Approfondimento tecnico sull'autenticazione basata su certificati Microsoft Entra

Questo articolo illustra il funzionamento dell'autenticazione basata su certificati (CBA) di Microsoft Entra e illustra i dettagli tecnici sulle configurazioni CBA di Microsoft Entra.

Come funziona l'autenticazione basata su certificati Microsoft Entra?

L'immagine seguente descrive cosa accade quando un utente tenta di accedere a un'applicazione in un tenant in cui è abilitato Microsoft Entra CBA.

A questo punto verrà illustrato ogni passaggio:

1. L'utente tenta di accedere a un'applicazione, ad esempio il portale App personali.

2. Se l'utente non ha già eseguito l'accesso, l'utente viene reindirizzato alla pagina di accesso utente di Microsoft Entra ID all'indirizzo https://login.microsoftonline.com/.

3. L'utente immette il proprio nome utente nella pagina di accesso di Microsoft Entra e quindi seleziona Avanti. Microsoft Entra ID esegue l'individuazione dell'area di autenticazione principale usando il nome del tenant e il nome utente viene usato per cercare l'utente nel tenant.

   

4. Microsoft Entra ID verifica se L'autenticazione ABA è abilitata per il tenant. Se CBA è abilitato, l'utente visualizza un collegamento a Usa un certificato o una smart card nella pagina della password. Se l'utente non visualizza il collegamento di accesso, assicurarsi che CBA sia abilitato nel tenant. Per altre informazioni, vedere Ricerca per categorie abilitare Microsoft Entra CBA?.

   Nota

   Se il CBA è abilitato nel tenant, tutti gli utenti visualizzano il collegamento Usa un certificato o una smart card nella pagina della password. Tuttavia, solo gli utenti nell'ambito di CBA possono eseguire correttamente l'autenticazione in un'applicazione che usa l'ID Microsoft Entra come provider di identità (IdP).

   

   Se sono stati abilitati altri metodi di autenticazione, ad esempio Telefono chiavi di accesso o di sicurezza, gli utenti potrebbero visualizzare una schermata di accesso diversa.

   

5. Dopo che l'utente seleziona l'autenticazione basata su certificato, il client viene reindirizzato all'endpoint di autenticazione del certificato, ovvero https://certauth.login.microsoftonline.com per l'ID Entra pubblico. Per Azure per enti pubblici, l'endpoint di autenticazione del certificato è https://certauth.login.microsoftonline.us.

   L'endpoint esegue l'autenticazione reciproca TLS e richiede il certificato client come parte dell'handshake TLS. Nel log degli accessi viene visualizzata una voce per questa richiesta.

   Nota

   L'amministratore di rete deve consentire l'accesso alla pagina di accesso utente e all'endpoint *.certauth.login.microsoftonline.com certauth per l'ambiente cloud del cliente. Disabilitare l'ispezione TLS nell'endpoint certauth per assicurarsi che la richiesta del certificato client abbia esito positivo come parte dell'handshake TLS.

   Assicurarsi che la disabilitazione dell'ispezione TLS funzioni anche per il nuovo URL con hint dell'autorità di certificazione. Non impostare come hardcoded l'URL con tenantId perché potrebbe cambiare per gli utenti B2B. Usare un'espressione regolare per consentire il funzionamento dell'URL precedente e nuovo per la disabilitazione dell'ispezione TLS. Ad esempio, a seconda del proxy, usare *.certauth.login.microsoftonline.com o *certauth.login.microsoftonline.com. In Azure per enti pubblici usare *.certauth.login.microsoftonline.us o *certauth.login.microsoftonline.us.

   A meno che l'accesso non sia consentito, l'autenticazione basata su certificati non riesce se si abilita la funzionalità di hint ca attendibili imminenti.

6. Microsoft Entra ID richiede un certificato client. L'utente seleziona il certificato client e seleziona OK.

   Nota

   Gli hint ca attendibili non sono supportati, quindi l'elenco dei certificati non può essere ulteriormente limitato. Questa funzionalità verrà aggiunta in futuro.

   

7. Microsoft Entra ID verifica l'elenco di revoche di certificati per assicurarsi che il certificato non sia revocato e sia valido. Microsoft Entra ID identifica l'utente usando l'associazione nome utente configurata nel tenant per eseguire il mapping del valore del campo del certificato al valore dell'attributo utente.

8. Se viene trovato un utente univoco con un criterio di accesso condizionale che richiede l'autenticazione a più fattori e la regola di associazione di autenticazione del certificato soddisfa l'autenticazione a più fattori, Microsoft Entra ID firma immediatamente l'utente. Se l'autenticazione a più fattori è obbligatoria, ma il certificato soddisfa solo un singolo fattore, l'accesso senza password o FIDO2 viene offerto come secondo fattore se sono già registrati.

9. Microsoft Entra ID completa il processo di accesso inviando di nuovo un token di aggiornamento primario per indicare l'accesso riuscito.

10. Se l'accesso dell'utente ha esito positivo, l'utente può accedere all'applicazione.

L'autenticazione basata su certificati è in grado di supportare mfa

Microsoft Entra CBA è in grado di eseguire l'autenticazione a più fattori (MFA). Microsoft Entra CBA può essere a fattore singolo (SF) o multifactoring (MF) a seconda della configurazione del tenant. L'abilitazione dell'autorità di certificazione rende un utente potenzialmente in grado di completare l'autenticazione a più fattori. Un utente potrebbe avere bisogno di una configurazione maggiore per completare l'autenticazione a più fattori e riprovare a registrare altri metodi di autenticazione quando l'utente è nell'ambito di CBA.

Se l'utente abilitato per CBA ha solo un certificato Single Factor (SF) e deve completare l'autenticazione a più fattori:

1. Usare una password e un certificato SF.
2. Eseguire un pass di accesso temporaneo.
3. Criteri di autenticazione Amministrazione istrator aggiunge un numero di telefono e consente l'autenticazione vocale/SMS per l'account utente.

Se l'utente abilitato per CBA non ha ancora emesso un certificato e deve completare l'autenticazione a più fattori:

1. Eseguire un pass di accesso temporaneo.
2. Criteri di autenticazione Amministrazione istrator aggiunge un numero di telefono e consente l'autenticazione vocale/SMS per l'account utente.

Se l'utente abilitato per CBA non può usare un certificato MF, ad esempio nel dispositivo mobile senza supporto per smart card e deve completare l'autenticazione a più fattori:

1. Eseguire un pass di accesso temporaneo.
2. L'utente deve registrare un altro metodo MFA (quando l'utente può usare il certificato MF).
3. Usare la password e il certificato MF (quando l'utente può usare il certificato MF).
4. Criteri di autenticazione Amministrazione istrator aggiunge un numero di telefono e consente l'autenticazione vocale/SMS per l'account utente.

Autenticazione a più fattori con autenticazione basata su certificati a singolo fattore (anteprima)

Microsoft Entra CBA può essere usato come secondo fattore per soddisfare i requisiti MFA con certificati a singolo fattore. Alcune delle combinazioni supportate sono:

1. CBA (primo fattore) e accesso tramite telefono senza password (accesso senza password come secondo fattore)
2. CBA (primo fattore) e chiavi di sicurezza FIDO2 (secondo fattore)
3. Password (primo fattore) e CBA (secondo fattore)

Gli utenti devono avere un altro modo per ottenere mfa e registrare l'accesso senza password o FIDO2 in anticipo per accedere con Microsoft Entra CBA.

Importante

Un utente è considerato in grado di supportare l'autenticazione a più fattori quando sono inclusi nelle impostazioni del metodo CBA. Ciò significa che l'utente non può usare la prova come parte dell'autenticazione per registrare altri metodi disponibili. Assicurarsi che gli utenti senza un certificato valido non siano inclusi nelle impostazioni del metodo CBA. Per altre informazioni sul funzionamento dell'autenticazione, vedere Autenticazione a più fattori Di Microsoft Entra.

Procedura per configurare l'accesso tramite telefono senza password (PSI) con CBA

Per il funzionamento dell'accesso senza password, gli utenti devono disabilitare la notifica legacy tramite l'app per dispositivi mobili.

1. Accedere all'interfaccia di amministrazione di Microsoft Entra come almeno un criterio di autenticazione Amministrazione istrator.

2. Seguire la procedura descritta in Abilitare l'autenticazione di accesso tramite telefono senza password.

   Importante

   Nella configurazione precedente verificare di aver scelto l'opzione Senza password . È necessario modificare la modalità di autenticazione per tutti i gruppi aggiunti per PSI a Senza password. Se si sceglie Any, CBA e PSI non funzionano.

3. Selezionare Protezione>autenticazione>a più fattori Altre impostazioni di autenticazione a più fattori basate sul cloud.

   

4. In Opzioni di verifica deselezionare Notifica tramite app per dispositivi mobili e selezionare Salva.

   

Flusso di autenticazione MFA con certificati a fattore singolo e accesso senza password

Di seguito viene illustrato un esempio di utente che ha un certificato a fattore singolo ed è configurato per l'accesso senza password.

1. Immettere il nome dell'entità utente (UPN) e selezionare Avanti.

   

2. Selezionare Accedi con un certificato.

   

   Se sono stati abilitati altri metodi di autenticazione, ad esempio Telefono chiavi di sicurezza di accesso o FIDO2, gli utenti potrebbero visualizzare una schermata di accesso diversa.

   

3. Selezionare il certificato utente corretto nella selezione certificati client e selezionare OK.

   

4. Poiché il certificato è configurato come livello di autenticazione a singolo fattore, l'utente deve avere un secondo fattore per soddisfare i requisiti di autenticazione a più fattori. L'utente vede i secondi fattori disponibili, che in questo caso è l'accesso senza password. Selezionare Approva una richiesta nell'app Microsoft Authenticator.

   

5. Riceverai una notifica sul telefono. Selezionare Approva accesso?.

6. Immettere il numero visualizzato nella schermata del browser o dell'app in Microsoft Authenticator.

   

7. Selezionare Sì e l'utente può eseguire l'autenticazione e accedere.

Informazioni sui criteri di associazione di autenticazione

I criteri di associazione di autenticazione consentono di determinare la forza dell'autenticazione come fattore singolo o a più fattori. Un amministratore può modificare il valore predefinito da un singolo fattore a più fattori o configurare configurazioni di criteri personalizzate usando l'oggetto dell'autorità di certificazione o l'OID dei criteri o l'OID autorità emittente e criterio nel certificato.

Punti di forza del certificato

Un amministratore può determinare se i certificati sono di livello a fattore singolo o a più fattori. Per altre informazioni, vedere la documentazione che esegue il mapping dei livelli di controllo dell'autenticazione NIST ai metodi di autenticazione di Microsoft Entra, basati su NIST 800-63B SP 800-63B, Linee guida per l'identità digitale: autenticazione e mgmt del ciclo di vita.

Autenticazione del certificato a più fattori

Quando un utente dispone di un certificato a più fattori, può eseguire l'autenticazione a più fattori solo con certificati. Tuttavia, un criterio di autenticazione Amministrazione istrator deve assicurarsi che i certificati siano protetti con un PIN o una biometria da considerare a più fattori.

Come Microsoft Entra ID risolve più regole di associazione dei criteri di autenticazione

Poiché è possibile creare più regole dei criteri di associazione per l'autenticazione personalizzata con campi di certificato diversi, ad esempio l'emittente e l'OID criteri o semplicemente l'OID criteri. Di seguito sono riportati i passaggi usati per determinare il livello di protezione dell'autenticazione quando le regole personalizzate si sovrappongono. Questi sono:

1. Le regole OID autorità di certificazione e criteri hanno la precedenza sulle regole OID dei criteri. Le regole OID dei criteri hanno la precedenza sulle regole dell'autorità di certificazione del certificato.
2. Le regole OID autorità di certificazione e criteri vengono valutate per prime. Se si dispone di una regola personalizzata con autorità di certificazione CA1 e OID dei criteri 1.2.3.4.5 con MFA, solo il certificato A soddisfa sia il valore dell'autorità di certificazione che l'OID dei criteri riceveranno MFA.
3. Vengono quindi valutate le regole personalizzate che usano gli ID dei criteri. Se si dispone di un certificato A con OID dei criteri 1.2.3.4.5 e una credenziale derivata B basata su tale certificato con un OID criteri 1.2.3.4.5.6 e la regola personalizzata viene definita come OID dei criteri con valore 1.2.3.4.5 con MFA, solo il certificato A soddisfa l'autenticazione a più fattori e la credenziale B soddisfa solo l'autenticazione a singolo fattore. Se l'utente ha usato le credenziali derivate durante l'accesso ed è stato configurato per avere MFA, all'utente viene richiesto un secondo fattore per l'autenticazione riuscita.
4. Se si verifica un conflitto tra più ID criteri (ad esempio quando un certificato ha due ID criteri, in cui uno si associa all'autenticazione a fattore singolo e l'altro si associa a MFA), considera il certificato come autenticazione a singolo fattore.
5. Vengono quindi valutate le regole personalizzate che usano l'autorità di certificazione dell'autorità di certificazione.
6. Se un certificato include sia l'OID dei criteri che le regole autorità di certificazione corrispondenti, l'OID dei criteri viene sempre controllato e, se non viene trovata alcuna regola dei criteri, vengono controllate le associazioni dell'autorità emittente. L'OID dei criteri ha una priorità di associazione di autenticazione avanzata più elevata rispetto all'autorità emittente.
7. Se un'autorità di certificazione è associata a MFA, tutti i certificati utente emessi dalla CA sono qualificati come MFA. La stessa logica si applica per l'autenticazione a fattore singolo.
8. Se un OID dei criteri viene associato a MFA, tutti i certificati utente che includono questo OID dei criteri come uno degli ID predefiniti (un certificato utente potrebbe avere più ID criteri) sono qualificati come MFA.
9. Un'autorità emittente di certificati può avere solo un'associazione di autenticazione avanzata valida, ovvero un certificato non può essere associato sia a singolo fattore che a MFA.

Importante

Esiste un problema noto per cui un amministratore tenant entra configura una regola dei criteri di autenticazione CBA usando sia l'OID autorità di certificazione che l'OID dei criteri influisce su alcuni scenari di registrazione dei dispositivi, tra cui:

• Registrazione di Windows Hello For Business
• Registrazione della chiave di sicurezza Fido2
• Accesso senza password di Windows Telefono

La registrazione del dispositivo con Workplace Join, Entra ID e scenari di aggiunta di dispositivi Entra ID ibrido non sono interessati. Le regole dei criteri di autenticazione CBA che usano l'OID dei criteri dell'autorità emittente o dei criteri non sono interessate. Per attenuare il problema, gli amministratori devono :

• Modificare le regole dei criteri di autenticazione basate su certificati che usano attualmente entrambe le opzioni OID autorità di certificazione e criteri e rimuovere il requisito Autorità di certificazione o OID e salvare. OPPURE
• Rimuovere la regola dei criteri di autenticazione attualmente usando l'OID autorità di certificazione e i criteri e creare regole usando solo l'OID autorità emittente o criteri

Microsoft sta lavorando per risolvere il problema.

Informazioni sui criteri di associazione nome utente

Il criterio di associazione del nome utente consente di convalidare il certificato dell'utente. Per impostazione predefinita, il nome dell'entità soggetto alternativo (SAN) nel certificato viene mappato all'attributo UserPrincipalName dell'oggetto utente per determinare l'utente.

Ottenere una maggiore sicurezza con associazioni di certificati

Esistono sette metodi supportati per le associazioni di certificati. In generale, i tipi di mapping sono considerati affinità elevata se sono basati su identificatori che non è possibile riutilizzare, ad esempio identificatori chiave soggetto o chiave pubblica SHA1. Questi identificatori forniscono una maggiore garanzia che solo un singolo certificato possa essere usato per autenticare il rispettivo utente.

I tipi di mapping in base ai nomi utente e agli indirizzi di posta elettronica sono considerati poco affini. Microsoft Entra ID implementa tre mapping considerati a bassa affinità in base a identificatori riutilizzabili. Gli altri sono considerati associazioni ad alta affinità. Per altre informazioni, vedere certificateUserIds.

Campo Mapping certificati	Esempi di valori in certificateUserIds	Attributi dell'oggetto utente	Type
Nome entità	X509:<PN>bob@woodgrove.com	Userprincipalname onPremisesUserPrincipalName certificateUserIds	affinità bassa
RFC822Name	X509:<RFC822>user@woodgrove.com	Userprincipalname onPremisesUserPrincipalName certificateUserIds	affinità bassa
IssuerAndSubject (anteprima)	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	certificateUserIds	affinità bassa
Oggetto (anteprima)	X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	certificateUserIds	affinità bassa
SCI	X509:<SKI>123456789abcdef	certificateUserIds	affinità elevata
SHA1PublicKey	X509:<SHA1-PUKEY>123456789abcdef	certificateUserIds	affinità elevata
IssuerAndSerialNumber (anteprima)	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48 Per ottenere il valore corretto per il numero di serie, eseguire questo comando e archiviare il valore visualizzato in CertificateUserIds: Sintassi: Certutil –dump –v [~certificate path~] >> [~dumpFile path~] Esempio: certutil -dump -v firstusercert.cer >> firstCertDump.txt	certificateUserIds	affinità elevata

Definire l'associazione di affinità a livello di tenant ed eseguire l'override con regole personalizzate (anteprima)

Con questa funzionalità un criterio di autenticazione Amministrazione istrator può configurare se un utente può essere autenticato usando il mapping di associazione di nome utente a bassa affinità o affinità elevata. È possibile impostare l'associazione di affinità obbligatoria per il tenant, che si applica a tutti gli utenti. È anche possibile eseguire l'override del valore predefinito a livello di tenant creando regole personalizzate in base all'OID autorità di certificazione e ai criteri o all'OID criteri o all'autorità emittente.

Come Microsoft Entra ID risolve più regole di associazione di criteri nome utente

Usare l'associazione con priorità più alta (numero più basso).

1. Cercare l'oggetto utente usando il nome utente o il nome dell'entità utente.
2. Ottenere l'elenco di tutte le associazioni nome utente configurate dall'amministratore tenant nella configurazione del metodo di autenticazione CBA ordinata dall'attributo 'priority'. Oggi il concetto di priorità non è esposto nell'esperienza utente del portale. Graph restituirà l'attributo priority per ogni associazione e verranno usati nel processo di valutazione.
3. Se il tenant ha l'associazione di affinità elevata abilitata o se il valore del certificato corrisponde a una regola personalizzata che richiede l'associazione di affinità elevata, rimuovere tutte le associazioni di affinità bassa dall'elenco.
4. Valutare ogni associazione nell'elenco fino a quando non si verifica un'autenticazione corretta.
5. Se il campo certificato X.509 dell'associazione configurata si trova nel certificato presentato, l'ID Microsoft Entra corrisponde al valore nel campo certificato al valore dell'attributo dell'oggetto utente.
   1. Se viene trovata una corrispondenza, l'autenticazione utente ha esito positivo.
   2. Se non viene trovata una corrispondenza, passare all'associazione di priorità successiva.
6. Se il campo certificato X.509 non è presente nel certificato presentato, passare all'associazione di priorità successiva.
7. Convalidare tutte le associazioni di nome utente configurate fino a quando una di esse non restituisce una corrispondenza e l'autenticazione dell'utente ha esito positivo.
8. Se non viene trovata una corrispondenza in nessuna delle associazioni di nome utente configurate, l'autenticazione utente non riesce.

Protezione della configurazione di Microsoft Entra con più associazioni nome utente

Ogni attributo dell'oggetto utente di Microsoft Entra (userPrincipalName, onPremiseUserPrincipalName, certificateUserIds) disponibile per associare i certificati agli account utente di Microsoft Entra ha un vincolo univoco per garantire che un certificato corrisponda solo a un singolo account utente di Microsoft Entra. Tuttavia, Microsoft Entra CBA supporta più metodi di associazione nel criterio di associazione nome utente che consente a un amministratore di supportare un certificato a più configurazioni degli account utente Entra.

Importante

Se si configurano più associazioni, l'autenticazione CBA di Microsoft Entra è sicura solo come l'associazione di affinità più bassa perché L'autorità di certificazione convalida ogni associazione per autenticare l'utente. Per evitare uno scenario in cui un singolo certificato corrisponde a più account Microsoft Entra, un criterio di autenticazione Amministrazione istrator può:

• Configurare un singolo metodo di associazione nei criteri di associazione nome utente.
• Se un tenant dispone di più metodi di associazione configurati e non vuole consentire il mapping di un certificato a più account, i criteri di autenticazione Amministrazione istrator devono garantire che tutti i metodi consentiti configurati nel mapping dei criteri allo stesso account Microsoft Entra. Tutti gli account utente devono avere valori corrispondenti a tutte le associazioni.
• Se un tenant dispone di più metodi di associazione configurati, i criteri di autenticazione Amministrazione istrator devono assicurarsi che non dispongano di più di un'associazione di affinità bassa.

Si supponga, ad esempio, di avere due associazioni nome utente per PrincipalName mappate a UPN e SubjectKeyIdentifier (SKI) a certificateUserIds. Se si vuole usare un certificato solo per un singolo account, un criterio di autenticazione Amministrazione istrator deve assicurarsi che l'account abbia l'UPN presente nel certificato e implementare il mapping SKI nell'attributo certificateUserId dello stesso account.

Supporto per più certificati con un account utente Entra (M:1)

Esistono scenari in cui un'organizzazione rilascia più certificati per una singola identità. In genere, questa potrebbe essere una credenziale derivata per un dispositivo mobile o può essere anche per una smart card secondaria o un dispositivo con supporto delle credenziali x509, ad esempio yubikey.

Account solo cloud Per gli account solo cloud è possibile eseguire il mapping di più certificati (fino a 5) da usare popolando il campo certificateUserIds (informazioni di autorizzazione nel portale utenti) con valori univoci che identificano ogni certificato. Se l'organizzazione usa associazioni di affinità elevata, ad esempio Issuer + SerialNumber, i valori all'interno di CertificateUserIds possono essere simili ai seguenti:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>c11154138u089b48767212a86cd0ef76

In questo esempio il primo valore rappresenta X509Certificate1 e il secondo valore rappresenta X509Certificate2. L'utente può presentare un certificato all'accesso e, a condizione che l'associazione del nome utente CBA sia impostata in modo che punti al campo certificateUserIds per cercare il tipo di associazione specifico (ad esempio Issuer+SerialNumber in questo esempio), l'utente eseguirà correttamente l'accesso.

Account sincronizzati ibridi Per gli account sincronizzati è possibile eseguire il mapping di più certificati da usare popolando il campo altSecurityIdentities in AD i valori che identificano ogni certificato. Se l'organizzazione usa associazioni ad alta affinità (ad esempio l'autenticazione avanzata), ad esempio Issuer + SerialNumber, questo potrebbe essere simile al seguente:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>c11154138u089b48767212a86cd0ef76

