Come configurare l'autenticazione basata su certificati Microsoft Entra

L'autenticazione basata su certificati Microsoft Entra consente alle organizzazioni di configurare i tenant di Microsoft Entra per consentire o richiedere agli utenti di eseguire l'autenticazione con certificati X.509 creati dall'infrastruttura a chiave pubblica (PKI) aziendale per l'accesso all'app e al browser. Questa funzionalità consente alle organizzazioni di adottare l'autenticazione moderna senza password resistente al phishing usando un certificato x.509.

Durante l'accesso, gli utenti vedranno anche un'opzione per l'autenticazione con un certificato anziché immettere una password. Se nel dispositivo sono presenti più certificati corrispondenti, l'utente può selezionarne uno da usare. Il certificato viene convalidato rispetto all'account utente e, se ha esito positivo, esegue l'accesso.

Seguire queste istruzioni per configurare e usare Microsoft Entra CBA per i tenant nei piani office 365 Enterprise e US Government. Dovrebbe essere già configurata un'infrastruttura a chiave pubblica (PKI).

Prerequisiti

Verifica che siano soddisfatti i seguenti prerequisiti:

• Configurare almeno un'autorità di certificazione (CA) ed eventuali ca intermedie nell'ID Microsoft Entra.
• L'utente deve avere accesso a un certificato utente (rilasciato da un'infrastruttura a chiave pubblica attendibile configurata nel tenant) destinato all'autenticazione client per l'autenticazione con Microsoft Entra ID.
• Ogni CA deve avere un elenco di revoche di certificati (CRL) a cui è possibile fare riferimento da URL con connessione Internet. Se la CA attendibile non dispone di un CRL configurato, l'ID Microsoft Entra non eseguirà alcun controllo CRL, la revoca dei certificati utente non funzionerà e l'autenticazione non verrà bloccata.

Importante

Assicurarsi che l'infrastruttura a chiave pubblica sia sicura e non possa essere facilmente compromessa. In caso di compromissione, l'utente malintenzionato può creare e firmare certificati client e compromettere qualsiasi utente nel tenant, sia gli utenti sincronizzati da utenti locali che solo cloud. Tuttavia, una strategia di protezione avanzata delle chiavi, insieme ad altri controlli fisici e logici, ad esempio schede di attivazione del modulo di protezione hardware o token per l'archiviazione sicura degli artefatti, può fornire una difesa approfondita per impedire a utenti malintenzionati esterni o minacce interne di compromettere l'integrità dell'infrastruttura a chiave pubblica. Per altre informazioni, vedere Protezione dell'infrastruttura a chiave pubblica (PKI).

Importante

Per le procedure consigliate per la crittografia Microsoft, vedere le raccomandazioni microsoft relative alla scelta dell'algoritmo, alla lunghezza delle chiavi e alla protezione dei dati. Assicurarsi di usare uno degli algoritmi consigliati, la lunghezza della chiave e le curve approvate dal NIST.

Importante

Nell'ambito dei continui miglioramenti della sicurezza degli endpoint di Azure/M365, l'aggiunta del supporto per TLS1.3 richiederà alcuni mesi per coprire le migliaia di endpoint di servizio in Azure/M365. Ciò include l'endpoint Entra ID usato da Microsoft Entra Certificate Based Authentication (CBA) *.certauth.login.microsoftonline.com & *.certauth.login.mcirosoftonline.us. TLS 1.3 è la versione più recente del protocollo di sicurezza più distribuito di Internet, che crittografa i dati per fornire un canale di comunicazione sicuro tra due endpoint. TLS 1.3 elimina gli algoritmi di crittografia obsoleti, migliora la sicurezza rispetto alle versioni precedenti e mira a crittografare la maggior parte dell'handshake possibile. È consigliabile per gli sviluppatori iniziare a testare TLS 1.3 nelle applicazioni e nei servizi.

Nota

