Configurare il supporto di AD FS per l'autenticazione del certificato utente

Questo articolo descrive come abilitare l'autenticazione del certificato utente in Active Directory Federation Services (AD FS). Fornisce anche informazioni sulla risoluzione dei problemi comuni relativi a questo tipo di autenticazione.

Esistono due casi d'uso principali per l'autenticazione del certificato utente:

• Gli utenti usano smart card per accedere al sistema AD FS.
• Gli utenti utilizzano certificati assegnati ai dispositivi mobili.

Prerequisiti

• Determinare la modalità di autenticazione del certificato utente di AD FS che si vuole abilitare usando una delle modalità descritte in supporto ad AD FS per l'associazione di nomi host alternativi per l'autenticazione del certificato.
• Assicurarsi che la catena di attendibilità dei certificati utente sia installata e considerata attendibile da tutti i server AD FS e Web Application Proxy (WAP), incluse le autorità di certificazione intermedie. Questa operazione viene in genere eseguita tramite l'oggetto Criteri di gruppo nei server AD FS e WAP.
• Assicurarsi che il certificato radice della catena di attendibilità per i certificati utente si trova nell'archivio NTAuth in Active Directory.
• Se si usa AD FS in modalità di autenticazione del certificato alternativa, assicurarsi che i server AD FS e WAP dispongano di certificati SSL (Secure Sockets Layer) che contengono il nome host AD FS preceduto da "certauth". Un esempio è certauth.fs.contoso.com. Assicurarsi anche che il traffico verso questo nome host sia consentito attraverso il firewall.
• Se si usa l'autenticazione del certificato dall'extranet, assicurarsi che almeno un AIA (Authority Information Access) e almeno un punto di distribuzione CRL (CDP) o il percorso OCSP (Online Certificate Status Protocol) nell'elenco dei certificati specificati siano accessibili da Internet.
• Se si sta configurando AD FS per l'autenticazione del certificato Microsoft Entra, assicurarsi di aver configurato le impostazioni di microsoft Entra e le regole attestazioni AD FS necessarie per l'autorità di certificazione e il numero di serie.
• Se si usa l'autenticazione del certificato Microsoft Entra per i client Exchange ActiveSync, il certificato client deve avere l'indirizzo di posta elettronica instradabile dell'utente in Exchange Online nel valore Nome entità o il valore nome RFC822 valore del campo Nome alternativo soggetto. Microsoft Entra ID esegue il mapping del valore RFC822 all'attributo dell'indirizzo proxy nella directory.

Abilitare l'autenticazione del certificato utente

Abilitare l'autenticazione del certificato utente come metodo di autenticazione Intranet o Extranet in AD FS usando la console di gestione di AD FS o il cmdlet di PowerShell Set-AdfsGlobalAuthenticationPolicy.

Le considerazioni facoltative includono:

• Se si vogliono usare attestazioni basate su campi certificato ed estensioni oltre al tipo di attestazione EKU, https://schemas.microsoft.com/2012/12/certificatecontext/extension/eku, configurare ulteriori regole di passaggio delle attestazioni nella relazione di attendibilità del provider di attestazioni Active Directory. Consulta l'elenco completo delle attestazioni di certificato disponibili più avanti in questo articolo.

• Se è necessario limitare l'accesso in base al tipo di certificato, è possibile usare le proprietà aggiuntive sul certificato nelle regole di autorizzazione di rilascio di AD FS per l'applicazione. Gli scenari comuni sono consentire solo i certificati di cui è stato effettuato il provisioning da un provider di gestione di dispositivi mobili (MDM) o di consentire solo i certificati smart card.

  Importante

  I clienti che usano il flusso del codice del dispositivo per l'autenticazione ed eseguono l'autenticazione del dispositivo usando un provider di identità diverso da Microsoft Entra ID (ad esempio, AD FS) non possono applicare l'accesso basato su dispositivo per le risorse di Microsoft Entra. Ad esempio, non possono consentire solo i dispositivi gestiti usando un servizio MDM di terze parti.

  Per proteggere l'accesso alle risorse aziendali in Microsoft Entra ID e prevenire eventuali perdite di dati, configurare l'accesso condizionale basato sul dispositivo Microsoft Entra. Ad esempio, usare Richiedi che il dispositivo sia contrassegnato come reclamo per concedere il controllo nell'accesso condizionale di Microsoft Entra.

  Configurare le autorità di certificazione emittente consentite per i certificati client usando le linee guida riportate in "Gestione di autorità di certificazione attendibili per l'autenticazione client" nella panoramica tecnica di SSP Schannel .