In questo esempio il primo valore rappresenta X509Certificate1 e il secondo valore rappresenta X509Certificate2. Questi valori devono quindi essere sincronizzati con il campo certificateUserIds in Azure AD.

Supporto per un certificato con più account utente Entra (1:M)

Esistono scenari in cui un'organizzazione richiede all'utente di usare lo stesso certificato per l'autenticazione in più identità. In genere si tratta di account amministrativi. Può anche essere per gli account per sviluppatore o per gli account temporanei. In ACTIVE Directory tradizionale viene usato il campo altSecurityIdentities per popolare i valori del certificato e viene usato un hint durante l'accesso per indirizzare AD all'account desiderato per verificare la presenza dell'account di accesso. Con Microsoft Entra CBA questo è diverso e non c'è hint. L'individuazione dell'area di autenticazione principale identifica invece l'account desiderato per controllare i valori del certificato. L'altra differenza fondamentale è che Microsoft Entra CBA applica l'univocità nel campo certificateUserIds. Ciò significa che due account non possono popolare gli stessi valori di certificato.

Importante

Non è una configurazione molto sicura per usare le stesse credenziali per l'autenticazione in account ENTRA ID diversi ed è consigliabile non consentire un certificato per più account utente Entra.

Account solo cloud Per gli account solo cloud è necessario creare più associazioni di nome utente ed eseguire il mapping di valori univoci a ogni account utente che utilizza il certificato. Ogni account verrà autenticato usando un'associazione nome utente diversa. Questo vale entro il limite di una singola directory/tenant (ad esempio, l'amministratore tenant può eseguire il mapping del certificato per l'uso in un'altra directory/tenant, purché i valori rimangano univoci anche per ogni account).