Quando si valuta un'infrastruttura a chiave pubblica, è importante esaminare i criteri di rilascio e l'applicazione dei certificati. Come accennato, l'aggiunta di autorità di certificazione (CA) alla configurazione di Microsoft Entra consente ai certificati rilasciati da tali autorità di certificazione di autenticare qualsiasi utente in Microsoft Entra ID. Per questo motivo, è importante considerare come e quando le CA sono autorizzate a rilasciare certificati e come implementano identificatori riutilizzabili. Quando gli amministratori devono assicurarsi che solo un certificato specifico sia in grado di autenticare un utente, gli amministratori devono usare esclusivamente associazioni di affinità elevata per ottenere un livello più elevato di garanzia che solo un certificato specifico sia in grado di autenticare l'utente. Per altre informazioni, vedere Associazioni ad alta affinità.

Procedura per configurare e testare microsoft Entra CBA

Alcuni passaggi di configurazione da eseguire prima di abilitare Microsoft Entra CBA. Prima di tutto, un amministratore deve configurare le ca attendibili che rilasciano certificati utente. Come illustrato nel diagramma seguente, viene usato il controllo degli accessi in base al ruolo per assicurarsi che siano necessari solo gli amministratori con privilegi minimi per apportare modifiche. Solo il ruolo Global Amministrazione istrator può configurare la CA.

Facoltativamente, è anche possibile configurare le associazioni di autenticazione per eseguire il mapping dei certificati all'autenticazione a fattore singolo o a più fattori e configurare le associazioni nome utente per eseguire il mapping del campo del certificato a un attributo dell'oggetto utente. I criteri di autenticazione Amministrazione istrator possono configurare le impostazioni correlate all'utente. Al termine di tutte le configurazioni, abilitare Microsoft Entra CBA nel tenant.

Passaggio 1: Configurare le autorità di certificazione

È possibile configurare le autorità di certificazione usando l'interfaccia di amministrazione di Microsoft Entra o le API REST di Microsoft Graph e gli SDK supportati, ad esempio Microsoft Graph PowerShell. L'infrastruttura PKI o l'amministratore PKI devono essere in grado di fornire l'elenco delle ca emittenti. Per assicurarsi di aver configurato tutte le CA, aprire il certificato utente e fare clic sulla scheda "Percorso di certificazione" e assicurarsi che ogni CA non venga caricata nell'archivio attendibilità entra. L'autenticazione CBA avrà esito negativo se mancano ca.

Configurare le autorità di certificazione usando l'interfaccia di amministrazione di Microsoft Entra

Per abilitare l'autenticazione basata su certificati e configurare le associazioni utente nell'interfaccia di amministrazione di Microsoft Entra, seguire questa procedura:

1. Accedere all'interfaccia di amministrazione di Microsoft Entra come global Amministrazione istrator.

2. Passare a Protezione>Mostra altre>autorità di certificazione del Centro sicurezza (o Identity Secure Score). >

3. Per caricare una CA, selezionare Carica:

   1. Selezionare il file CA.

   2. Selezionare Sì se la CA è un certificato radice. In caso contrario, selezionare No.

   3. Per URL dell'elenco di revoche di certificati, impostare l'URL con connessione Internet per il CRL di base della CA che contiene tutti i certificati revocati.For Certificate Revoke List URL, set the Internet-facing URL for the CA base CRL that contains all revoked certificates. Se l'URL non è impostato, l'autenticazione con certificati revocati non avrà esito negativo.

   4. Per l'URL dell'elenco di revoche di certificati delta, impostare l'URL con connessione Internet per il CRL che contiene tutti i certificati revocati dopo la pubblicazione dell'ultima CRL di base.

   5. Selezionare Aggiungi.

      

4. Per eliminare un certificato ca, selezionare il certificato e selezionare Elimina.

5. Selezionare Colonne per aggiungere o eliminare colonne.

Nota

Il caricamento di una nuova CA ha esito negativo se una CA esistente è scaduta. Un Amministrazione istrator globale deve eliminare qualsiasi CA scaduta e riprovare a caricare la nuova CA.

