Condividi tramite


Concetti tecnici relativi all'autenticazione basata su certificati Microsoft Entra

Questo articolo descrive i concetti tecnici per spiegare il funzionamento dell'autenticazione basata su certificati (CBA) di Microsoft Entra. Informazioni tecniche su come configurare e gestire il CBA di Microsoft Entra nel tenant.

Come funziona l'autenticazione basata su certificati Microsoft Entra?

La figura seguente illustra cosa accade quando un utente tenta di accedere a un'applicazione in un tenant in cui è configurato Microsoft Entra CBA.

Diagramma che mostra una panoramica dei passaggi descritti in Autenticazione basata su certificati Microsoft Entra.

I passaggi seguenti riepilogano il processo CBA di Microsoft Entra:

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

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

  3. Immettono il nome utente nella pagina di accesso di Microsoft Entra e quindi seleziona Avanti. Microsoft Entra ID completa l'individuazione dell'area di autenticazione principale usando il nome del tenant. Usa il nome utente per cercare l'utente nel tenant.

    Screenshot che mostra la pagina di accesso per il portale App personali.

  4. Microsoft Entra ID verifica se l'autenticazione ABA è configurata per il tenant. Se l'amministratore del servizio di certificazione è configurato, 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 L'autorità di certificazione sia configurata per il tenant.

    Per altre informazioni, vedere How do we turn on Microsoft Entra CBA?.

    Nota

    Se il CBA è configurato per il tenant, tutti gli utenti visualizzano il collegamento Usa un certificato o una smart card nella pagina di accesso alle password. Tuttavia, solo gli utenti inclusi nell'ambito di CBA possono eseguire correttamente l'autenticazione per un'applicazione che usa Microsoft Entra ID come provider di identità.

    Screenshot che mostra l'opzione per usare un certificato o una smart card.

    Se si rendono disponibili altri metodi di autenticazione, ad esempio l'accesso tramite telefono o le chiavi di sicurezza, gli utenti potrebbero visualizzare una finestra di dialogo di accesso diversa.

    Screenshot che mostra la finestra di dialogo di accesso se è disponibile anche l'autenticazione FIDO2.

  5. Dopo che l'utente ha selezionato L'autorità di certificazione, il client viene reindirizzato all'endpoint di autenticazione del certificato. Per l'ID Microsoft Entra pubblico, l'endpoint di autenticazione del certificato è https://certauth.login.microsoftonline.com. Per Azure per enti pubblici, l'endpoint di autenticazione del certificato è https://certauth.login.microsoftonline.us.

    L'endpoint esegue l'autenticazione reciproca TLS (Transport Layer Security) e richiede il certificato client come parte dell'handshake TLS. Nel log di accesso viene visualizzata una voce per questa richiesta.

    Nota

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

    Assicurarsi che la disattivazione dell'ispezione TLS funzioni anche per gli hint dell'autorità di certificazione con il nuovo URL. Non impostare come hardcoded l'URL con l'ID tenant. L'ID tenant potrebbe cambiare per gli utenti business-to-business (B2B). Usare un'espressione regolare per consentire il funzionamento dell'URL precedente e del nuovo URL quando si disattiva l'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'autorità di certificazione non riesce se si attivano gli hint dell'autorità emittente.

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

    Screenshot che mostra la selezione certificati.

  7. Microsoft Entra ID verifica l'elenco di revoche di certificati (CRL) per assicurarsi che il certificato non venga revocato e che 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 un utente univoco viene trovato tramite un criterio di accesso condizionale di Microsoft Entra che richiede l'autenticazione a più fattori (MFA) e la regola di associazione di autenticazione del certificato soddisfa l'autenticazione a più fattori, Microsoft Entra ID accede immediatamente all'utente. Se l'autenticazione a più fattori è obbligatoria, ma il certificato soddisfa solo un singolo fattore, se l'utente è già registrato, l'accesso senza password e FIDO2 viene offerto come secondo fattore.

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

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

Hint autorità di certificazione (anteprima)

Gli hint dell'autorità di certificazione inviano un indicatore ca attendibile come parte dell'handshake TLS. L'elenco ca attendibile viene impostato sull'oggetto delle ca caricate dal tenant nell'archivio attendibilità di Microsoft Entra. Un client browser o un client applicazione nativa può usare 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à.

Attivare i suggerimenti dell'autorità emittente

Per attivare gli hint dell'autorità emittente, selezionare la casella di controllo Hint autorità di certificazione . Un amministratore dei criteri di autenticazione deve selezionare Conferma dopo aver verificato che il proxy con ispezione TLS sia stato configurato correttamente e quindi salvare le modifiche.

Nota

Se l'organizzazione dispone di firewall o proxy che usano l'ispezione TLS, confermare che è stata disattivata l'ispezione TLS dell'endpoint CA in grado di corrispondere a qualsiasi nome in [*.]certauth.login.microsoftonline.com, personalizzato in base al proxy specifico in uso.

Screenshot che mostra come attivare gli hint dell'autorità emittente.

Nota

Dopo aver attivato gli hint dell'autorità di certificazione, l'URL della CA ha il formato <tenantId>.certauth.login.microsoftonline.com.