Popolare il campo certificateUserIds (Informazioni di autorizzazione nel portale utenti) con un valore univoco che identifica il certificato desiderato. Se l'organizzazione usa associazioni ad alta affinità (ad esempio l'autenticazione avanzata), ad esempio Issuer + SerialNumber e SKI, questo potrebbe essere simile al seguente:

Associazioni di nome utente:

• Issuer + Serial Number -> CertificateUserIds
• SKI -> CertificateUserIds

Valori CertificateUserIds dell'account utente:
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523

A questo punto, quando uno degli utenti presenta lo stesso certificato all'accesso, l'utente accederà correttamente perché l'account corrisponde a un valore univoco per tale certificato. Un account verrà autenticato usando Issuer+SerialNumber e l'altro utilizzando l'associazione SKI.

Nota

Il numero di account che possono essere usati in questo modo è limitato dal numero di associazioni nome utente configurate nel tenant. Se l'organizzazione usa solo associazioni di affinità elevata, il numero di account supportati sarà limitato a 3. Se l'organizzazione usa anche associazioni di affinità bassa, questo numero aumenta a 7 account (1 PrincipalName, 1 RFC822Name, 1 SubjectKeyIdentifier, 1 SHA1PublicKey, 1 Issuer+Subject, 1 Issuer+SerialNumber, 1 Subject).

