Approfondimento tecnico sull'autenticazione basata su certificati Microsoft Entra

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

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 dov'è abilitato Microsoft Entra CBA.

A questo punto verrà illustrato ogni passaggio:

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

2. Se l'utente non ha già eseguito l'accesso, 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, 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 CBA è abilitato 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 Come abilitare Microsoft Entra CBA.

   Nota

   Se 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 l'accesso tramite telefono o le chiavi 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, che è https://certauth.login.microsoftonline.com per il Microsoft Entra ID 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 di accesso 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 *.certauth.login.microsoftonline.com 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 degli 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 abilitano gli hint dell'autorità di certificazione.

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

   

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 fa accedere 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 l'utente è già registrato.

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.

Informazioni sugli hint dell'autorità di certificazione (anteprima)

Gli hint dell'autorità di certificazione inviano un'indicazione CA attendibile come parte dell'handshake TLS. L'elenco CA attendibile è impostato sull'oggetto delle autorità di certificazione (CA) caricate dal tenant nell'archivio attendibilità Entra. I browser client o i client di applicazioni native usano gli hint restituiti dal server per filtrare i certificati visualizzati nella selezione certificati. Il client mostra solo i certificati di autenticazione rilasciati dalle autorità di certificazione nell'archivio attendibilità.

Abilitare gli hint dell'autorità di certificazione

Per abilitare l'opzione, fare clic sulla casella di controllo degli Hint dell'autorità di certificazione. Gli amministratori dei criteri di autenticazione devono fare clic su Confermo dopo aver verificato che il proxy con l'ispezione TLS abilitato sia aggiornato correttamente e salvare.

Nota

Se l'organizzazione dispone di firewall o proxy con ispezione TLS, confermare di aver disabilitato l'ispezione TLS dell'endpoint certauth in grado di corrispondere a qualsiasi nome in [*.]certauth.login.microsoftonline.com, personalizzato in base al proxy specifico in uso.

Nota

L'URL dell'autorità di certificazione sarà di un formato t{tenantId}.certauth.login.microsoftonline.com dopo l'abilitazione degli hint dell'autorità di certificazione.

Propagazione degli aggiornamenti dell'archivio attendibilità CA

Dopo aver abilitato gli hint dell'autorità di certificazione e aver aggiunto, aggiornato o eliminato CA dallo stato di attendibilità, è presente un ritardo fino a 10 minuti per propagare nuovamente gli hint dell'autorità di certificazione al client. Gli utenti non possono eseguire l'autenticazione con i certificati rilasciati dalle nuove CA fino a quando non vengono propagati gli hint.

Gli amministratori dei criteri di autenticazione devono accedere con un certificato dopo aver abilitato gli hint dell'autorità di certificazione per avviare la propagazione. Gli utenti visualizzeranno il messaggio di errore seguente quando gli aggiornamenti dell'archivio attendibilità CA sono in propagazione.

Funzionalità di autenticazione MFA con autenticazione basata su certificati

Microsoft Entra CBA è in grado di eseguire l'autenticazione a più fattori (MFA). Microsoft Entra CBA può essere a fattore singolo (SF) o a più fattori (MF) a seconda della configurazione del tenant. L'abilitazione di CBA rende un utente potenzialmente in grado di completare l'autenticazione a più fattori. Un utente potrebbe avere bisogno di eseguire più configurazioni 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 a singolo fattore (SF) e deve completare l'autenticazione a più fattori:

1. Usare una password e un certificato SF.
2. Emettere un pass di accesso temporaneo.
3. L'amministratore dei criteri di autenticazione 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. Emettere un pass di accesso temporaneo.
2. L'amministratore dei criteri di autenticazione 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 in un dispositivo mobile senza supporto per smart card e deve completare l'autenticazione a più fattori:

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

Autenticazione a più fattori basata su certificati a singolo fattore

Microsoft Entra CBA è supportato sia come primo fattore che come fattore selcond per l'autenticazione. Alcune delle combinazioni supportate sono:

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

Nota

L'autorità di certificazione come secondo fattore in iOS presenta problemi noti e viene bloccata in iOS. Microsoft sta lavorando per risolvere i problemi e deve essere supportato in iOS.

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

Importante

Un utente è considerato in grado di supportare l'autenticazione a più fattori quando è incluso nelle impostazioni del metodo CBA. Ciò significa che l'utente non può usare l'identificazione 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, consultare Autenticazione a più fattori di Microsoft Entra.

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

