La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
In questo documento viene descritto come configurare correttamente il servizio Registrazione dispositivi di rete Microsoft (NDES) e il protocollo SCEP (Simple Certificate Enrollment Protocol) per portare il proprio dispositivo (BYOD) su Cisco Identify Services Engine (ISE).
Cisco raccomanda la conoscenza dei seguenti argomenti:
Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Le informazioni relative ai servizi certificati Microsoft sono fornite come guida specifica per Cisco BYOD. Fare riferimento a Microsoft TechNet come fonte definitiva di informazioni per le configurazioni server relative a Microsoft Certification Authority, Network Device Enrollment Service (NDES) e SCEP.
Uno dei vantaggi dell'implementazione di BYOD abilitata per Cisco ISE è la capacità degli utenti finali di eseguire la registrazione self-service dei dispositivi. In questo modo viene eliminato il carico amministrativo che grava sul reparto IT per distribuire le credenziali di autenticazione e abilitare i dispositivi sulla rete. Il cuore della soluzione BYOD è il processo di provisioning dei supplicant di rete, che tenta di distribuire i certificati richiesti ai dispositivi di proprietà dei dipendenti. Per soddisfare questo requisito, è possibile configurare un'Autorità di certificazione (CA) Microsoft per automatizzare il processo di registrazione dei certificati con SCEP.
SCEP viene utilizzato da anni in ambienti VPN (Virtual Private Network) per facilitare la registrazione e la distribuzione dei certificati ai client e ai router di accesso remoto. L'attivazione della funzionalità SCEP su un server Windows 2008 R2 richiede l'installazione di NDES. Durante l'installazione del ruolo NDES viene installato anche il server Web Microsoft Internet Information Services (IIS). IIS viene utilizzato per terminare le richieste di registrazione SCEP HTTP o HTTPS e le risposte tra il nodo dei criteri CA e ISE.
Il ruolo NDES può essere installato in una CA corrente oppure in un server membro. In una distribuzione autonoma, il servizio NDES viene installato in una CA esistente che include il servizio Autorità di certificazione e, facoltativamente, il servizio Registrazione Web Autorità di certificazione. In una distribuzione distribuita, il servizio NDES viene installato in un server membro. Il server NDES distribuito viene quindi configurato per comunicare con una CA radice o una CA radice secondaria upstream. In questo scenario, le modifiche del Registro di sistema descritte in questo documento vengono apportate sul server NDES con il modello personalizzato, in cui i certificati risiedono nella CA a monte.
In questa sezione viene fornita una breve panoramica degli scenari di installazione di CA/NDES che sono stati testati nel laboratorio Cisco. Fare riferimento a Microsoft TechNet come fonte definitiva di informazioni per le configurazioni server relative a Microsoft CA, NDES e SCEP.
Quando ISE viene utilizzato in uno scenario Proof of Concept (PoC), è comune distribuire un computer Windows 2008 o 2012 autonomo che funge da controller di dominio Active Directory (AD), CA radice e server NDES:
Quando l'ISE è integrato in un ambiente di produzione Microsoft AD/PKI corrente, è più comune vedere i servizi distribuiti su più server distinti Windows 2008 o 2012. Cisco ha testato due scenari per le distribuzioni.
In questa immagine viene illustrato il primo scenario testato per le distribuzioni distribuite:
In questa immagine viene illustrato il secondo scenario testato per le distribuzioni distribuite:
Prima di configurare il supporto SCEP per BYOD, verificare che nel server Windows 2008 R2 NDES siano installati i seguenti aggiornamenti rapidi Microsoft:
Avviso: Quando si configura la CA Microsoft, è importante notare che l'ISE non supporta l'algoritmo di firma RSASSA-PSS. Cisco consiglia di configurare il criterio CA in modo che utilizzi sha1WithRSAEncryption o sha256WithRSAEncryption.
Di seguito è riportato un elenco di importanti porte e protocolli BYOD:
Nota: Per l'elenco più recente delle porte e dei protocolli richiesti, fare riferimento alla Guida all'installazione dell'hardware ISE 1.2.
Utilizzare questa sezione per configurare il supporto NDES e SCEP per BYOD sull'ISE.
Per impostazione predefinita, nell'implementazione di Microsoft SCEP (MSCEP) viene utilizzata una password di verifica dinamica per autenticare i client e gli endpoint durante l'intero processo di registrazione dei certificati. Con questo requisito di configurazione, è necessario passare alla GUI Web di amministrazione di MSCEP sul server NDES per generare una password su richiesta. È necessario includere questa password nella richiesta di registrazione.
In un'implementazione BYOD, il requisito di una password di verifica vanifica lo scopo di una soluzione self-service per gli utenti. Per rimuovere questo requisito, è necessario modificare la chiave del Registro di sistema nel server NDES:
In alcuni scenari di distribuzione, potrebbe essere preferibile limitare le comunicazioni SCEP a un elenco selezionato di nodi ISE noti. A tale scopo, è possibile utilizzare la funzionalità Restrizioni indirizzo IPv4 e dominio in IIS:
È possibile che ISE generi URL troppo lunghi per il server Web IIS. Per evitare questo problema, è possibile modificare la configurazione IIS predefinita in modo da consentire URL più lunghi. Immettere questo comando dalla CLI del server NDES:
%systemroot%\system32\inetsrv\appcmd.exe set config /section:system.webServer/
security/requestFiltering /requestLimits.maxQueryString:"8192" /commit:apphost
Nota: Le dimensioni della stringa di query potrebbero variare a seconda della configurazione di ISE e dell'endpoint. Immettere questo comando dalla CLI del server NDES con privilegi amministrativi.
Gli amministratori di una CA Microsoft possono configurare uno o più modelli utilizzati per applicare i criteri dell'applicazione a un insieme comune di certificati. Questi criteri consentono di identificare la funzione per cui vengono utilizzati il certificato e le chiavi associate. I valori dei criteri di applicazione sono contenuti nel campo Utilizzo chiave esteso (EKU) del certificato. L'autenticatore analizza i valori nel campo EKU per garantire che il certificato presentato dal client possa essere utilizzato per la funzione desiderata. Alcuni degli utilizzi più comuni includono l'autenticazione server, l'autenticazione client, la VPN IPSec e la posta elettronica. In termini di ISE, i valori dell'EKU più comunemente usati includono l'autenticazione del server e/o del client.
Quando si accede a un sito Web di una banca protetta, ad esempio, il server Web che elabora la richiesta viene configurato con un certificato con un criterio di applicazione di autenticazione server. Quando il server riceve una richiesta HTTPS, invia un certificato di autenticazione server al browser Web che si connette per l'autenticazione. Il punto importante è che si tratta di uno scambio unidirezionale dal server al client. In relazione all'ISE, un utilizzo comune per un certificato di autenticazione server è l'accesso tramite interfaccia grafica di amministrazione. ISE invia il certificato configurato al browser connesso e non si aspetta di ricevere un certificato dal client.
Quando si tratta di servizi come BYOD che utilizzano EAP-TLS, è preferibile l'autenticazione reciproca. Per abilitare lo scambio bidirezionale dei certificati, il modello utilizzato per generare il certificato di identità ISE deve disporre di una policy minima per l'applicazione dell'autenticazione server. Il modello di certificato del server Web soddisfa questo requisito. Il modello di certificato che genera i certificati degli endpoint deve contenere un criterio minimo di applicazione per l'autenticazione client. Il modello di certificato utente soddisfa questo requisito. Se si configura ISE per servizi come Inline Policy Enforcement Point (iPEP), il modello utilizzato per generare il certificato di identità del server ISE deve contenere entrambi gli attributi di autenticazione client e server se si utilizza ISE versione 1.1.x o precedenti. In questo modo, i nodi admin e inline possono autenticarsi reciprocamente. La convalida EKU per iPEP è stata rimossa in ISE versione 1.2, il che rende questo requisito meno rilevante.
È possibile riutilizzare i modelli predefiniti del server Web e dell'utente di Microsoft CA oppure duplicare e creare un nuovo modello con il processo descritto in questo documento. In base a questi requisiti, la configurazione della CA e i certificati ISE ed endpoint risultanti devono essere pianificati con attenzione per ridurre al minimo le modifiche indesiderate alla configurazione quando vengono installati in un ambiente di produzione.
Come indicato nell'introduzione, SCEP è ampiamente utilizzato in ambienti VPN IPSec. Di conseguenza, l'installazione del ruolo NDES configura automaticamente il server in modo che utilizzi il modello IPSec (Offline Request) per SCEP. Per questo motivo, uno dei primi passaggi nella preparazione di una CA Microsoft per BYOD consiste nella creazione di un nuovo modello con i criteri di applicazione corretti. In una distribuzione autonoma, i servizi Autorità di certificazione e NDES sono collocati nello stesso server e i modelli e le modifiche del Registro di sistema necessarie sono contenuti nello stesso server. In una distribuzione NDES distribuita, le modifiche del Registro di sistema vengono apportate sul server NDES; tuttavia, i modelli effettivi vengono definiti nel server CA radice o subradice specificato nell'installazione del servizio NDES.
Per configurare il modello di certificato, completare la procedura seguente:
Nota: Il periodo di validità del modello deve essere minore o uguale al periodo di validità dei certificati radice e intermedi della CA.
Nota: In alternativa, è possibile abilitare il modello dalla CLI con il comando certutil -SetCAtemplates +ISE-BYOD.
Completare questa procedura per configurare le chiavi del Registro di sistema per i modelli di certificato:
In una distribuzione BYOD, l'endpoint non comunica direttamente con il server NDES back-end. Al contrario, il nodo dei criteri ISE è configurato come proxy SCEP e comunica con il server NDES per conto degli endpoint. Gli endpoint comunicano direttamente con l'ISE. È possibile configurare l'istanza di IIS nel server NDES in modo da supportare i binding HTTP e/o HTTPS per le directory virtuali SCEP.
Completare questa procedura per configurare ISE come proxy SCEP:
Attualmente non è disponibile una procedura di verifica per questa configurazione.
Consultare questa sezione per risolvere i problemi di configurazione.
Di seguito è riportato un elenco di note importanti che è possibile utilizzare per risolvere i problemi relativi alla configurazione:
Nota: Alcuni supplicant non inizializzano uno scambio di certificati client se è presente l'EKU errato, ad esempio un certificato client con l'EKU dell'autenticazione server. Pertanto, gli errori di autenticazione potrebbero non essere sempre presenti nei log ISE.
Di seguito sono elencate alcune tecniche utili utilizzate per risolvere i problemi di registrazione sul lato client:
Nota: WinHTTP viene utilizzato per la connessione tra l'endpoint Microsoft Windows e ISE. Fare riferimento all'articolo Messaggi di errore di Microsoft Windows per un elenco di codici di errore.
Completare questa procedura per visualizzare il log ISE:
Per ulteriori informazioni, fare riferimento a Servizi certificati Active Directory: Risoluzione dei problemi relativi al servizio Registrazione dispositivi di rete Articolo di Windows Server.