Screenshot che mostra la selezione certificati dopo l'attivazione degli hint dell'autorità emittente.

Propagazione degli aggiornamenti dell'archivio attendibilità CA

Dopo aver attivato gli hint dell'autorità emittente e aver aggiunto, aggiornato o eliminato ca dall'archivio attendibilità, potrebbe verificarsi un ritardo massimo di 10 minuti durante la propagazione degli hint dell'autorità emittente al client. Un amministratore dei criteri di autenticazione deve accedere con un certificato dopo che gli hint dell'autorità emittente sono resi disponibili per avviare la propagazione.

Gli utenti non possono eseguire l'autenticazione usando certificati rilasciati da nuove ca fino a quando non vengono propagati suggerimenti. Gli utenti visualizzano il messaggio di errore seguente quando vengono propagati gli aggiornamenti dell'archivio attendibilità CA:

Screenshot che mostra l'errore che gli utenti vedono se gli aggiornamenti sono in corso.

MFA con LBA a fattore singolo

Microsoft Entra CBA è qualificato sia per l'autenticazione a primo fattore che per l'autenticazione a secondo fattore.

Ecco alcune combinazioni supportate:

Gli utenti devono avere un modo per ottenere l'autenticazione a più fattori e registrare l'accesso senza password o FIDO2 prima dell'accesso tramite Microsoft Entra CBA.

Importante

Un utente è considerato in grado di supportare l'autenticazione a più fattori se il nome utente viene visualizzato nelle impostazioni del metodo CBA. In questo scenario, l'utente non può usare la propria identità 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.

Opzioni per ottenere la funzionalità MFA con CBA abilitato

L'autorità di certificazione Microsoft Entra può essere a fattore singolo o a più fattori a seconda della configurazione del tenant. L'attivazione del CBA rende un utente potenzialmente in grado di completare l'autenticazione a più fattori. Un utente con un certificato a singolo fattore o una password deve usare un altro fattore per completare l'autenticazione a più fattori.

Non è consentita la registrazione di altri metodi senza prima soddisfare l'autenticazione a più fattori. Se l'utente non ha un altro metodo MFA registrato ed è nell'ambito di CBA, l'utente non può usare la prova dell'identità per registrare altri metodi di autenticazione e ottenere l'autenticazione a più fattori.

Se l'utente con supporto per CBA ha solo un certificato a fattore singolo e deve completare l'autenticazione a più fattori, scegliere una di queste opzioni per autenticare l'utente:

  • L'utente può immettere una password e usare un certificato a singolo fattore.
  • Un amministratore dei criteri di autenticazione può eseguire un passaggio di accesso temporaneo.
  • Un amministratore dei criteri di autenticazione può aggiungere un numero di telefono e consentire l'autenticazione vocale o sms per l'account utente.

Se l'utente con supporto per CBA non ha emesso un certificato e deve completare l'autenticazione a più fattori, scegliere una di queste opzioni per autenticare l'utente:

  • Un amministratore dei criteri di autenticazione può eseguire un passaggio di accesso temporaneo.
  • Un amministratore dei criteri di autenticazione può aggiungere un numero di telefono e consentire l'autenticazione vocale o sms per l'account utente.

Se l'utente con supporto per CBA non può usare un certificato a più fattori, ad esempio se usa un dispositivo mobile senza supporto per smart card, ma deve completare l'autenticazione a più fattori, scegliere una di queste opzioni per autenticare l'utente:

  • Un amministratore dei criteri di autenticazione può eseguire un passaggio di accesso temporaneo.
  • L'utente può registrare un altro metodo MFA (quando l'utente può usare un certificato a più fattori in un dispositivo).
  • Un amministratore dei criteri di autenticazione può aggiungere un numero di telefono e consentire l'autenticazione vocale o sms per l'account utente.

Configurare l'accesso tramite telefono senza password con CBA

Per il funzionamento dell'accesso tramite telefono senza password, disattivare prima di tutto la notifica legacy tramite l'app per dispositivi mobili per l'utente.

  1. Accedere all'interfaccia di amministrazione di Microsoft Entra come almeno un amministratore dei criteri di autenticazione.

  2. Completare i passaggi descritti in Abilitare l'autenticazione dell'accesso tramite telefono senza password.

    Importante

    Assicurarsi di selezionare l'opzione Senza password . Per tutti i gruppi aggiunti all'accesso tramite telefono senza password, è necessario modificare il valore per la modalità di autenticazione in Senza password. Se si seleziona Qualsiasi, CBA e accesso senza password non funzionano.

  3. Selezionare Entra ID>Autenticazione a più fattori>Impostazioni aggiuntive di autenticazione a più fattori basata sul cloud.

    Screenshot che mostra come configurare le impostazioni MFA.

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

    Screenshot che mostra come rimuovere la notifica tramite l'opzione dell'app per dispositivi mobili.

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