Perché l'accesso senza password funzioni, gli utenti devono disabilitare le notifiche legacy tramite l'app per dispositivi mobili.

1. Accedere all'Interfaccia di amministrazione di Microsoft Entra almeno come Amministratore dei criteri di autenticazione.

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 di tutti i gruppi aggiunti per PSI su Senza password. Se si sceglie Qualsiasi, 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 l'accesso tramite telefono o le chiavi di sicurezza 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 (in questo caso l'accesso senza password). Selezionare Approva una richiesta nell'app Microsoft Authenticator.

   

5. Comparirà 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ì; l'utente può eseguire l'autenticazione e accedere.

Informazioni sui criteri di associazione dell'autenticazione

I criteri di associazione dell'autenticazione consentono di determinare la forza dell'autenticazione come fattore singolo o a più fattori. Gli amministratori dei criteri di autenticazione possono modificare il valore predefinito da fattore singolo a più fattori o configurare criteri personalizzati usando il soggetto dell'autorità di certificazione, l'OID dei criteri o i campi OID dell'autorità ed emittente nel certificato.

Forza del certificato

Gli amministratori dei criteri di autenticazione possono stabilire se la forza dei certificati è 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 gestione 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 i certificati. Tuttavia, un amministratore dei criteri di autenticazione deve assicurarsi che i certificati siano protetti con un PIN o una biometria per essere considerati 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'OID emittente + 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 + criteri hanno la precedenza sulle regole OID dei criteri. Le regole OID dei criteri hanno la precedenza sulle regole dell'autorità di certificazione.
2. Le regole OID dell'autorità di certificazione + criteri vengono valutate per prime. Se si dispone di una regola personalizzata con OID autorità di certificazione CA1 e 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 e avrà MFA.
3. Vengono quindi valutate le regole personalizzate che usano OID dei criteri. Se si dispone di un certificato A con OID dei criteri 1.2.3.4.5e una credenziale derivata B basata su tale certificato con un OID criteri 1.2.3.4.5.6e 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 riuscire l'autenticazione.
4. Se si verifica un conflitto tra più OID criteri (ad esempio quando un certificato ha due OID criteri, dove 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 CA.
6. Se in un certificato combaciano sia le regole OID dei criteri che le regole autorità di certificazione, l'OID dei criteri viene sempre controllato per primo e, se non viene trovata alcuna regola dei criteri, vengono controllate le associazioni dell'autorità di certificazione. L'OID dei criteri ha una priorità di associazione di autenticazione avanzata più elevata rispetto all'autorità di certificazione.
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à di certificazione 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 dei criteri di autenticazione di Microsoft Entra configura una regola dei criteri di autenticazione CBA usando sia l'emittente sia l'OID dei criteri influendo su alcuni scenari di registrazione dei dispositivi, tra cui:

• Iscrizione di Windows Hello For Business
• Registrazione della chiave di sicurezza Fido2
• Accesso a Windows tramite telefono senza password

La registrazione dei dispositivi con Workplace Join, Microsoft Entra ID e gli scenari dei dispositivi aggiunti a Microsoft Entra ibrido non sono interessati. Le regole dei criteri di autenticazione CBA che usano l'Autorità di certificazione OPPURE l’OID dei criteri non sono interessate. Per attenuare il problema, gli amministratori dei criteri di autenticazione devono:

• Modificare le regole dei criteri di autenticazione basate su certificati che usano attualmente sia l’opzione Autorità di certificazione sia OID dei criteri e rimuovi il requisito di Autorità di certificazione od OID e salva. OPPURE
• Rimuovere la regola dei criteri di autenticazione attuale che usa sia l'autorità di certificazione che L’OID dei criteri e creare regole usando solo l'autorità di certificazione o l’OID dei 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 alternativo del soggetto (SAN) dell'entità di sicurezza 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 della chiave del soggetto o una 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
SKI	X509:<SKI>aB1cD2eF3gH4iJ5kL6-mN7oP8qR=	certificateUserIds	high-affinity
SHA1PublicKey	X509:<SHA1-PUKEY>aB1cD2eF3gH4iJ5kL6-mN7oP8qR	certificateUserIds	high-affinity
IssuerAndSerialNumber (anteprima)	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT 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	high-affinity

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

Con questa funzionalità, un amministratore dei criteri di autenticazione può configurare se un utente può essere autenticato usando un mapping di associazione nome utente a bassa o alta affinità. È possibile impostare l'associazione di affinità richiesta 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 criteri o all'OID criteri o all'autorità di certificazione.

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 dei criteri di autenticazione nella configurazione del metodo di autenticazione CBA ordinata dall'attributo 'priority'. Oggi il concetto di priorità non è esposto nel portale UX. Graph restituirà l'attributo priority per ogni associazione e verrà usato 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 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 dei criteri di autenticazione di supportare un certificato a più configurazioni di account utente Microsoft Entra.

Importante

Se si configurano più associazioni, l'autenticazione CBA di Microsoft Entra è sicura solo come l'associazione di affinità più bassa perché CBA convalida ogni associazione per autenticare l'utente. Per evitare uno scenario in cui un singolo certificato corrisponde a più account Microsoft Entra, un amministratore dei criteri di autenticazione 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, l'amministratore dei criteri di autenticazione deve assicurarsi che tutti i metodi consentiti configurati nei criteri siano mappati allo stesso account Microsoft Entra. Tutti gli account utente devono avere valori corrispondenti a tutte le associazioni.
• Se un tenant ha più metodi di associazione configurati, l'amministratore dei criteri di autenticazione deve assicurarsi che non disponga 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 amministratore dei criteri di autenticazione deve assicurarsi che l'account abbia l'UPN presente nel certificato e implementi il mapping SKI nell'attributo certificateUserId dello stesso account.

Supporto per più certificati con un account utente Microsoft 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>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

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 (ovvero 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à (ovvero autenticazione avanzata), ad esempio Issuer + SerialNumber, potrebbe essere simile al seguente:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

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 Microsoft Entra ID.

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

Esistono scenari in cui un'organizzazione richiede all'utente di usare lo stesso certificato per l'autenticazione di più identità. In genere si tratta di account amministrativi. Può anche succedere per gli account per sviluppatori o account temporanei. In AD 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 non è così e non ci sono hint. L'individuazione dell'area di autenticazione principale, invece, identifica 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 usare le stesse credenziali per l'autenticazione in account Microsoft Entra diversi ed è consigliabile non consentire un certificato per più account utente Microsoft 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 (ovvero, l'amministratore dei criteri di autenticazione 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à (ovvero autenticazione avanzata), ad esempio Issuer + SerialNumber e SKI, 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>aB1cD2eF3gH4iJ5kL6-mN7oP8qR
X509:<SKI>cD2eF3gH4iJ5kL6mN7-oP8qR9sT

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 passa 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 dei criteri di autenticazione può eseguire il mapping di valori univoci a ogni account utente che utilizzerà il certificato, la procedura comune di popolare tutti i valori per ogni account in Microsoft Entra ID lo renderebbe difficile. Microsoft Entra Connect deve invece filtrare i valori desiderati per account in base ai valori univoci popolati nell'account in Microsoft Entra ID. La regola di univocità si applica entro il limite di una singola directory/tenant (ovvero l'amministratore dei criteri di autenticazione 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 potrebbe avere più foreste di Active Directory che forniscono gli utenti in un singolo tenant di Microsoft Entra. In questo caso, Microsoft Entra Connect 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 quale tipo di account utente sta valutando l'utente (ad esempio msDS-cloudExtensionAttribute1). Popolare questo attributo con il valore del tipo di utente desiderato, ad esempio dettailee, 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>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Foresta 1 - Account2 (bob-admin@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Foresta 2 - ADAccount1 (bob-tdy@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

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

Passaggi per la sincronizzazione con certificateUserIds

1. Configurare Microsoft Entra 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 Microsoft Entra ID, non solo il primo trovato.

1. Un secondo esempio che mostra come eseguire il push di un valore vuoto se l'attributo di 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 a nessuno dei valori di ricerca nell'attributo di 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 Microsoft 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 Microsoft 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 dei criteri di autenticazione di revocare l'uso di un certificato rilasciato in precedenza 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 Configuraaione della 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.

Gli amministratori dei criteri di autenticazione possono impostare 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 per 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 in MICROSOFT Entra ID 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 dopo alcuni 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 in Microsoft Entra ID pubblico e 150 MB nei cloud Azure per enti pubblici USA).

Importante

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

A partire da ora, Online Certificate Status Protocol (OCSP) non è supportato per motivi di prestazioni e affidabilità. Invece di scaricare il CRL a ogni connessione dal browser client per OCSP, Microsoft Entra ID lo 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, la 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 nella catena di certificati 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, gli amministratori dei criteri di autenticazione devono 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 da questo 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 (Certificate Revocation List o CRL) dagli URL caricati come parte delle informazioni sull'autorità di certificazione e li 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. Connettersi 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.

Informazioni sulla convalida CRL (anteprima)

Un CRL è un record di certificati digitali revocati prima della fine del periodo di validità da un'autorità di certificazione (CA). Quando le CA vengono caricate nell'archivio attendibilità di Microsoft Entra, un CRL, o più specificamente l'attributo CrlDistributionPoint, non è obbligatorio. È possibile caricare una CA senza un endpoint CRL e l'autenticazione basata su certificati non avrà esito negativo se una CA emittente non ha un CRL specificato.

Per rafforzare la sicurezza ed evitare configurazioni errate, un amministratore dei criteri di autenticazione può richiedere l'autenticazione CBA se non è configurato alcun CRL per una CA che rilascia un certificato utente finale.

Abilitare la convalida CRL

Per abilitare la convalida CRL, fare clic su Richiedi convalida CRL (scelta consigliata).

Dopo l'abilitazione, qualsiasi CBA avrà esito negativo perché il certificato dell'utente finale è stato emesso da una CA senza alcun CRL configurato.

Un amministratore dei criteri di autenticazione può esentare una CA se il relativo CRL presenta problemi che devono essere risolti. Fare clic su Aggiungi esenzione e selezionare eventuali CA che devono essere escluse.

Le CA nell'elenco esentato non devono avere CRL configurato e i certificati dell'utente finale che rilasciano non hanno esito negativo.

Nota

Si è verificato un problema noto con la selezione oggetto in cui gli elementi selezionati non vengono visualizzati correttamente. Usare la scheda Autorità di certificazione per selezionare o rimuovere le CA.

Funzionamento di CBA 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 CBA come singolo fattore, fattore multiplo 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 dei criteri di autenticazione può determinare il livello di attendibilità del certificato usando il criterio 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

Log di accesso fornisce 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, 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 della chiave del soggetto previsto {expectedSKI} non corrisponde alla chiave dell'autorità CRL {crlAK}. Richiedere all'amministratore del tenant di controllare la configurazione CRL." dove {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 le Informazioni sulla pagina di errore di CBA

Test dell'autenticazione a fattore singolo

Per il primo scenario di test, configurare i criteri di autenticazione in cui la regola del 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. Vengono impostati criteri di autenticazione dove la regola dell'oggetto autorità di certificazione soddisfa l'autenticazione a fattore singolo.

2. Cercare e selezionare i Log di accesso.

   Verranno ora esaminate più in dettaglio alcune delle voci disponibili nei logdi 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 dove 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 dove la regola policyOID soddisfa l'autenticazione a più fattori.

1. Accedere all'interfaccia di amministrazione di Microsoft Entra usando 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 dove 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 del soggetto del certificato utente	Fa riferimento al campo del nome soggetto nel certificato.
   Associazione del certificato 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 del 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 come il certificato non valido, l'utente che ha selezionato il certificato errato, un certificato scaduto o a causa di un problema di elenco di revoche di certificati (CRL). Quando la convalida del certificato ha esito negativo, l'utente visualizza questo errore:

Se CBA riscontra errori in un browser, anche se sono dovuti 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 CBA riprova, il browser invia il certificato memorizzato nella cache durante la sfida TLS, causando un errore di accesso e l'errore di convalida.

Selezionare Altri dettagli per ottenere informazioni di registrazione che possono essere inviate a un amministratore dei criteri di autenticazione e che a sua volta può 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 CBA 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. La volta successiva, quando l'utente immette il proprio UPN e seleziona Avanti, l'utente viene portato direttamente al 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 utente guest B2B con identità esterna può usare CBA nel tenant principale e se le impostazioni tra tenant per il tenant della risorsa sono configurate per considerare attendibile L'autenticazione MFA dal tenant principale, verrà rispettata l'autenticazione CBA dell'utente nel tenant principale. Per altre informazioni su come Considerare attendibile l’autenticazione a più fattori dai tenant di Microsoft Entra, vedere Configurare l'accesso tra tenant di Collaborazione B2B. L'autorità di certificazione nel tenant delle risorse non è ancora supportata.

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