Account sincronizzati ibridi Per gli account sincronizzati l'approccio sarà diverso. Anche se l'amministratore tenant può eseguire il mapping di valori univoci a ogni account utente che utilizza il certificato, la pratica comune di popolare tutti i valori per ogni account in Entra ID renderebbe difficile questa operazione. Al contrario, Azure AD Connessione deve filtrare i valori desiderati per account in base ai valori univoci popolati nell'account in ENTRA ID. La regola di univocità si applica entro il limite di una singola directory/tenant (ad esempio, l'amministratore tenant può eseguire il mapping del certificato per l'uso in un'altra directory/tenant, purché i valori rimangano univoci anche per ogni account). Inoltre, l'organizzazione può avere più foreste di Active Directory che contribuiscono agli utenti in un singolo tenant entra ID. In questo caso, Azure AD Connessione applicherà il filtro a ognuna di queste foreste di Active Directory con lo stesso obiettivo di popolare solo un valore univoco desiderato per l'account cloud.

Popolare il campo altSecurityIdentities in AD con i valori che identificano il certificato desiderato e includere il valore del certificato desiderato per il tipo di account utente,ad esempio detailee, admin, developer e così via. Selezionare un attributo chiave in AD che indicherà alla sincronizzazione il tipo di account utente che l'utente sta valutando(ad esempio msDS-cloudExtensionAttribute1). Popolare questo attributo con il valore del tipo di utente desiderato, ad esempio dettaglio, amministratore o sviluppatore. Se si tratta dell'account primario dell'utente, il valore può essere lasciato vuoto/null.

Gli account potrebbero avere un aspetto simile al seguente:

Foresta 1 - Account1 (bob@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

Foresta 1 - Account2 (bob-admin@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

Foresta 2 - ADAccount1 (bob-tdy@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

Questi valori devono quindi essere sincronizzati con il campo certificateUserIds in Entra ID.

Passaggi per la sincronizzazione con certificateUserIds

1. Configurare Azure AD connect per aggiungere il campo alternativeSecurityIds al Metaverse
2. Per ogni foresta di Active Directory configurare una nuova regola in ingresso personalizzata con una precedenza elevata (numero basso inferiore a 100). Aggiungere una trasformazione Expression con il campo altSecurityIdentities come origine. L'espressione di destinazione userà l'attributo chiave selezionato e popolato, nonché il mapping ai tipi utente definiti.
3. Ad esempio:

IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer"))>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    Where($item,[altSecurityIdentities],(BitAnd(InStr($item, "X509:<I>"),InStrRev($item, "<SR>"))>0)), NULL) 
)

Nell'esempio precedente, altSecurityIdentities e l'attributo chiave msDS-cloudExtensionAttribute1is vengono prima controllati per verificare se sono popolati. In caso contrario, altSecurityIdentities viene controllato per verificare se è popolato. Se è vuoto, lo impostiamo su NULL. In caso contrario, l'account rientra nel caso predefinito e in questo esempio viene filtrato solo il mapping Issuer+SerialNumber. Se l'attributo chiave viene popolato, il valore viene controllato per verificare se è uguale a uno dei tipi di utente definiti. In questo esempio se tale valore è detailee, viene applicato un filtro al valore SHA1PublicKey da altSecurityIdentities. Se il valore è sviluppatore, viene applicato un filtro al valore SubjectKeyIssuer da altSecurityIdentities. Possono essere presenti più valori di certificato di un tipo specifico. Ad esempio, più valori PrincipalName o più valori SKI o SHA1-PUKEY. Il filtro otterrà tutti i valori e si sincronizzerà in Entra ID, non solo il primo trovato.

1. Un secondo esempio che mostra come eseguire il push di un valore vuoto se l'attributo del controllo è vuoto è riportato di seguito.

IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer")>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    AuthoritativeNull, NULL) 
) 

Se il valore in altSecurityIdentities non corrisponde ad alcuno dei valori di ricerca nell'attributo del controllo, viene passato un valore AuthoritativeNull. In questo modo si garantisce che le regole precedenti o successive che popolano alternativeSecurityId vengano ignorate e che il risultato sia vuoto in Entra ID.

1. Configurare una nuova regola in uscita personalizzata con una precedenza bassa (numero elevato superiore a 160 - parte inferiore dell'elenco).
2. Aggiungere una trasformazione diretta con il campo alternativeSecurityIds come origine e il campo certificateUserIds come destinazione.
3. Eseguire un ciclo di sincronizzazione per completare il popolamento dei dati in ENTRA ID.

Assicurarsi che L'autorità di certificazione in ogni tenant sia configurata con le associazioni nome utente che puntano al campo certificateUserIds per i tipi di campo mappati dal certificato. Ora uno di questi utenti può presentare il certificato all'accesso e dopo la convalida del valore univoco del certificato rispetto al campo certificateUserIds, l'utente verrà connesso correttamente.

Informazioni sul processo di revoca dei certificati

Il processo di revoca dei certificati consente all'amministratore di revocare un certificato rilasciato in precedenza dall'uso per l'autenticazione futura. La revoca del certificato non revoca i token già emessi dell'utente. Seguire la procedura per revocare manualmente i token in Configurare la revoca.

Microsoft Entra ID scarica e memorizza nella cache l'elenco di revoche di certificati (CRL) dei clienti dall'autorità di certificazione per verificare se i certificati vengono revocati durante l'autenticazione dell'utente.

Un amministratore può configurare il punto di distribuzione CRL durante il processo di configurazione delle autorità emittenti attendibili nel tenant di Microsoft Entra. Ogni autorità emittente attendibile deve avere un CRL a cui è possibile fare riferimento usando un URL con connessione Internet.

Importante

Le dimensioni massime di un CRL per Microsoft Entra ID da scaricare correttamente in un accesso interattivo e la cache sono pari a 20 MB nell'ID Entra pubblico e 45 MB nei cloud di Azure US Government e il tempo necessario per scaricare il CRL non deve superare i 10 secondi. Se Microsoft Entra ID non riesce a scaricare un CRL, le autenticazioni basate su certificati tramite certificati rilasciati dalla CA corrispondente hanno esito negativo. Come procedura consigliata per mantenere i file CRL entro i limiti di dimensioni, mantenere la durata dei certificati entro limiti ragionevoli e pulire i certificati scaduti. Per altre informazioni, vedere Esiste un limite per le dimensioni CRL?.

Quando un utente esegue un accesso interattivo con un certificato e il CRL supera il limite interattivo per un cloud, l'accesso iniziale ha esito negativo con l'errore seguente:

"L'elenco di revoche di certificati (CRL) scaricato da {uri} ha superato le dimensioni massime consentite ({size} byte) per i CRL in Microsoft Entra ID. Riprovare in pochi minuti. Se il problema persiste, contattare gli amministratori tenant."

Dopo l'errore, Microsoft Entra ID tenta di scaricare il CRL soggetto ai limiti lato servizio (45 MB nell'ID Entra pubblico e 150 MB nei cloud di Azure US Government).

Importante

Se l'amministratore ignora la configurazione del CRL, l'ID Microsoft Entra non esegue alcun controllo CRL durante l'autenticazione basata su certificato dell'utente. Questo può essere utile per la risoluzione dei problemi iniziale, ma non deve essere considerato per l'uso in produzione.

A partire dal momento, non è supportato Online Certificate Status Protocol (OCSP) a causa di motivi di prestazioni e affidabilità. Invece di scaricare il CRL a ogni connessione dal browser client per OCSP, Microsoft Entra ID scarica una volta al primo accesso e lo memorizza nella cache, migliorando così le prestazioni e l'affidabilità della verifica CRL. La cache viene indicizzata anche in modo che la ricerca sia molto più veloce ogni volta. I clienti devono pubblicare CRL per la revoca dei certificati.

I passaggi seguenti sono un flusso tipico del controllo CRL:

1. Microsoft Entra ID tenta di scaricare il CRL al primo evento di accesso di qualsiasi utente con un certificato dell'autorità di certificazione o dell'autorità di certificazione attendibile corrispondente.
2. Microsoft Entra ID memorizza nella cache e riutilizza il CRL per qualsiasi utilizzo successivo. Rispetta la data di aggiornamento successivo e, se disponibile, data di pubblicazione CRL successiva (usata dalle CA di Windows Server) nel documento CRL.
3. L'autenticazione basata su certificato utente ha esito negativo se:

   • Un CRL è stato configurato per l'emittente attendibile e l'ID Microsoft Entra non può scaricare il CRL, a causa di vincoli di disponibilità, dimensioni o latenza.

   • Il certificato dell'utente viene elencato come revocato nel CRL.

     

   • Microsoft Entra ID tenta di scaricare un nuovo CRL dal punto di distribuzione se il documento CRL memorizzato nella cache è scaduto.

Nota

Microsoft Entra ID controlla il CRL della CA emittente e di altri ca nella catena di attendibilità PKI fino alla CA radice. È previsto un limite massimo di 10 ca dal certificato client foglia per la convalida CRL nella catena PKI. La limitazione consiste nel garantire che un attore non valido non arresti il servizio caricando una catena PKI con un numero enorme di ca con dimensioni CRL maggiori. Se la catena PKI del tenant ha più di 5 CA e in caso di compromissione della CA, l'amministratore deve rimuovere l'autorità emittente attendibile compromessa dalla configurazione del tenant di Microsoft Entra.

Importante

A causa della natura dei cicli di memorizzazione nella cache e pubblicazione di CRL, è consigliabile in caso di revoca del certificato per revocare anche tutte le sessioni dell'utente interessato in Microsoft Entra ID.

A partire dal momento, non è possibile forzare manualmente o ritentare il download del CRL.

Come configurare la revoca

Per revocare un certificato client, Microsoft Entra ID recupera l'elenco di revoche di certificati (CRL) dagli URL caricati come parte delle informazioni dell'autorità di certificazione e lo memorizza nella cache. L'ultimo timestamp di pubblicazione, ovvero la proprietàEffective Date (Data di validità), in CRL viene usato per assicurare la validità di CRL. Il CRL viene referenziato periodicamente per revocare l'accesso ai certificati che fanno parte dell'elenco.

Se è necessaria una revoca più immediata (ad esempio in caso di smarrimento del dispositivo da parte di un utente), il token di autorizzazione dell'utente può essere annullato. Per annullare il token di autorizzazione, impostare il campo StsRefreshTokenValidFrom per questo particolare utente usando Windows PowerShell. È necessario aggiornare il campo StsRefreshTokenValidFrom per ogni utente a cui revocare l'accesso.

Per fare in modo che la revoca persista, è necessario impostare la proprietà Effective Date (Data di validità) di CRL su una data successiva al valore impostato da StsRefreshTokenValidFrom e assicurarsi che il certificato in questione sia in CRL.

Nota

I moduli Azure AD e MSOnline PowerShell sono deprecati a partire dal 30 marzo 2024. Per maggiori informazioni, leggere l'aggiornamento sulla deprecazione. Dopo questa data, il supporto per questi moduli è limitato all'assistenza alla migrazione a Microsoft Graph PowerShell SDK e alle correzioni di sicurezza. I moduli deprecati continueranno a funzionare fino al 30 marzo 2025.

È consigliabile eseguire la migrazione a Microsoft Graph PowerShell per interagire con Microsoft Entra ID (in precedenza Azure AD). Per domande comuni sulla migrazione, consultare le Domande frequenti sulla migrazione. Nota: le versioni 1.0.x di MSOnline potrebbero subire interruzioni dopo il 30 giugno 2024.

I passaggi seguenti illustrano il processo per aggiornare e annullare il token di autorizzazione impostando il campo StsRefreshTokenValidFrom .

1. Connessione a PowerShell:

   Connect-MgGraph
   

2. Recuperare il valore StsRefreshTokensValidFrom corrente per un utente:

           $user = Get-MsolUser -UserPrincipalName test@yourdomain.com`
           $user.StsRefreshTokensValidFrom
   

3. Configurare un nuovo valore StsRefreshTokensValidFrom per l'utente uguale al timestamp corrente:

           Set-MsolUser -UserPrincipalName test@yourdomain.com -StsRefreshTokensValidFrom ("03/05/2021")
   

La data impostata deve essere futura. Se la data non è futura, la proprietà StsRefreshTokensValidFrom non viene impostata. Se la data è futura, la proprietà StsRefreshTokensValidFrom viene impostata sull'ora corrente, non sulla data indicata dal comando Set-MsolUser.

Funzionamento dell'autorità di certificazione con criteri di attendibilità dell'autenticazione dell'accesso condizionale

I clienti possono creare un criterio di attendibilità dell'autenticazione dell'accesso condizionale per specificare che l'autorità di certificazione deve essere usata per accedere a una risorsa.

È possibile usare il livello di autenticazione MFA predefinito resistente al phishing. Questo criterio consente solo metodi di autenticazione resistenti al phishing come CBA, chiavi di sicurezza FIDO2 e Windows Hello for Business.

È anche possibile creare un livello di autenticazione personalizzato per consentire solo all'autorità di certificazione di accedere alle risorse sensibili. È possibile consentire l'autenticazione ABA come singolo fattore, multifactoring o entrambi. Per altre informazioni, vedere Livello di autenticazione dell'accesso condizionale.

Livello di autenticazione CBA con opzioni avanzate

Nei criteri dei metodi di autenticazione CBA, un amministratore può determinare il livello di attendibilità del certificato usando i criteri di associazione di autenticazione nel metodo CBA. È ora possibile configurare le opzioni avanzate quando si crea un livello di autenticazione personalizzato per richiedere l'uso di un certificato specifico, in base agli OID dell'autorità emittente e dei criteri, quando gli utenti eseguono LBA per accedere a determinate risorse sensibili. Questa funzionalità offre una configurazione più precisa per determinare i certificati e gli utenti che possono accedere alle risorse. Per altre informazioni, vedere Opzioni avanzate per il livello di autenticazione dell'accesso condizionale.

Informazioni sui log di accesso

I log di accesso forniscono informazioni sugli accessi e sul modo in cui le risorse vengono usate dagli utenti. Per altre informazioni sui log di accesso, vedere Log di accesso in Microsoft Entra ID.

Verranno ora illustrati due scenari, uno in cui il certificato soddisfa l'autenticazione a singolo fattore e un altro in cui il certificato soddisfa l'autenticazione a più fattori.

Per gli scenari di test, scegliere un utente con criteri di accesso condizionale che richiedono l'autenticazione a più fattori. Configurare i criteri di associazione utente eseguendo il mapping del nome dell'entità SAN a UserPrincipalName.

Il certificato utente deve essere configurato come questo screenshot:

Risoluzione dei problemi di accesso con le variabili dinamiche nei log di accesso

Anche se i log di accesso forniscono tutte le informazioni per eseguire il debug dei problemi di accesso di un utente, esistono momenti in cui sono necessari valori specifici e poiché i log di accesso non supportano variabili dinamiche, i log di accesso avrebbero informazioni mancanti. Ad esempio: il motivo dell'errore nel log di accesso dovrebbe essere simile a "L'elenco di revoche di certificati (CRL) non è riuscito a convalidare la firma. L'identificatore di chiave del soggetto previsto {expectedSKI} non corrisponde alla chiave dell'autorità CRL {crlAK}. Richiedere all'amministratore del tenant di controllare la configurazione CRL." in cui {expectedSKI} e {crlAKI} non vengono popolati con valori corretti.

Quando l'accesso degli utenti con CBA ha esito negativo, copiare i dettagli del log dal collegamento "Altri dettagli" nella pagina dell'errore. Per informazioni più dettagliate, vedere la pagina di errore dell'autorità di certificazione

Testare l'autenticazione a fattore singolo

Per il primo scenario di test, configurare i criteri di autenticazione in cui la regola soggetto autorità di certificazione soddisfa l'autenticazione a fattore singolo.

1. Accedere all'interfaccia di amministrazione di Microsoft Entra come utente di test usando CBA. I criteri di autenticazione vengono impostati in cui la regola dell'oggetto autorità di certificazione soddisfa l'autenticazione a fattore singolo.

2. Cercare e selezionare Log di accesso.

   Verranno ora esaminate più in dettaglio alcune delle voci disponibili nei log di accesso.

   La prima voce richiede il certificato X.509 dall'utente. Lo stato Interrotto indica che l'ID Entra di Microsoft ha convalidato che L'autorità di certificazione è abilitata nel tenant e che viene richiesto un certificato per l'autenticazione.

   

   I dettagli attività mostrano che questa è solo parte del flusso di accesso previsto in cui l'utente seleziona un certificato.

   

   I dettagli aggiuntivi mostrano le informazioni sul certificato.

   

   Queste voci aggiuntive mostrano che l'autenticazione è stata completata, un token di aggiornamento primario viene inviato al browser e all'utente viene concesso l'accesso alla risorsa.

   

Testare l'autenticazione a più fattori

Per lo scenario di test successivo, configurare i criteri di autenticazione in cui la regola policyOID soddisfa l'autenticazione a più fattori.

1. Accedere all'interfaccia di amministrazione di Microsoft Entra con CBA. Poiché i criteri sono stati impostati per soddisfare l'autenticazione a più fattori, l'accesso dell'utente ha esito positivo senza un secondo fattore.

2. Cercare e selezionare Accessi.

   Nei log di accesso verranno visualizzate diverse voci, tra cui una voce con stato Interrotto .

   

   I dettagli attività mostrano che questa è solo parte del flusso di accesso previsto in cui l'utente seleziona un certificato.

   

   La voce con stato Interrotto contiene altre informazioni di diagnostica nella scheda Dettagli aggiuntivi.

   

   Nella tabella seguente è presente una descrizione di ogni campo.

   Campo	Descrizione
   Nome soggetto certificato utente	Fa riferimento al campo del nome soggetto nel certificato.
   Associazione di certificati utente	Certificato: Nome entità; Attributo utente: userPrincipalName; Classificazione: 1 Viene illustrato il campo certificato SAN PrincipalName mappato all'attributo utente userPrincipalName e la priorità 1.
   Livello di autenticazione del certificato utente	multiFactorAuthentication
   Tipo di livello di autenticazione del certificato utente	PolicyId Questo mostra l'OID dei criteri usato per determinare il livello di attendibilità dell'autenticazione.
   Identificatore del livello di autenticazione del certificato utente	1.2.3.4 Viene visualizzato il valore dell'OID dei criteri di identificatore del certificato.

Informazioni sulla pagina degli errori di autenticazione basata su certificati

L'autenticazione basata su certificati può non riuscire per motivi quali il certificato non valido o l'utente ha selezionato il certificato errato o un certificato scaduto o a causa di un problema di elenco di revoche di certificati . Quando la convalida del certificato ha esito negativo, l'utente visualizza questo errore:

Se il CBA non riesce in un browser, anche se l'errore è dovuto all'annullamento della selezione certificati, è necessario chiudere la sessione del browser e aprire una nuova sessione per riprovare. È necessaria una nuova sessione perché i browser memorizzano nella cache il certificato. Quando l'autorità di certificazione viene ritentata, il browser invia il certificato memorizzato nella cache durante la richiesta TLS, che causa un errore di accesso e l'errore di convalida.

Selezionare Altri dettagli per ottenere informazioni di registrazione che possono essere inviate a un amministratore, che a loro volta possono ottenere altre informazioni dai log di accesso.

Selezionare Altri modi per accedere per provare altri metodi disponibili per l'accesso dell'utente.

Nota

Se si ritenta l'autenticazione ABA in un browser, l'operazione non riesce a causa del problema di memorizzazione nella cache del browser. Gli utenti devono aprire una nuova sessione del browser e accedere di nuovo.

Autenticazione basata su certificati nei metodi MostRecentlyUsed (MRU)

Dopo che un utente esegue correttamente l'autenticazione con LBA, il metodo di autenticazione MostRecentlyUsed (MRU) dell'utente è impostato su CBA. Ora successiva, quando l'utente immette il proprio UPN e seleziona Avanti, l'utente viene impiegato direttamente nel metodo CBA e non deve selezionare Usa il certificato o la smart card.

Per reimpostare il metodo MRU, l'utente deve annullare la selezione certificati, selezionare Altri modi per accedere e selezionare un altro metodo disponibile per l'utente e autenticarsi correttamente.

Supporto delle identità esterne

Un'identità esterna non può eseguire l'autenticazione a più fattori nel tenant delle risorse con Microsoft Entra CBA. Chiedere invece all'utente di eseguire l'autenticazione a più fattori usando L'autenticazione a più fattori nel tenant principale e configurare le impostazioni tra tenant per il tenant delle risorse per considerare attendibile l'autenticazione a più fattori dal tenant principale.

Per altre informazioni su come abilitare l'autenticazione a più fattori attendibili dai tenant di Microsoft Entra, vedere Configurare l'accesso tra tenant di Collaborazione B2B.

Passaggi successivi

• Panoramica di Microsoft Entra CBA
• Come configurare Microsoft Entra CBA
• Microsoft Entra CBA nei dispositivi iOS
• Microsoft Entra CBA nei dispositivi Android
• Accesso tramite smart card di Windows con Microsoft Entra CBA
• ID utente certificato
• Come eseguire la migrazione di utenti federati
• Domande frequenti
• Risolvere i problemi relativi a Microsoft Entra CBA