Configurare le autorità di certificazione (CA) con PowerShell

È supportato un solo punto di distribuzione CRL (CDP) per una CA attendibile. Cdp può essere solo URL HTTP. Gli URL ldap (Lightweight Directory Access Protocol) o OCSP (Online Certificate Status Protocol) non sono supportati.

Per configurare le autorità di certificazione in Microsoft Entra ID, caricare quanto segue per ogni autorità di certificazione:

• La parte pubblica del certificato, nel formato .cer
• Gli URL Internet in cui si trovano gli elenchi di revoche di certificati (Certificate Revocation List o CRL)

Lo schema per un'autorità di certificazione ha un aspetto simile al seguente:

    class TrustedCAsForPasswordlessAuth
    {
       CertificateAuthorityInformation[] certificateAuthorities;
    }

    class CertificateAuthorityInformation

    {
        CertAuthorityType authorityType;
        X509Certificate trustedCertificate;
        string crlDistributionPoint;
        string deltaCrlDistributionPoint;
        string trustedIssuer;
        string trustedIssuerSKI;
    }

    enum CertAuthorityType
    {
        RootAuthority = 0,
        IntermediateAuthority = 1
    }

Per la configurazione, è possibile usare Microsoft Graph PowerShell:

1. Avviare Windows PowerShell con privilegi amministrativi.

2. Installare Microsoft Graph PowerShell:

       Install-Module Microsoft.Graph
   

Il primo passaggio di configurazione consiste nello stabilire una connessione con il tenant. Non appena viene stabilita la connessione al tenant è possibile rivedere, aggiungere, eliminare e modificare le autorità di certificazione attendibili definite nella directory.

Connessione

Per stabilire una connessione con il tenant, usare Connessione-MgGraph:

    Connect-MgGraph

Retrieve

Per recuperare le autorità di certificazione attendibili definite nella directory, usare Get-MgOrganizationCertificateBasedAuthConfiguration.

    Get-MgOrganizationCertificateBasedAuthConfiguration

Aggiungi

Nota

Il caricamento di nuove CA avrà esito negativo quando una delle ca esistenti è scaduta. Il tenant Amministrazione deve eliminare le ca scadute e quindi caricare la nuova CA.

Seguire i passaggi precedenti per aggiungere una CA nell'interfaccia di amministrazione di Microsoft Entra.

AuthorityType

• Usare 0 per indicare un'autorità di certificazione radice
• Usare 1 per indicare un'autorità di certificazione intermedia o emittente

crlDistributionPoint

È possibile scaricare il CRL e confrontare il certificato CA e le informazioni CRL per convalidare il valore crlDistributionPoint nell'esempio di PowerShell precedente è valido per la CA da aggiungere.

La tabella e l'immagine seguenti illustrano come eseguire il mapping delle informazioni dal certificato CA agli attributi del CRL scaricato.

Informazioni sul certificato CA	=	Informazioni CRL scaricate
Oggetto	=	Autorità di certificazione
Identificatore della chiave del soggetto	=	Identificatore di chiave dell'autorità (KeyID)

Suggerimento

Il valore di crlDistributionPoint nell'esempio precedente è il percorso http per l'elenco di revoche di certificati (CRL) della CA. Questo valore è disponibile in alcune posizioni:

• Nell'attributo CRL Distribution Point (CDP) di un certificato emesso dalla CA.

Se la CA emittente esegue Windows Server:

• Nelle proprietà della CA nell'autorità di certificazione Microsoft Management Console (MMC).
• Nella CA eseguendo certutil -cainfo cdp. Per altre informazioni, vedere certutil.

Per altre informazioni, vedere Informazioni sul processo di revoca dei certificati.

Convalidare la configurazione dell'autorità di certificazione