Si consideri un esempio di utente che ha un certificato a fattore singolo ed è configurato per l'accesso senza password. Come utente, è necessario completare questi passaggi:

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

    Screenshot che mostra come immettere un nome dell'entità utente.

  2. Selezionare Usa un certificato o una smart card.

    Screenshot che mostra come accedere con un certificato.

    Se si rendono disponibili altri metodi di autenticazione, ad esempio l'accesso tramite telefono o le chiavi di sicurezza, gli utenti potrebbero visualizzare una finestra di dialogo di accesso diversa.

    Screenshot che mostra un modo alternativo per accedere con un certificato.

  3. Nella selezione certificati client selezionare il certificato utente corretto e quindi selezionare OK.

    Screenshot che mostra come selezionare un certificato.

  4. Poiché il certificato è configurato come livello di attendibilità dell'autenticazione a fattore singolo, è necessario un secondo fattore per soddisfare i requisiti di autenticazione a più fattori. I secondi fattori disponibili vengono visualizzati nella finestra di dialogo di accesso. In questo caso, si tratta di un accesso senza password. Selezionare Approva una richiesta nell'app Microsoft Authenticator.

    Screenshot che mostra il completamento di una richiesta di secondo fattore.

  5. Si riceve una notifica sul telefono. Selezionare Approva accesso?. Screenshot che mostra la richiesta di approvazione telefonica.

  6. In Microsoft Authenticator immettere il numero visualizzato nel browser o nell'app.

    Screenshot che mostra una corrispondenza numerica.

  7. Selezionare ed è possibile eseguire l'autenticazione e accedere.

Criteri di associazione di autenticazione

I criteri di associazione di autenticazione consentono di impostare l'attendibilità dell'autenticazione come fattore singolo o multifactoring. Un amministratore dei criteri di autenticazione può modificare il metodo predefinito da singolo fattore a più fattori. Un amministratore può anche configurare configurazioni di criteri personalizzate usando IssuerAndSubject, PolicyOIDo Issuer e PolicyOID nel certificato.

Livello di attendibilità del certificato

Gli amministratori dei criteri di autenticazione possono determinare se il livello di attendibilità del certificato è 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 ha un certificato a più fattori, può eseguire l'autenticazione a più fattori solo usando i certificati. Tuttavia, un amministratore dei criteri di autenticazione deve assicurarsi che i certificati siano protetti da un PIN o da una biometria da considerare a più fattori.

Più regole di associazione dei criteri di autenticazione

È possibile creare più regole dei criteri di associazione di autenticazione personalizzate usando attributi di certificato diversi. Un esempio consiste nell'usare l'emittente e l'OID dei criteri, o solo l'OID dei criteri o solo l'emittente.

La sequenza seguente determina il livello di protezione dell'autenticazione quando si sovrappongono regole personalizzate:

  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.
  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 con MFA, viene assegnata mfa solo il certificato A che soddisfa sia il valore dell'autorità di certificazione che l'OID 1.2.3.4.5 dei criteri.
  3. Vengono valutate le regole personalizzate che usano gli ID dei criteri. Se si dispone di un certificato A con l'OID dei criteri di 1.2.3.4.5 e una credenziale derivata B basata su tale certificato con un OID dei criteri di 1.2.3.4.5.6e la regola personalizzata viene definita come un OID dei criteri con il valore 1.2.3.4.5 MFA, solo il certificato A soddisfa L'autenticazione a più fattori. La credenziale B soddisfa solo l'autenticazione a singolo fattore. Se l'utente ha usato una credenziale derivata durante l'accesso ed è stato configurato per l'autenticazione a più fattori, 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 dei 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 valutate regole personalizzate che usano ca emittenti di autorità di certificazione. Se un certificato dispone di regole OID e OID dei criteri corrispondenti, l'OID dei criteri viene sempre controllato per primo. 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.
  6. Se un'autorità di certificazione è associata a MFA, tutti i certificati utente emessi dalla CA sono qualificati come MFA. La stessa logica si applica all'autenticazione a singolo fattore.
  7. Se un OID dei criteri viene associato a MFA, tutti i certificati utente che includono questo OID dei criteri come uno degli OID qualificano come MFA. Un certificato utente può avere più ID criteri.
  8. Un'autorità emittente di certificati può avere solo un'associazione di autenticazione avanzata valida, ovvero un certificato non può essere associato sia all'autenticazione a singolo fattore che a MFA.

Importante

Attualmente, in un problema noto che viene risolto, se un amministratore dei criteri di autenticazione crea una regola dei criteri CBA usando sia l'emittente che l'OID dei criteri, alcuni scenari di registrazione del dispositivo sono interessati.

Gli scenari interessati includono:

  • Registrazione di Windows Hello for Business
  • Registrazione della chiave di sicurezza FIDO2
  • Accesso tramite telefono senza password di Windows

La registrazione dei dispositivi con Workplace Join, l'ID Microsoft Entra e gli scenari aggiunti ibridi a Microsoft Entra non sono interessati. Le regole dei criteri CBA che usano l'autorità di certificazione o l'OID dei criteri non sono interessate.

Per attenuare il problema, un amministratore dei criteri di autenticazione deve completare una delle opzioni seguenti:

  • Modificare la regola dei criteri CBA che attualmente usa sia l'emittente che l'OID dei criteri per rimuovere l'autorità emittente o il requisito dell'ID criterio.
  • Rimuovere la regola dei criteri di autenticazione che attualmente usa sia l'autorità di certificazione che l'OID dei criteri e quindi creare una regola che usa solo l'emittente o l'OID dei criteri.

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à alternativo del soggetto nel certificato viene mappato all'attributo userPrincipalName dell'oggetto utente per identificare l'utente.

