Condividi tramite

Configurare il supporto 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). Vengono anche fornite informazioni sulla risoluzione di 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 usano i certificati di cui è stato effettuato il provisioning nei 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 di 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 trovi 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 dalla extranet, assicurarsi che almeno un accesso alle informazioni dell'autorità (AIA) e almeno un punto di distribuzione dell'elenco di revoche di certificati (CDP) o un percorso Protocollo di stato del certificato online (OCSP) dall'elenco specificato nei certificati 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 Principal Name o nel valore RFC822 Name del campo Subject Alternative Name .If you're using Microsoft Entra certificate authentication for Exchange ActiveSync clients, the client certificate must have the user's routable email address in Exchange Online in the Principal Name value or the RFC822 Name value of the Subject Alternative Name field. Microsoft Entra ID esegue il mapping del valore RFC822 all'attributo dell'indirizzo proxy nella directory.

Nota

AD FS non supporta gli hint per il nome utente con l'autenticazione basata su smart card o certificati.

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.

Alcune considerazioni opzionali 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 più regole pass-through attestazioni nel trust del provider di attestazioni Active Directory. Vedere 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 consistono esempio nel 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 emittenti consentite per i certificati client usando le indicazioni 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 in qualcosa di più intuitivo.

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

Quando un computer dispone di più certificati utente (ad esempio certificati Wi-Fi) che soddisfano gli scopi dell'autenticazione client, il browser Chrome nei desktop 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 questo criterio manualmente apportando una modifica al Registro di sistema oppure è possibile configurarlo automaticamente tramite l'oggetto 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 degli 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 trovare una corrispondenza con l'emittente attendibile, è necessario assicurarsi che tutte le autorità radice e intermedie siano configurate come autorità di certificazione attendibili nell'archivio locale per le autorità di certificazione del computer.

Per convalidarlo automaticamente, usare lo strumento analizzatore diagnostica 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 altre informazioni, vedere Supporto di AD FS per l'associazione di nomi host alternativi per l'autenticazione del certificato.

Nota

In AD FS in Windows Server 2016 sono ora supportate due modalità. La prima modalità usa l'host adfs.contoso.com con le porte 443 e 49443. La seconda modalità usa host adfs.contoso.com e certauth.adfs.contoso.com con la porta 443. È necessario un certificato SSL per supportare certauth.\<adfs-service-name> come nome soggetto alternativo. È possibile eseguire questa operazione al momento della creazione della farm o in seguito tramite PowerShell.

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

  1. Prendere nota del nome host e della porta configurati in AD FS.
  2. Assicurarsi che qualsiasi firewall davanti ad AD FS o WAP sia configurato per consentire la combinazione di hostname:port per la 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. Utilizzare la procedura riportata di seguito per risolvere i problemi:

  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, abilitare la registrazione eventi CAPI2 in ogni server AD FS e WAP.
  4. Verificare la presenza dell'ID evento 41 (verifica revoca) nei log operativi CAPI2.
  5. Controllare <Result value="80092013">The revocation function was unable to check revocation because the revocation server was offline.</Result>.

Suggerimento

È possibile specificare come destinazione un singolo server AD FS o WAP per semplificare la risoluzione dei problemi, configurando la risoluzione DNS (file host in Windows) in modo che punti a un server specifico. Questa tecnica consente di abilitare la traccia specificando come destinazione un server.

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. Nel server AD FS primario aprire una finestra del prompt dei comandi con privilegi elevati.
  2. Immetti Netsh http show sslcert.
  3. Copiare il GUID dell'applicazione e l'hash del certificato del servizio federativo.
  4. Immetti netsh http add sslcert ipport=0.0.0.0:{your_certauth_port} certhash={your_certhash} appid={your_applicaitonGUID}.

Controllare se il provisioning del dispositivo client è stato eseguito correttamente con il certificato

Si potrebbe notare che alcuni dispositivi funzionano correttamente, ma altri no. 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 sia 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 per il sistema o computer).

  2. Esportare il certificato utente client in un file .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 la 1.3). In alternativa, potrebbe verificarsi un problema inverso, in cui i server AD FS e WAP vengono 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 suite 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 Supporto per il parametro prompt=login in AD FS.

Risoluzione dei problemi aggiuntiva

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

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

Tipo di attestazione Valore di esempio
http://schemas.microsoft.com/2012/12/certificatecontext/field/x509version 3
http://schemas.microsoft.com/2012/12/certificatecontext/field/signaturealgorithm sha256RSA
http://schemas.microsoft.com/2012/12/certificatecontext/field/issuer CN=entca, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/issuername CN=entca, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/notbefore 12/05/2016 20:50:18
http://schemas.microsoft.com/2012/12/certificatecontext/field/notafter 12/05/2017 20:50:18
http://schemas.microsoft.com/2012/12/certificatecontext/field/subject E=user@contoso.com, CN=user, CN=Users, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/subjectname E=user@contoso.com, CN=user, CN=Users, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/rawdata {Base64 encoded digital certificate data}
http://schemas.microsoft.com/2012/12/certificatecontext/extension/keyusage DigitalSignature
http://schemas.microsoft.com/2012/12/certificatecontext/extension/keyusage KeyEncipherment
http://schemas.microsoft.com/2012/12/certificatecontext/extension/subjectkeyidentifier 9D11941EC06FACCCCB1B116B56AA97F3987D620A
http://schemas.microsoft.com/2012/12/certificatecontext/extension/authoritykeyidentifier KeyID=d6 13 e3 6b bc e5 d8 15 52 0a fd 36 6a d5 0b 51 f3 0b 25 7f
http://schemas.microsoft.com/2012/12/certificatecontext/extension/certificatetemplatename User
http://schemas.microsoft.com/2012/12/certificatecontext/extension/san Other Name:Principal Name=user@contoso.com, RFC822 Name=user@contoso.com
http://schemas.microsoft.com/2012/12/certificatecontext/extension/eku 1.3.6.1.4.1.311.10.3.4