È importante assicurarsi che il risultato dei passaggi di configurazione precedenti sia la capacità di Entra ID per convalidare la catena di attendibilità dell'autorità di certificazione sia per verificare correttamente l'elenco di revoche di certificati (CRL) dal punto di distribuzione CRL configurato dell'autorità di certificazione . Per facilitare questa attività, è consigliabile installare il modulo PowerShell MSIdentity Tools ed eseguire Test-MsIdCBATrustStoreConfiguration. Questo cmdlet di PowerShell esaminerà la configurazione dell'autorità di certificazione del tenant Entra e presenterà errori/avvisi per problemi di configurazione errata comuni.

Passaggio 2: Abilitare L'autorità di certificazione nel tenant

Importante

Un utente è considerato in grado di eseguire l'autenticazione a più fattori quando l'utente è nell'ambito dell'autenticazione basata su certificati nei criteri metodi di autenticazione . Questo requisito di criteri significa che un utente non può usare la prova come parte dell'autenticazione per registrare altri metodi disponibili. Se gli utenti non hanno accesso ai certificati, verranno bloccati e non potranno registrare altri metodi per l'autenticazione a più fattori. L'amministratore deve quindi abilitare gli utenti che dispongono di un certificato valido nell'ambito CBA. Non usare tutti gli utenti per la destinazione CBA e usare gruppi di utenti con certificati validi disponibili. Per altre informazioni, vedere Autenticazione a più fattori Di Microsoft Entra.

Per abilitare l'autenticazione basata su certificati nell'interfaccia di amministrazione di Microsoft Entra, completare la procedura seguente:

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

2. Passare a Gruppi>Tutti i gruppi> selezionare Nuovo gruppo e creare un gruppo per gli utenti CBA

3. Passare a Metodi di autenticazione di protezione>Autenticazione> basata su certificati.

4. In Abilita e destinazione selezionare Abilita.

5. Selezionare Tutti gli utenti oppure Aggiungi gruppi per selezionare gruppi specifici come quello creato in precedenza. È consigliabile usare gruppi specifici anziché Tutti gli utenti.

   

Dopo aver abilitato l'autenticazione basata su certificati nel tenant, tutti gli utenti nel tenant vedranno l'opzione per accedere con un certificato. Solo gli utenti abilitati per l'autenticazione basata su certificati potranno eseguire l'autenticazione usando il certificato X.509.

Nota

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

Passaggio 3: Configurare i criteri di associazione di autenticazione

I criteri di associazione di autenticazione consentono di determinare l'attendibilità dell'autenticazione a un singolo fattore o a più fattori. Il livello di protezione predefinito per i certificati nel tenant è l'autenticazione a fattore singolo.

Un Amministrazione istrator dei criteri di autenticazione può modificare il valore predefinito da un singolo fattore a più fattori e configurare regole di criteri personalizzate. Le regole di associazione di autenticazione eseguono il mapping degli attributi del certificato, ad esempio Issuer, o Policy OID o Issuer and Policy OID, a un valore e selezionare il livello di protezione predefinito per tale regola. È possibile creare più regole.

Per modificare le impostazioni predefinite del tenant nell'interfaccia di amministrazione di Microsoft Entra, seguire questa procedura:

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

2. Passare a Criteri dei metodi> di autenticazione di protezione.>

3. In Gestisci selezionare Metodi di autenticazione Autenticazione> basata su certificato.

   

4. Selezionare Configura per configurare l'associazione di autenticazione e l'associazione nome utente.

5. L'attributo livello di protezione ha un valore predefinito di Autenticazione a fattore singolo. Selezionare Multi-Factor Authentication per modificare il valore predefinito in MFA.

   Nota

   Il valore predefinito del livello di protezione è attivo se non vengono aggiunte regole personalizzate. Se vengono aggiunte regole personalizzate, viene invece rispettato il livello di protezione definito a livello di regola.

   