Ottenere una maggiore sicurezza usando associazioni di certificati

Microsoft Entra supporta sette metodi per l'uso di associazioni di certificati. In generale, i tipi di mapping sono considerati affinità elevata se sono basati su identificatori che non è possibile riutilizzare, ad esempio SubjectKeyIdentifier (SKI) o SHA1PublicKey. Questi identificatori forniscono una maggiore garanzia che sia possibile usare un solo certificato per autenticare un utente.

I tipi di mapping basati su nomi utente e indirizzi di posta elettronica sono considerati affinità bassa. 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 TIPO
PrincipalName X509:<PN>bob@woodgrove.com userPrincipalName
onPremisesUserPrincipalName
certificateUserIds
Affinità bassa
RFC822Name X509:<RFC822>user@woodgrove.com userPrincipalName
onPremisesUserPrincipalName
certificateUserIds
Affinità bassa
IssuerAndSubject X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest certificateUserIds Affinità bassa
Subject X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest certificateUserIds Affinità bassa
SKI X509:<SKI>aB1cD2eF3gH4iJ5kL6-mN7oP8qR= certificateUserIds Affinità elevata
SHA1PublicKey X509:<SHA1-PUKEY>aB1cD2eF3gH4iJ5kL6-mN7oP8qR
Il SHA1PublicKey valore (hash SHA1 dell'intero contenuto del certificato, inclusa la chiave pubblica) si trova nella proprietà Identificazione personale del certificato.
certificateUserIds Affinità elevata
IssuerAndSerialNumber 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 Affinità elevata

Importante

È possibile usare il CertificateBasedAuthentication modulo PowerShell per trovare il valore corretto certificateUserIds per un utente in un certificato.

Definire ed eseguire l'override dell'associazione di affinità

Un amministratore dei criteri di autenticazione può configurare se gli utenti possono eseguire l'autenticazione usando un mapping di associazione nome utente ad affinità bassa o ad alta affinità.

Impostare Associazione di affinità obbligatoria per il tenant, che si applica a tutti gli utenti. Per eseguire l'override del valore predefinito a livello di tenant, creare regole personalizzate in base all'emittente e all'OID dei criteri o solo all'OID dei criteri o solo all'autorità emittente.

Regole di associazione di più criteri nome utente

Per risolvere più regole di associazione di criteri nome utente, Microsoft Entra ID usa l'associazione con priorità più alta (numero più basso):

  1. Cerca l'oggetto utente usando il nome utente o l'UPN.
  2. Ottiene l'elenco di tutte le associazioni di nome utente configurate dall'amministratore dei criteri di autenticazione nella configurazione del metodo CBA ordinata dall'attributo priority . Attualmente, la priorità non viene visualizzata nell'interfaccia di amministrazione. Microsoft Graph restituisce l'attributo priority per ogni associazione. Quindi, le priorità vengono usate nel processo di valutazione.
  3. Se il tenant ha un'associazione di affinità elevata configurata o se il valore del certificato corrisponde a una regola personalizzata che richiede un'associazione ad affinità elevata, rimuove tutte le associazioni di affinità bassa dall'elenco.
  4. Valuta 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.
    • Se viene trovata una corrispondenza, l'autenticazione utente ha esito positivo.
    • Se non viene trovata una corrispondenza, passa all'associazione di priorità successiva.
  6. Se il campo certificato X.509 non è presente nel certificato presentato, passa all'associazione di priorità successiva.
  7. Convalida 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.

Proteggere la configurazione di Microsoft Entra usando più associazioni nome utente

Ognuno degli attributi dell'oggetto utente di Microsoft Entra disponibile per associare i certificati agli account utente di Microsoft Entra (userPrincipalName, onPremiseUserPrincipalNamee certificateUserIds) 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 nei criteri di associazione nome utente. Un amministratore dei criteri di autenticazione può contenere un certificato usato in più configurazioni degli account utente di Microsoft Entra.

Importante

Se si configurano più associazioni, l'autenticazione CBA di Microsoft Entra è sicura solo dell'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 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, un amministratore dei criteri di autenticazione deve assicurarsi che tutti i metodi consentiti configurati nel mapping dei criteri allo stesso account Microsoft Entra. Tutti gli account utente devono avere valori che corrispondono a tutte le associazioni.
  • Se un tenant ha più metodi di associazione configurati, un amministratore dei criteri di autenticazione deve assicurarsi che non disponga di più di un'associazione di affinità bassa.

Ad esempio, sono disponibili due associazioni nome utente su PrincipalName cui è stato eseguito il mapping a UPNe SubjectKeyIdentifier (SKI) viene eseguito il mapping a certificateUserIds. Se si vuole usare un certificato solo per un singolo account, un amministratore dei criteri di autenticazione deve assicurarsi che l'account disponga dell'UPN presente nel certificato. L'amministratore implementa quindi il SKI mapping nell'attributo certificateUserIds dello stesso account.

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

In alcuni scenari, un'organizzazione rilascia più certificati per una singola identità. Potrebbe trattarsi di una credenziale derivata per un dispositivo mobile, ma potrebbe anche essere per una smart card secondaria o un dispositivo con supporto per le credenziali X.509, ad esempio YubiKey.

Account solo cloud (M:1)

Per gli account solo cloud, è possibile eseguire il mapping di un massimo di cinque certificati da usare popolando il certificateUserIds campo con valori univoci per identificare ogni certificato. Per eseguire il mapping dei certificati, nell'interfaccia di amministrazione passare alla scheda Informazioni di autorizzazione .

Se l'organizzazione usa associazioni ad alta affinità come IssuerAndSerialNumber, i valori in certificateUserIds potrebbero essere simili all'esempio 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. Il secondo valore rappresenta X509Certificate2. L'utente può presentare uno dei due certificati all'accesso. Se l'associazione del nome utente CBA è impostata in modo che punti al certificateUserIds campo per cercare il tipo di associazione specifico (in questo esempio, IssuerAndSerialNumber), l'utente accede correttamente.

Account sincronizzati ibridi (M:1)

Per gli account sincronizzati, è possibile eseguire il mapping di più certificati. In Active Directory locale popolare il altSecurityIdentities campo con i valori che identificano ogni certificato. Se l'organizzazione usa associazioni ad alta affinità (ovvero autenticazione avanzata), ad IssuerAndSerialNumberesempio , i valori potrebbero essere simili agli esempi 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. Il secondo valore rappresenta X509Certificate2. I valori devono quindi essere sincronizzati con il certificateUserIds campo in Microsoft Entra ID.

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

In alcuni scenari, un'organizzazione richiede a un utente di usare lo stesso certificato per l'autenticazione in più identità. Potrebbe trattarsi di un account amministrativo o di uno sviluppatore o di un account temporaneo.

In Active Directory locale, il altSecurityIdentities campo popola i valori del certificato. Un hint viene usato durante l'accesso per indirizzare Active Directory all'account previsto per verificare la presenza di accesso.

Microsoft Entra CBA ha un processo diverso e non è incluso alcun suggerimento. L'individuazione dell'area di autenticazione principale identifica invece l'account desiderato e controlla i valori del certificato. Microsoft Entra CBA applica anche l'univocità nel certificateUserIds campo. Due account non possono popolare gli stessi valori di certificato.

Importante

L'uso delle stesse credenziali per l'autenticazione in account Microsoft Entra diversi non è una configurazione sicura. È consigliabile non consentire l'uso di un singolo certificato per più account utente di Microsoft Entra.

Account solo cloud (1:M)

Per gli account solo cloud, creare più associazioni di nome utente ed eseguire il mapping di valori univoci a ogni account utente che usa il certificato. L'accesso a ogni account viene autenticato usando un'associazione nome utente diversa. Questo livello di autenticazione si applica al limite di una singola directory o tenant. Un amministratore dei criteri di autenticazione può eseguire il mapping del certificato per usarlo in un'altra directory o tenant se i valori rimangono univoci per ogni account.

Popolare il certificateUserIds campo con un valore univoco che identifica il certificato. Per popolare il campo, nell'interfaccia di amministrazione passare alla scheda Informazioni di autorizzazione .

Se l'organizzazione usa associazioni ad alta affinità ( ovvero autenticazione avanzata) come IssuerAndSerialNumber e SKI, i valori potrebbero essere simili all'esempio seguente:

Associazioni di nome utente:

  • IssuerAndSerialNumber > certificateUserIds
  • SKI > certificateUserIds

Valori dell'account certificateUserIds 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 accede correttamente perché il proprio account corrisponde a un valore univoco per tale certificato. Un account viene autenticato tramite IssuerAndSerialNumber e l'altro tramite SKI l'associazione.

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 massimo di account supportati è tre. Se l'organizzazione usa anche associazioni a bassa affinità, il numero aumenta a sette account: uno , uno PrincipalName, uno RFC822Name, uno , uno SKI, uno , uno SHA1PublicKeyIssuerAndSubjecte uno IssuerAndSerialNumber.Subject

Account sincronizzati ibridi (1:M)

Gli account sincronizzati richiedono un approccio diverso. Anche se un amministratore dei criteri di autenticazione può eseguire il mapping di valori univoci a ogni account utente che usa il certificato, la pratica comune di popolare tutti i valori per ogni account in Microsoft Entra ID rende difficile questo approccio. Microsoft Entra Connect deve invece filtrare i valori per account in base ai valori univoci popolati nell'account in Microsoft Entra ID. La regola di univocità si applica al limite di una singola directory o tenant. Un amministratore dei criteri di autenticazione può eseguire il mapping del certificato per usarlo in un'altra directory o tenant se i valori rimangono univoci per ogni account.

L'organizzazione potrebbe anche avere più foreste di Active Directory che contribuiscono agli utenti a un singolo tenant di Microsoft Entra. In questo caso, Microsoft Entra Connect applica il filtro a ognuna delle foreste di Active Directory con lo stesso obiettivo: popolare solo un valore specifico e univoco per l'account cloud.

Popolare il altSecurityIdentities campo in Active Directory con i valori che identificano il certificato. Includere il valore del certificato specifico per il tipo di account utente, ad esempio detailed, admino developer. Selezionare un attributo chiave in Active Directory. L'attributo indica 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 che si vuole usare, ad esempio detailed, admino developer. Se l'account è l'account primario dell'utente, il valore può essere vuoto o NULL.

Verificare che gli account siano simili a questi esempi:

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

È quindi necessario sincronizzare questi valori con il certificateUserIds campo in Microsoft Entra ID.

Per eseguire la sincronizzazione con certificateUserIds:

  1. Configurare Microsoft Entra Connect per aggiungere il alternativeSecurityIds campo al metaverse.
  2. Per ogni foresta Active Directory locale, configurare una nuova regola in ingresso personalizzata con precedenza elevata (un numero basso, inferiore a 100). Aggiungere una Expression trasformazione con il altSecurityIdentities campo come origine. L'espressione di destinazione usa l'attributo chiave selezionato e popolato e usa il mapping ai tipi di utente definiti.

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) 
)