• È consigliabile modificare le pagine di accesso in base alle esigenze degli utenti quando eseguono l'autenticazione del certificato. Un caso comune consiste nel modificare Accedere con il certificato X509 a qualcosa di più semplice da usare.

Configurare l'autenticazione senza problemi di certificato per il browser Chrome nei desktop di Windows

Quando un computer dispone di più certificati utente (ad esempio Wi-Fi certificati) che soddisfano gli scopi dell'autenticazione client, il browser Chrome nei desktop di Windows richiederà agli utenti di selezionare il certificato corretto. Questa richiesta potrebbe generare confusione per gli utenti. Per ottimizzare questa esperienza, è possibile impostare un criterio per Chrome per selezionare automaticamente il certificato corretto.

È possibile impostare manualmente questo criterio modificando il Registro di sistema oppure configurarlo automaticamente tramite i Criteri di Gruppo (per impostare le chiavi del Registro di sistema). Ciò richiede che i certificati client utente per l'autenticazione in AD FS abbiano autorità emittenti distinte da altri casi d'uso.

Per altre informazioni sulla configurazione dell'autenticazione del certificato per Chrome, vedere elenco di criteri di Chrome Enterprise.

Risolvere i problemi di autenticazione del certificato

Usare le informazioni seguenti per risolvere i problemi comuni durante la configurazione di AD FS per l'autenticazione del certificato per gli utenti.

Controllare se le autorità emittenti attendibili del certificato sono configurate correttamente in tutti i server AD FS e WAP

Se le autorità emittenti attendibili del certificato non sono configurate correttamente, un sintomo comune è un errore HTTP 204: "Nessun contenuto da https://certauth.adfs.contoso.com."

AD FS usa il sistema operativo Windows sottostante per dimostrare il possesso del certificato utente e assicurarsi che corrisponda a un'autorità emittente attendibile convalidando la catena di attendibilità del certificato. Per corrispondere all'emittente attendibile, è necessario assicurarsi che tutte le autorità radice e intermedie siano configurate come emittenti attendibili nell'archivio locale per le autorità di certificazione del computer.

Per convalidarlo automaticamente, utilizzare lo strumento Analizzatore Diagnostico AD FS. Lo strumento esegue una query su tutti i server e garantisce che venga eseguito correttamente il provisioning dei certificati corretti.

1. Scaricare ed eseguire lo strumento.
2. Caricare i risultati ed esaminare eventuali errori.

Controllare se l'autenticazione del certificato è abilitata nei criteri di autenticazione di AD FS

AD FS esegue l'autenticazione del certificato utente per impostazione predefinita sulla porta 49443 con lo stesso nome host di AD FS (ad esempio, adfs.contoso.com). È anche possibile configurare AD FS per usare la porta 443 (porta HTTPS predefinita) usando l'associazione SSL alternativa. Tuttavia, l'URL usato in questa configurazione è certauth.<adfs-farm-name> (ad esempio: certauth.contoso.com). Per ulteriori informazioni, consultare il supporto di AD FS per l'associazione di nomi host alternativi con l'autenticazione tramite certificato.

Il caso più comune dei problemi di connettività di rete è che un firewall è stato configurato in modo non corretto e blocca il traffico per l'autenticazione del certificato utente. In genere, viene visualizzata una schermata vuota o un errore del server 500 quando si verifica questo problema. Per correggerlo:

1. Prendere nota del nome host e della porta configurati in AD FS.
2. Assicurati che un firewall davanti ad AD FS o WAP sia configurato di consentire la combinazione hostname:port per la tua farm AD FS. Il tecnico di rete deve eseguire questo passaggio.

Controllare la connettività CRL

Gli elenchi di revoche di certificati (CRL) sono endpoint codificati nel certificato utente per eseguire controlli di revoca in fase di esecuzione. Ad esempio, se un dispositivo che contiene un certificato viene rubato, un amministratore può aggiungere il certificato all'elenco di certificati revocati. Qualsiasi endpoint che ha accettato questo certificato in precedenza avrà esito negativo per l'autenticazione.

Ogni server AD FS e WAP deve raggiungere l'endpoint CRL per verificare se il certificato presentato è ancora valido e non è stato revocato. La convalida CRL può verificarsi tramite HTTPS, HTTP, LDAP o OCSP. Se i server AD FS e WAP non riescono a raggiungere l'endpoint, l'autenticazione avrà esito negativo. Per risolvere i problemi, seguire questa procedura:

1. Rivolgersi al tecnico dell'infrastruttura a chiave pubblica (PKI) per determinare quali endpoint CRL vengono usati per revocare i certificati utente dal sistema PKI.
2. In ogni server AD FS e WAP assicurarsi che gli endpoint CRL siano raggiungibili tramite il protocollo usato (in genere HTTPS o HTTP).
3. Per la convalida avanzata, abilita la registrazione degli eventi CAPI2 su ciascun server AD FS e WAP.
4. Verificare la presenza dell'ID evento 41 (verifica revoca) nei log operativi CAPI2.
5. Verificare la presenza di <Result value="80092013">The revocation function was unable to check revocation because the revocation server was offline.</Result>.

Verificare la presenza di problemi SNI

AD FS richiede dispositivi client (o browser) e i servizi di bilanciamento del carico per supportare l'indicazione del nome del server (SNI). Alcuni dispositivi client( ad esempio versioni precedenti di Android) potrebbero non supportare SNI. Inoltre, i servizi di bilanciamento del carico potrebbero non supportare SNI o non essere configurati per SNI. In questi casi è probabile che si verifichino errori di certificazione utente.

Per risolvere questo problema, rivolgersi al tecnico di rete per assicurarsi che il servizio di bilanciamento del carico per AD FS e WAP supporti SNI. Se SNI non può essere supportato, usare la soluzione alternativa seguente in AD FS:

1. Aprire una finestra del prompt dei comandi con privilegi elevati nel server AD FS primario.
2. Inserisci Netsh http show sslcert.
3. Copiare il GUID dell'applicazione e l'hash del certificato del servizio federativo.
4. Inserisci netsh http add sslcert ipport=0.0.0.0:{your_certauth_port} certhash={your_certhash} appid={your_applicationGUID}.

Verificare se il dispositivo client è stato configurato correttamente con il certificato.

Si potrebbe notare che alcuni dispositivi funzionano correttamente, ma altri non lo sono. Nella maggior parte dei casi, significa che il provisioning del certificato utente non è stato eseguito correttamente in alcuni dispositivi client. Seguire questa procedura:

1. Se il problema è specifico di un dispositivo Android, la causa più comune è che la catena di certificati non è completamente attendibile nel dispositivo. Fare riferimento al fornitore MDM per assicurarsi che il provisioning del certificato sia stato eseguito correttamente e che l'intera catena sia completamente attendibile nel dispositivo Android.

   Se il problema è specifico di un dispositivo Windows, verificare se il provisioning del certificato viene eseguito correttamente controllando l'archivio certificati di Windows per l'utente connesso (non di sistema o computer).

2. Esportare il certificato utente client in un file di .cer ed eseguire il comando certutil -f -urlfetch -verify certificatefilename.cer.

Controllare se la versione di TLS è compatibile tra i server AD FS/WAP e il dispositivo client

In rari casi, un dispositivo client viene aggiornato per supportare solo una versione successiva di TLS (ad esempio, 1.3). In alternativa, potrebbe verificarsi un problema inverso, in cui i server AD FS e WAP sono stati aggiornati in modo da usare solo una versione TLS superiore non supportata dal dispositivo client.

È possibile usare gli strumenti SSL online per controllare i server AD FS e WAP e verificare se sono compatibili con il dispositivo. Per altre informazioni su come controllare le versioni di TLS, vedere Gestione di protocolli SSL/TLS e pacchetti di crittografia per AD FS.

Controllare se Microsoft Entra PromptLoginBehavior è configurato correttamente nelle impostazioni del dominio federato

Molte applicazioni di Office 365 inviano prompt=login a Microsoft Entra ID. Microsoft Entra ID, per impostazione predefinita, lo converte in un nuovo account di accesso con password ad AD FS. Di conseguenza, anche se è stata configurata l'autenticazione del certificato in AD FS, gli utenti visualizzano solo un account di accesso con password. Per risolvere il problema:

1. Ottenere le impostazioni del dominio federato usando il cmdlet Get-MgDomainFederationConfiguration.
2. Assicurarsi che il parametro PromptLoginBehavior sia impostato su Disabled o NativeSupport.

Per altre informazioni, vedere AD FS prompt=login parameter support.

Risoluzione dei problemi aggiuntiva

Raramente, se gli elenchi CRL sono molto lunghi, potrebbero andare in timeout quando si tenta di scaricarli. In questo caso, è necessario aggiornare MaxFieldLength e MaxRequestByte come descritto in Http.sys impostazioni del Registro di sistema per Windows.

Riferimento: Elenco completo dei tipi di attestazione di certificato utente e valori di esempio

Collegamenti correlati

• Configurare l'associazione del nome host alternativo per l'autenticazione del certificato AD FS
• Configurare le autorità di certificazione in Microsoft Entra ID