6. È anche possibile configurare regole di associazione di autenticazione personalizzate per determinare il livello di protezione per i certificati client. Può essere configurato usando i campi OID oggetto o criterio dell'autorità emittente nel certificato.

   Le regole di associazione di autenticazione eseguiranno il mapping degli attributi del certificato (OID autorità di certificazione o criteri) a un valore e selezioneranno il livello di protezione predefinito per tale regola. È possibile creare più regole.

   Per aggiungere regole personalizzate, selezionare Aggiungi regola.

   

   Per creare una regola per autorità di certificazione, selezionare Autorità di certificazione.

   1. Selezionare un identificatore dell'autorità emittente del certificato nella casella di riepilogo.

   2. Selezionare Autenticazione a più fattori, Associazione di affinità bassa e quindi fare clic su Aggiungi. Quando richiesto, fare clic su Conferma per completare l'aggiunta della regola.

      

   Per creare una regola in base all'OID criteri, selezionare OID criteri.

   1. Immettere un valore per OID criteri.

   2. Selezionare Autenticazione a più fattori, Associazione di affinità bassa e quindi fare clic su Aggiungi. Quando richiesto, fare clic su Conferma per completare l'aggiunta della regola. .

      

   Per creare una regola in base all'OID autorità di certificazione e criteri:

   1. Selezionare Autorità di certificazione e OID criteri.

   2. Selezionare un'autorità emittente e immettere l'OID dei criteri.

   3. In Livello di autenticazione selezionare Autenticazione a singolo fattore o Autenticazione a più fattori.

   4. Per Associazione di affinità selezionare Bassa.

      

   5. Selezionare Aggiungi.

      

   6. Eseguire l'autenticazione con un certificato con OID dei criteri 3.4.5.6 e rilasciato da CN=CBATestRootProd. L'autenticazione deve passare e ottenere un'attestazione a più fattori.

Importante

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

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

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

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

Microsoft sta lavorando per risolvere il problema.

Per creare una regola in base all'autorità emittente e al numero di serie:

1. Aggiungere un criterio di associazione di autenticazione che richiede qualsiasi certificato emesso da CN=CBATestRootProd con policyOID 1.2.3.4.6 richiede solo l'associazione ad affinità elevata, ovvero vengono usati autorità di certificazione e numero di serie.

   

2. Selezionare il campo certificato. In questo esempio si selezionerà Issuer (Autorità di certificazione) e Serial number (Numero di serie).

   

3. L'unico attributo utente supportato è CertificateUserIds. Selezionare Aggiungi.

   

4. Seleziona Salva.

Il log degli accessi mostra l'associazione usata e i dettagli del certificato.

1. Selezionare OK per salvare qualsiasi regola personalizzata.

Importante

Immettere PolicyOID usando il formato dell'identificatore di oggetto. Ad esempio, se il criterio del certificato indica Tutti i criteri di rilascio, immettere l'OID come 2.5.29.32.0 quando si aggiunge la regola. La stringa Tutti i criteri di rilascio non è valida per l'editor delle regole e non avrà effetto.

Passaggio 4: Configurare i 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à nel certificato viene mappato a UserPrincipalName nell'oggetto utente per determinare l'utente.

Un Amministrazione istrator dei criteri di autenticazione può eseguire l'override dell'impostazione predefinita e creare un mapping personalizzato. Per determinare come configurare l'associazione di nomi utente, vedere Funzionamento dell'associazione di nomi utente.

Per altre informazioni sugli scenari che usano l'attributo certificateUserIds, vedere ID utente certificato.

Importante

Se un criterio di associazione nome utente utilizza attributi sincronizzati, ad esempio certificateUserIds, onPremisesUserPrincipalName e attributo userPrincipalName dell'oggetto utente, tenere presente che gli account con privilegi amministrativi in Active Directory (ad esempio quelli con diritti delegati per gli oggetti utente o i diritti di amministratore per Entra Connessione Server) possono apportare modifiche che influiscono su questi attributi in Entra ID.