In questo esempio altSecurityIdentities e l'attributo msDS-cloudExtensionAttribute1 chiave vengono prima controllati per verificare se sono popolati. Se non vengono popolati, altSecurityIdentities viene controllato per verificare se è popolato. Se è vuoto, impostarlo su NULL. In caso contrario, l'account è uno scenario predefinito.

In questo esempio, filtrare solo in base al IssuerAndSerialNumber mapping. Se l'attributo chiave viene popolato, il valore viene controllato per verificare se è uguale a uno dei tipi di utente definiti. Nell'esempio, se tale valore è detailed, filtrare in base al SHA1PublicKey valore di altSecurityIdentities. Se il valore è developer, filtrare il SubjectKeyIssuer valore da altSecurityIdentities.

È possibile che si verifichino più valori di certificato di un tipo specifico. Ad esempio, potrebbero essere visualizzati più PrincipalName valori o più SKI valori.SHA1-PUKEY Il filtro ottiene tutti i valori e li sincronizza in Microsoft Entra ID, non solo il primo trovato.

Ecco un secondo esempio che mostra come eseguire il push di un valore vuoto se l'attributo del controllo è vuoto:

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 AuthoritativeNull valore. Questo valore garantisce che le regole precedenti o successive che popolano vengano ignorate alternativeSecurityId . Il risultato è vuoto in Microsoft Entra ID.