1. Creare l'associazione nome utente selezionando uno dei campi certificato X.509 da associare a uno degli attributi utente. L'ordine di associazione del nome utente rappresenta il livello di priorità dell'associazione. Il primo ha la priorità più alta e così via.

   

   Se il campo certificato X.509 specificato viene trovato nel certificato, ma l'ID Microsoft Entra non trova un oggetto utente che usa tale valore, l'autenticazione non riesce. Microsoft Entra ID prova l'associazione successiva nell'elenco.

2. Seleziona Salva per salvare le modifiche.

La configurazione finale sarà simile alla seguente immagine:

Passaggio 5: Testare la configurazione

Questa sezione illustra come testare il certificato e le regole di associazione di autenticazione personalizzate.

Testare il certificato

Come primo test di configurazione, è consigliabile provare ad accedere al portale MyApps usando il browser sul dispositivo.

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

   

2. Selezionare Avanti.

   

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

   

3. Selezionare Accedi con un certificato.

4. Selezionare il certificato utente corretto nell'interfaccia utente selezione certificati client e selezionare OK.

   

5. Gli utenti devono accedere al portale MyApps.

Se l'accesso ha esito positivo significa che:

• Il provisioning del certificato utente è stato effettuato nel dispositivo di test.
• L'ID Microsoft Entra è configurato correttamente con ca attendibili.
• L'associazione nome utente è configurata correttamente e l'utente viene trovato e autenticato.

Testare le regole di associazione di autenticazione personalizzate

Verrà ora illustrato uno scenario in cui viene convalidata l'autenticazione avanzata. Verranno create due regole dei criteri di autenticazione, una usando l'autorità emittente soggetta a soddisfare l'autenticazione a fattore singolo e un'altra usando l'OID dei criteri per soddisfare l'autenticazione a più fattori.

1. Creare una regola soggetto dell'autorità di certificazione con livello di protezione come autenticazione a fattore singolo e valore impostato sul valore soggetto dell'autorità di certificazione. Ad esempio:

   CN = WoodgroveCA

2. Creare una regola OID dei criteri, con livello di protezione come autenticazione a più fattori e valore impostato su uno degli ID dei criteri nel certificato. Ad esempio, 1.2.3.4.

   

3. Creare un criterio di accesso condizionale per l'utente per richiedere l'autenticazione a più fattori seguendo la procedura descritta in Accesso condizionale - Richiedi autenticazione a più fattori.

4. Passare al portale App personali. Immettere l'UPN e selezionare Avanti.

   

5. Selezionare Accedi con un certificato.

   

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

   

6. Selezionare il certificato client e selezionare Informazioni certificato.

   

7. Viene visualizzato il certificato ed è possibile verificare i valori dell'OID autorità di certificazione e dei criteri.

8. Per visualizzare i valori dell'OID dei criteri, selezionare Dettagli.

   

9. Selezionare il certificato client e selezionare OK.

10. L'OID dei criteri nel certificato corrisponde al valore configurato 1.2.3.4 e soddisfa l'autenticazione a più fattori. Analogamente, l'emittente nel certificato corrisponde al valore configurato di CN=WoodgroveCA e soddisfa l'autenticazione a fattore singolo.

11. Poiché la regola OID dei criteri ha la precedenza sulla regola dell'autorità di certificazione, il certificato soddisfa l'autenticazione a più fattori.

12. I criteri di accesso condizionale per l'utente richiedono l'autenticazione a più fattori e il certificato soddisfa il multifactoring, in modo che l'utente possa accedere all'applicazione.

Testare i criteri di associazione nome utente

Il criterio di associazione del nome utente consente di convalidare il certificato dell'utente. Esistono tre associazioni supportate per i criteri di associazione nome utente:

• IssuerAndSerialNumber > CertificateUserIds
• IssuerAndSubject > CertificateUserIds
• Subject > CertificateUserIds

Per impostazione predefinita, Microsoft Entra ID esegue il mapping del nome dell'entità nel certificato a UserPrincipalName nell'oggetto utente per determinare l'utente. Un Amministrazione istrator dei criteri di autenticazione può eseguire l'override del valore predefinito e creare un mapping personalizzato, come illustrato in precedenza nel passaggio 4.

Prima di abilitare le nuove associazioni, un Amministrazione istrator dei criteri di autenticazione deve assicurarsi che i valori corretti per le associazioni vengano aggiornati nell'attributo dell'oggetto utente Certificate UserIds per le associazioni nome utente corrispondenti.

• Per gli utenti solo cloud, usare l'interfaccia di amministrazione di Microsoft Entra o le API Microsoft Graph per aggiornare il valore in CertificateUserIds.
• Per gli utenti sincronizzati locali, usare Microsoft Entra Connessione per sincronizzare i valori dall'ambiente locale seguendo microsoft Entra Connessione Rules o sincronizzando il valore AltSecId.

Importante

Il formato dei valori di Issuer, Subject e SerialNumber deve essere nell'ordine inverso del formato nel certificato. Non aggiungere spazio nell'autorità emittente o nell'oggetto.

Mapping manuale dell'autorità di certificazione e del numero di serie

Di seguito è riportato un esempio per il mapping manuale dell'autorità di certificazione e del numero di serie. Il valore issuer da aggiungere è:

C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate

Per ottenere il valore corretto per il numero di serie, eseguire il comando seguente e archiviare il valore visualizzato in CertificateUserIds. La sintassi del comando è:

Certutil –dump –v [~certificate path~] >> [~dumpFile path~] 

Ad esempio:

certutil -dump -v firstusercert.cer >> firstCertDump.txt

Di seguito è riportato un esempio di comando certutil:

certutil -dump -v C:\save\CBA\certs\CBATestRootProd\mfausercer.cer 

X509 Certificate: 
Version: 3 
Serial Number: 48efa06ba8127299499b069f133441b2 

   b2 41 34 13 9f 06 9b 49 99 72 12 a8 6b a0 ef 48 

Il valore SerialNumber da aggiungere in CertificateUserId è:

b24134139f069b49997212a86ba0ef48

CertificateUserId:

X509:<I>C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate<SR> b24134139f069b49997212a86ba0ef48 

Mapping manuale dei problemi e dell'oggetto

Di seguito è riportato un esempio relativo al mapping manuale dei problemi e dell'oggetto. Il valore issuer è:

Il valore Subject è:

CertificateUserId:

X509:<I>C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate<S> DC=com,DC=contoso,DC=corp,OU=UserAccounts,CN=FirstUserATCSession

Mapping manuale dell'oggetto

Ecco un esempio per il mapping manuale dell'oggetto. Il valore Subject è:

CertificateUserId:

X509:<S>DC=com,DC=contoso,DC=corp,OU=UserAccounts,CN=FirstUserATCSession

Testare l'associazione di affinità

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

2. Passare a Criteri dei metodi> di autenticazione di protezione.>

3. In Gestisci selezionare Metodi di autenticazione Autenticazione> basata su certificato.

4. Seleziona Configura.

5. Impostare Binding di affinità richiesta a livello di tenant.

   Importante

   Prestare attenzione all'impostazione di affinità a livello di tenant. È possibile bloccare l'intero tenant se si modifica l'associazione di affinità richiesta per il tenant e non si hanno valori appropriati nell'oggetto utente. Analogamente, se si crea una regola personalizzata che si applica a tutti gli utenti e richiede un'associazione di affinità elevata, gli utenti nel tenant possono essere bloccati.

   

6. Per eseguire il test, selezionare Binding di affinità obbligatorio in basso.

7. Aggiungere un'associazione ad alta affinità, ad esempio SKI. Selezionare Aggiungi regola in Associazione nome utente.

8. Selezionare SKI e selezionare Aggiungi.

   

   Al termine, la regola è simile alla schermata seguente:

   