Per sincronizzare un valore vuoto:

  1. Configurare una nuova regola in uscita personalizzata con una precedenza bassa (un numero elevato, superiore a 160 ma dalla parte inferiore dell'elenco).
  2. Aggiungere una trasformazione diretta con il alternativeSecurityIds campo come origine e il certificateUserIds campo 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 certificateUserIds campo per i tipi di campo mappati dal certificato. A questo punto uno di questi utenti può presentare il certificato all'accesso. Dopo la convalida del valore univoco del certificato rispetto al certificateUserIds campo, l'utente ha eseguito l'accesso.

Ambito dell'autorità di certificazione (CA) (anteprima)

L'ambito della CA in Microsoft Entra consente agli amministratori tenant di limitare l'uso di ca specifiche a gruppi di utenti definiti. Questa funzionalità migliora la sicurezza e la gestibilità dell'autorità di certificazione assicurando che solo gli utenti autorizzati possano eseguire l'autenticazione usando certificati rilasciati da ca specifiche.

La definizione dell'ambito della CA è utile negli scenari multi-PKI o B2B in cui vengono usate più ca in diverse popolazioni di utenti. Consente di impedire l'accesso imprevisto e supporta la conformità ai criteri dell'organizzazione.

Vantaggi chiave

  • Limita l'uso del certificato a gruppi di utenti specifici
  • Supporta ambienti PKI complessi tramite più ca
  • Fornisce una protezione avanzata contro l'uso improprio o la compromissione dei certificati
  • Offre visibilità sull'utilizzo della CA tramite i log di accesso e gli strumenti di monitoraggio

Un amministratore può usare l'ambito ca per definire le regole che associano una CA (identificata dal relativo ski) a un gruppo specifico di Microsoft Entra. Quando un utente tenta di eseguire l'autenticazione usando un certificato, il sistema verifica se l'ambito della CA emittente per il certificato è un gruppo che include l'utente. Microsoft Entra procede con la catena ca. Applica tutte le regole di ambito fino a quando l'utente non viene trovato in uno dei gruppi in tutte le regole di ambito. Se l'utente non è incluso nel gruppo con ambito, l'autenticazione ha esito negativo, anche se il certificato è altrimenti valido.

Configurare la funzionalità di definizione dell'ambito della CA

  1. Accedere all'interfaccia di amministrazione di Microsoft Entra come almeno un amministratore dei criteri di autenticazione.

  2. Passare a Entra ID>Authentication methods>Certificate-based authentication (Autenticazione basata su certificato).

  3. In Configura passare a Criteri di ambito autorità di certificazione.

    Screenshot che mostra i criteri di ambito della CA.

  4. Selezionare Aggiungi regola.

    Screenshot che mostra come aggiungere una regola di ambito della CA.

  5. Selezionare Filtra CA per PKI.

    Le ca classiche mostrano tutte le CA dal classico archivio ca. Se si seleziona un'infrastruttura a chiave pubblica specifica, vengono visualizzate tutte le ca dall'infrastruttura a chiave pubblica selezionata.

  6. Selezionare un'infrastruttura a chiave pubblica( PKI).

    Screenshot che mostra il filtro PKI per la definizione dell'ambito della CA.

  7. L'elenco Autorità di certificazione mostra tutte le ca dall'infrastruttura a chiave pubblica selezionata. Selezionare una CA (Autorità di Certificazione) per creare una regola di ambito.

    Screenshot che mostra come selezionare una CA nell'ambito della CA.

  8. Selezionare Aggiungi gruppo.

    Screenshot che mostra l'opzione Aggiungi gruppo nell'ambito della CA.

  9. Selezionare un gruppo.

    Screenshot che mostra l'opzione seleziona gruppo nell'ambito della CA.

  10. Selezionare Aggiungi per salvare la regola.

    Screenshot che mostra l'opzione salva regola nell'ambito della CA.

  11. Selezionare la casella di controllo Conferma e quindi selezionare Salva.

    Screenshot che mostra l'opzione di configurazione Salva CBA nell'ambito della CA.

  12. Per modificare o eliminare un criterio di ambito della CA, selezionare "..." nella riga della regola. Per modificare la regola, selezionare Modifica. Per eliminare la regola, selezionare Elimina.

    Screenshot che mostra come modificare o eliminare nell'ambito della CA.

Limitazioni note

  • È possibile assegnare un solo gruppo per ogni CA.
  • È supportato un massimo di 30 regole di ambito.
  • L'applicazione dell'ambito è eseguita a livello di CA intermedio.
  • Una configurazione non corretta potrebbe comportare blocchi utente se non esistono regole di ambito valide.

Voci di log di accesso

  • Il log di accesso mostra l'esito positivo. Nella scheda Dettagli aggiuntivi viene visualizzato lo SKI della CA dalla regola dei criteri di definizione dell'ambito.

    Screenshot che mostra l'esito positivo del log di accesso della regola di definizione dell'ambito della CA.

  • Quando un'autorità di certificazione non riesce a causa di una regola di ambito ca, la scheda Informazioni di base nel log di accesso mostra il codice di errore 500189.

    Screenshot che mostra un errore di ambito del log di accesso della CA.

    Gli utenti finali visualizzano il messaggio di errore seguente:

    Screenshot che mostra un errore utente di ambito della CA.

Funzionamento di CBA con criteri di attendibilità dell'autenticazione dell'accesso condizionale

È possibile usare il livello di autenticazione MFA resistente al phishing predefinito di Microsoft Entra per creare un criterio di autenticazione dell'accesso condizionale che specifica di usare LBA per accedere a una risorsa. Il criterio consente solo metodi di autenticazione resistenti al phishing, ad esempio 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 A più fattori come autenticazione a singolo fattore, MFA o entrambe. Per altre informazioni, vedere Livello di autenticazione dell'accesso condizionale.

Livello CBA con opzioni avanzate

Nei criteri del metodo CBA, un amministratore dei criteri di autenticazione può determinare il livello di attendibilità del certificato usando un criterio di associazione di autenticazione nel metodo CBA. È ora possibile richiedere l'uso di un certificato specifico in base agli OID dell'autorità emittente e ai criteri quando gli utenti eseguono LBA per accedere a determinate risorse sensibili. Quando si crea un livello di autenticazione personalizzato, passare a Opzioni avanzate. La funzionalità fornisce 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.

Registri di accesso

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

Si considerino quindi due scenari. In uno scenario, il certificato soddisfa l'autenticazione a fattore singolo. Nel secondo scenario, il certificato soddisfa l'autenticazione a più fattori.

Per gli scenari di test, selezionare 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 alternativo soggetto e del nome dell'entità all'oggetto userPrincipalName utente.

Il certificato utente deve essere configurato come l'esempio illustrato in questo screenshot:

Screenshot che mostra il certificato utente.

Risolvere i problemi di accesso con le variabili dinamiche nei log di accesso

Anche se i log di accesso in genere forniscono tutte le informazioni necessarie per eseguire il debug di un problema di accesso, a volte sono necessari valori specifici. I log di accesso non supportano variabili dinamiche, quindi in alcuni casi i log di accesso non contengono le informazioni necessarie per il debug.

Ad esempio, il motivo dell'errore nei log di accesso potrebbe essere visualizzato "The Certificate Revocation List (CRL) failed signature validation. Expected Subject Key Identifier <expectedSKI> doesn't match CRL Authority Key <crlAK>. Request your tenant administrator to check the CRL configuration." in questo scenario<expectedSKI> e <crlAKI> non viene popolato con valori corretti.

Quando l'accesso dell'utente con CBA ha esito negativo, è possibile copiare i dettagli del log dal collegamento Altri dettagli nella pagina dell'errore. Per altre informazioni, vedere La pagina relativa all'errore CBA.

Test dell'autenticazione a fattore singolo

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

Screenshot che mostra la configurazione dei criteri di autenticazione e l'autenticazione a singolo fattore richiesta.

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

  2. Cercare e quindi selezionare Log di accesso.

    La figura seguente mostra 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 è configurata per il tenant. Viene richiesto un certificato per l'autenticazione.

    Screenshot che mostra la voce di autenticazione a fattore singolo nei log di accesso.

    Dettagli attività mostra che la richiesta fa parte del flusso di accesso previsto in cui l'utente seleziona un certificato.

    Screenshot che mostra i dettagli dell'attività nei log di accesso.

    Dettagli aggiuntivi mostra le informazioni sul certificato.

    Screenshot che mostra dettagli aggiuntivi a più fattori nei log di accesso.

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

    Screenshot che mostra una voce del token di aggiornamento nei log di accesso.

Testare l'autenticazione a più fattori

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

Screenshot che mostra la configurazione dei criteri di autenticazione che mostra l'autenticazione a più fattori richiesta.

  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 quindi selezionare Accessi.

    Vengono visualizzate diverse voci nei log di accesso, inclusa una voce con stato Interrotto .

    Screenshot che mostra diverse voci nei log di accesso.

    Dettagli attività mostra che la richiesta fa parte del flusso di accesso previsto in cui l'utente seleziona un certificato.

    Screenshot che mostra i dettagli dell'accesso di secondo fattore nei log di accesso.

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

    Screenshot che mostra i dettagli dei tentativi interrotti nei log di accesso.

    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: PrincipalName; attributo utente: userPrincipalName; Classificazione: 1
    Questo campo mostra il campo certificato SAN PrincipalName mappato all'attributo userPrincipalName utente e la priorità 1.
    Livello di autenticazione del certificato utente multiFactorAuthentication
    Tipo di livello di autenticazione del certificato utente PolicyId
    Questo campo mostra che l'OID dei criteri è stato 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.

Pagina di errore di CBA

L'autorità di certificazione potrebbe non riuscire per diversi motivi. Gli esempi includono un certificato non valido, l'utente ha selezionato il certificato errato o un certificato scaduto o si verifica un problema CRL. Quando la convalida del certificato ha esito negativo, l'utente visualizza questo messaggio di errore:

Screenshot che mostra un errore di convalida del certificato.

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

  1. Per ottenere informazioni di registrazione da inviare a un amministratore dei criteri di autenticazione per altre informazioni dai log di accesso, selezionare Altri dettagli.

    Screenshot che mostra i dettagli dell'errore.

  2. Selezionare Altri modi per accedere e provare altri metodi di autenticazione disponibili per accedere.

    Screenshot che mostra un nuovo tentativo di accesso.

Reimpostare la scelta del certificato in Microsoft Edge

Il browser Microsoft Edge ha aggiunto una funzionalità che reimposta la selezione del certificato senza riavviare il browser.

L'utente completa i passaggi seguenti:

  1. Quando L'autorità di certificazione ha esito negativo, viene visualizzata la pagina di errore.

    Screenshot che mostra un errore di convalida del certificato.

  2. A sinistra dell'URL dell'indirizzo selezionare l'icona di blocco e quindi selezionare Opzioni del certificato.

    Screenshot che mostra la scelta del certificato del browser Microsoft Edge.

  3. Selezionare Reimposta opzioni di certificato.

    Screenshot che mostra la reimpostazione della scelta del certificato del browser Microsoft Edge.

  4. Selezionare Reimposta scelte.

    Screenshot che mostra l'accettazione della reimpostazione del certificato del browser Microsoft Edge.

  5. Selezionare Altri modi per accedere.

    Screenshot che mostra un errore di convalida del certificato.

  6. Selezionare Usa un certificato o una smart card e continuare con l'autenticazione CBA.

CBA nei metodi MostRecentlyUsed

Dopo l'autenticazione di un utente tramite CBA, il metodo di autenticazione dell'utente MostRecentlyUsed (MRU) viene impostato su CBA. La volta successiva che l'utente immette il proprio UPN e seleziona Avanti, visualizza il metodo CBA e non è necessario selezionare Usa il certificato o la smart card.

Per reimpostare il metodo MRU, annullare la selezione certificati e quindi selezionare Altri modi per accedere. Selezionare un altro metodo disponibile e quindi completare l'autenticazione.

Il metodo di autenticazione MRU viene impostato a livello di utente. Se un utente accede correttamente a un dispositivo diverso usando un metodo di autenticazione diverso, l'elenco mru viene reimpostato per l'utente al metodo attualmente connesso.

Supporto delle identità esterne

Un utente guest B2B con identità esterna può usare L'autorità di certificazione nel tenant principale. Se le impostazioni tra tenant per il tenant di risorse sono configurate per considerare attendibile l'autenticazione a più fattori dal tenant principale, viene rispettata l'autorità di certificazione dell'utente nel tenant principale. Per altre informazioni, vedere Configurare l'accesso tra tenant di Collaborazione B2B. Attualmente, L'autorità di certificazione in un tenant di risorse non è supportata.