9. Aggiornare tutti gli oggetti utente Attributo CertificateUserIds per avere il valore corretto di SKI dal certificato utente. Per altre informazioni, vedere Modelli supportati per CertificateUserIDs.

10. Creare una regola personalizzata per l'associazione di autenticazione.

11. Selezionare Aggiungi.

    

    Al termine, la regola è simile alla schermata seguente:

    

12. Aggiornare l'id utente CertificateUserIds con il valore SKI corretto dal certificato con l'OID dei criteri 9.8.7.5.

13. Eseguire il test con un certificato con l'OID dei criteri 9.8.7.5 e l'utente deve essere autenticato con l'associazione SKI e ottenere MFA solo con il certificato.

Abilitare L'autorità di certificazione usando l'API Microsoft Graph

Per abilitare L'autorità di certificazione e configurare le associazioni di nomi utente tramite l'API Graph, seguire questa procedura.

Nota

La procedura seguente usa Graph Explorer, che non è disponibile nel cloud us government. I tenant cloud degli Stati Uniti possono usare Postman per testare le query di Microsoft Graph.

1. Passare a Microsoft Graph Explorer.

2. Selezionare Accedi a Graph Explorer e accedere al tenant.

3. Seguire la procedura per fornire il consenso all'autorizzazione delegata Policy.ReadWrite.AuthenticationMethod.

4. GET tutti i metodi di autenticazione:

   GET  https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy
   

5. OTTENERE la configurazione per il metodo di autenticazione del certificato x509:

   GET https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy/authenticationMethodConfigurations/X509Certificate
   

6. Per impostazione predefinita, il metodo di autenticazione del certificato x509 è disabilitato. Per consentire agli utenti di accedere con un certificato, è necessario abilitare il metodo di autenticazione e configurare i criteri di autenticazione e associazione nome utente tramite un'operazione di aggiornamento. Per aggiornare i criteri, eseguire una richiesta PATCH.

   Testo della richiesta:

   PATCH https: //graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/x509Certificate
   Content-Type: application/json
   
   {
       "@odata.type": "#microsoft.graph.x509CertificateAuthenticationMethodConfiguration",
       "id": "X509Certificate",
       "state": "enabled",
       "certificateUserBindings": [
           {
               "x509CertificateField": "PrincipalName",
               "userProperty": "onPremisesUserPrincipalName",
               "priority": 1
           },
           {
               "x509CertificateField": "RFC822Name",
               "userProperty": "userPrincipalName",
               "priority": 2
           }, 
           {
               "x509CertificateField": "PrincipalName",
               "userProperty": "certificateUserIds",
               "priority": 3
           }
       ],
       "authenticationModeConfiguration": {
           "x509CertificateAuthenticationDefaultMode": "x509CertificateSingleFactor",
           "rules": [
               {
                   "x509CertificateRuleType": "issuerSubject",
                   "identifier": "CN=WoodgroveCA ",
                   "x509CertificateAuthenticationMode": "x509CertificateMultiFactor"
               },
               {
                   "x509CertificateRuleType": "policyOID",
                   "identifier": "1.2.3.4",
                   "x509CertificateAuthenticationMode": "x509CertificateMultiFactor"
               }
           ]
       },
       "includeTargets": [
           {
               "targetType": "group",
               "id": "all_users",
               "isRegistrationRequired": false
           }
       ]
   }
   

7. Si ottiene un codice di 204 No content risposta. Eseguire nuovamente la richiesta GET per assicurarsi che i criteri vengano aggiornati correttamente.

8. Testare la configurazione eseguendo l'accesso con un certificato che soddisfa i criteri.

Passaggi successivi

• Panoramica di Microsoft Entra CBA
• Approfondimento tecnico per Microsoft Entra CBA
• Limitazioni con Microsoft Entra CBA
• Accesso a Smart Card di Windows con Microsoft Entra CBA
• Microsoft Entra CBA nei dispositivi mobili (Android e iOS)
• ID utente certificato
• Come eseguire la migrazione di utenti federati
• Domande frequenti