Come configurare l'autenticazione basata su certificati Microsoft Entra

L'autenticazione basata su certificati (CBA) di 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 la moderna autenticazione senza password resistente al phishing usando un certificato x.509.

Durante l'accesso, gli utenti visualizzano 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, in caso di esito positivo, l’utente effettua l'accesso.

Seguire queste istruzioni per configurare e usare Microsoft Entra CBA per i tenant di Microsoft Office 365 per aziende e piani degli enti pubblici degli Stati Uniti. Dovrebbe essere già configurata unaPKI..

Prerequisiti

Verifica che siano soddisfatti i seguenti prerequisiti:

• Configurare almeno un'autorità di certificazione (CA) e tutte le ca intermedie nell'ID Microsoft Entra.
• L'utente deve avere accesso a un certificato utente (rilasciato da un’infrastruttura a chiave pubblica [PKI] 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 per Internet. Se la CA attendibile non dispone di un CRL configurato, l'ID Entra di Microsoft non esegue alcun controllo CRL, la revoca dei certificati utente non funziona e l'autenticazione non viene bloccata.

Importante

Assicurarsi che la PKI 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 in locale che gli utenti 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à della PKI. Per altre informazioni, vedere Protezione della PKI.

Importante

Per le procedure consigliate per la crittografia Microsoft relativa alla scelta dell'algoritmo, alla lunghezza delle chiavi e alla protezione dei dati, vedere i Consigli di Microsoft. Assicurarsi di usare uno degli algoritmi consigliati, la lunghezza della chiave e le curve approvate dal National Institute of Standards and Technology (NIST).

Importante

Nell'ambito dei continui miglioramenti della sicurezza degli endpoint di Azure/M365, si sta aggiungendo il supporto per TLS1.3, processo che richiederà alcuni mesi per coprire le migliaia di endpoint di servizio in Azure/M365. Sono inclusi l'endpoint Microsoft Entra usato da Microsoft Entra CBA *.certauth.login.microsoftonline.com e *.certauth.login.microsoftonline.us. TLS 1.3 è la versione più recente del protocollo di sicurezza più implementato 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 che gli sviluppatori inizino a testare TLS 1.3 nelle loro applicazioni e servizi.

Nota

Quando si valuta una PKI, è importante esaminare i criteri di rilascio e l'applicazione dei certificati. Come accennato, l'aggiunta di una CA alla configurazione di Microsoft Entra consente ai certificati rilasciati da tali CA 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 esse implementano identificatori riutilizzabili. Quando gli amministratori devono assicurarsi che solo un certificato specifico consenta 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 consenta di autenticare l'utente. Per altre informazioni, vedere Associazioni ad alta affinità.

Procedura per configurare e testare Microsoft Entra CBA

Prima di abilitare Microsoft Entra CBA, è necessario eseguire alcuni passaggi di configurazione. 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 assicurare che per apportare modifiche siano necessari solo gli amministratori con privilegi minimi.

Per gestire questa funzionalità è necessario un amministratore globale.

Facoltativamente, puoi anche configurare le associazioni dell’autenticazione per eseguire il mapping dei certificati per l’autenticazione a fattore singolo o l’autenticazione a più fattori e configurare le associazioni nome utente per eseguire il mapping del campo del certificato per un attributo dell'oggetto utente. Gli amministratori dei criteri di autenticazione possono configurare le impostazioni correlate all'utente. Una volta completate tutte le configurazioni, abilitare Microsoft Entra CBA nel tenant.

Passaggio 1: Configurare le autorità di certificazione con l'archivio attendibilità basato su PKI (anteprima)

Entra ha un nuovo archivio di attendibilità delle autorità di certificazione basate su infrastruttura a chiave pubblica (PKI). L'archivio di attendibilità della CA basato su PKI mantiene le ca all'interno di un oggetto contenitore per ogni infrastruttura PKI diversa. Gli amministratori possono gestire ca in un contenitore in base all'infrastruttura a chiave pubblica più semplice di un elenco semplice di ca.

L'archivio attendibilità basato su PKI presenta limiti più elevati per il numero di ca e le dimensioni di ogni file ca. Un archivio attendibilità basato su PKI supporta fino a 250 CA e dimensioni di 8 KB per ogni oggetto CA. È consigliabile usare il nuovo archivio attendibilità basato su PKI per l'archiviazione di ca, scalabili e supporta nuove funzionalità come gli hint dell'autorità di certificazione.

Nota

Se si usa l'archivio attendibilità precedente per configurare le ca, è consigliabile configurare un archivio attendibilità basato su PKI.

Un amministratore deve configurare le ca attendibili che rilasciano certificati utente. Per apportare modifiche sono necessari solo gli amministratori con privilegi minimi. Un archivio attendibilità basato su PKI ha ruoli di controllo degli accessi in base al ruolo Amministratore autenticazione e Amministratore autenticazione.

La funzionalità Upload PKI dell'archivio trust basato su PKI è disponibile solo con licenza P1 o P2 dell'ID Entra Microsoft. Tuttavia, anche con licenza gratuita, gli amministratori possono caricare tutte le CA singolarmente anziché il file PKI e configurare l'archivio attendibilità basato su PKI.

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

Creare un oggetto contenitore PKI

1. Creare un oggetto contenitore PKI.

2. Accedere all'interfaccia di amministrazione di Microsoft Entra come amministratore dei criteri di autenticazione.

3. Passare a Protezione>Mostra altro>Centro sicurezza (o Identity Secure Score) >Infrastruttura a chiave pubblica (anteprima).

4. Fare clic su + Crea infrastruttura a chiave pubblica.

5. Immettere il Nome visualizzato.

6. Cliccare su Crea.

   

7. Seleziona Colonne per aggiungere o eliminare colonne.

8. Selezionare Aggiorna per aggiornare l'elenco delle infrastruttura a chiave pubblica.Select Refresh to refresh the list of PKIs.

Eliminare un oggetto contenitore PKI

1. Per eliminare un'infrastruttura a chiave pubblica, selezionare l'infrastruttura a chiave pubblica e selezionare Elimina. Se l'infrastruttura a chiave pubblica contiene ca, immettere il nome dell'infrastruttura a chiave pubblica per confermare l'eliminazione di tutte le ca al suo interno e selezionare Elimina.

   

Caricare singole ca in un oggetto contenitore PKI

1. Per caricare una CA nel contenitore PKI:

   1. Fare clic su + Aggiungi autorità di certificazione.

   2. Seleziona il file CA.

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

   4. Per l’Elenco di revoche di certificati degli URL, imposta l'URL per internet per il CRL di base della CA che contiene tutti i certificati revocati. Se l'URL non è impostato, l'autenticazione con certificati revocati non ha esito negativo.

   5. Per l’URL dell'elenco di revoche di certificati Delta, imposta l'URL per internet per il CRL che contiene tutti i certificati revocati a partire dalla pubblicazione dell'ultimo CRL di base.

   6. Il flag hint dell'autorità di certificazione è abilitato per impostazione predefinita. Disattivare gli hint autorità di certificazione se l'autorità di certificazione non deve essere inclusa negli hint dell'autorità di certificazione.

   7. Seleziona Salva.

   8. Per eliminare un certificato della CA, seleziona il certificato e seleziona Elimina.

      

   9. Seleziona Colonne per aggiungere o eliminare colonne.

   10. Selezionare Aggiorna per aggiornare l'elenco delle ca.

Caricare tutte le ca con il caricamento dell'infrastruttura a chiave pubblica (PKI) nell'oggetto contenitore PKI

1. Per caricare tutte le ca contemporaneamente nel contenitore PKI:

   1. Creare un oggetto contenitore PKI o aprirne uno.
   2. Selezionare Carica pki.
   3. Immettere l'URL con connessione Internet http in cui è disponibile il file con estensione p7b.
   4. Immettere il checksum SHA256 del file.
   5. Selezionare il caricamento.
   6. Caricare l'infrastruttura a chiave pubblica (PKI) è un processo asincrono. Quando ogni CA viene caricata, è disponibile nell'infrastruttura a chiave pubblica. Il completamento del caricamento PKI può richiedere fino a 30 minuti.
   7. Selezionare Aggiorna per aggiornare le ca.

   Per generare il checksum SHA256 del file con estensione p7b PKI, eseguire questo comando:

   Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256
   

Modificare un'infrastruttura a chiave pubblica

1. Per modificare l'infrastruttura a chiave pubblica, selezionare ... nella riga PKI e selezionare Modifica.
2. Immettere un nuovo nome PKI e selezionare Salva.

Modificare una CA

1. Per modificare la CA, selezionare ... nella riga CA e selezionare Modifica.
2. Immettere nuovi valori per tipo di autorità di certificazione (radice/intermedia), URL CRL, URL CRL delta, flag abilitato hint autorità di certificazione in base alle esigenze e selezionare Salva.

Ripristinare un'infrastruttura a chiave pubblica

1. Selezionare la scheda PKIs eliminata.
2. Selezionare l'infrastruttura a chiave pubblica (PKI) e selezionare Restore PKI (Ripristina infrastruttura a chiave pubblica).

Ripristinare una CA

1. Selezionare la scheda Ca eliminate.
2. Selezionare il file DELLA CA e selezionare Ripristina autorità di certificazione.

Informazioni sull'attributo isIssuerHintEnabled nella CA

Gli hint dell'autorità emittente inviano un'indicazione CA attendibile come parte dell'handshake Transport Layer Security (TLS). L'elenco ca attendibile è impostato sull'oggetto delle ca caricate dal tenant nell'archivio attendibilità entra. Per altre informazioni sugli hint dell'autorità emittente, vedere Understanding Issuer Hints.For more information about issuer hints, see Understanding Issuer Hints.

Per impostazione predefinita, i nomi dei soggetti di tutte le ca nell'archivio attendibilità di Microsoft Entra vengono inviati come suggerimenti. Se si vuole inviare un hint solo con ca specifiche, impostare l'attributo hint dell'autorità di certificazione isIssuerHintEnabled su true.

Esiste un limite di caratteri di 16 KB per gli hint dell'autorità di certificazione (nome soggetto della CA) che il server può inviare al client TLS. Come procedura consigliata, impostare l'attributo isIssuerHintEnabled su true solo per le ca che rilasciano certificati utente.

Se più ca intermedie dello stesso certificato radice rilasciano i certificati dell'utente finale, per impostazione predefinita tutti i certificati vengono visualizzati nella selezione certificati. Tuttavia, se si imposta isIssuerHintEnabled su true per ca specifiche, nella selezione certificati vengono visualizzati solo i certificati utente appropriati. Per abilitare isIssuerHintEnabled, modificare la CA e aggiornare il valore in true.

Configurare le autorità di certificazione usando le API Microsoft Graph

Le API di Microsoft Graph possono essere usate per configurare le CA. Gli esempi seguenti illustrano come usare Microsoft Graph per eseguire operazioni Create, Read, Update o Delete (CRUD) per un'infrastruttura a chiave pubblica o un'autorità di certificazione.

Creare un oggetto contenitore PKI

PATCH https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/
Content-Type: application/json
{
   "displayName": "ContosoPKI"
}

Ottenere tutti gli oggetti PKI

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations
ConsistencyLevel: eventual

Ottenere l'oggetto PKI in base all'ID PKI

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/{PKI-id}/
ConsistencyLevel: eventual

Caricare ca con un file con estensione p7b

PATCH https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/{PKI-id}/certificateAuthorities/{CA-id}
Content-Type: application/json
{
    	"uploadUrl":"https://CBA/demo/CBARootPKI.p7b,
    	"sha256FileHash": "AAAAAAD7F909EC2688567DE4B4B0C404443140D128FE14C577C5E0873F68C0FE861E6F"
}

Ottenere tutte le ca in un'infrastruttura a chiave pubblica

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/{PKI-id}/certificateAuthorities
ConsistencyLevel: eventual

Ottenere una CA specifica all'interno di un'infrastruttura a chiave pubblica (PKI) in base all'ID CA

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/{PKI-id}/certificateAuthorities/{CA-id}
ConsistencyLevel: eventual

Aggiornare un flag di hint dell'autorità di certificazione specifica

PATCH https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/{PKI-id}/certificateAuthorities/{CA-id}
Content-Type: application/json
{
   "isIssuerHintEnabled": true
}

Configurare le autorità di certificazione (CA) usando PowerShell Per questa configurazione, è possibile usare [Microsoft Graph PowerShell] (/powershell/microsoftgraph/installation).

1. Avviare PowerShell con privilegi di amministratore.

2. Installare e importare Microsoft Graph PowerShell SDK.

   Install-Module Microsoft.Graph -Scope AllUsers
   Import-Module Microsoft.Graph.Authentication
   Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
   

3. Connettersi al tenant e accettare tutto.

      Connect-MGGraph -Scopes "Directory.ReadWrite.All", "User.ReadWrite.All" -TenantId <tenantId>
   

Log di audit

Tutte le operazioni CRUD su un'infrastruttura a chiave pubblica o un'autorità di certificazione all'interno dell'archivio attendibilità vengono registrate nei log di controllo di Microsoft Entra.

Domande frequenti

Domanda: Perché il caricamento dell'infrastruttura a chiave pubblica ha esito negativo?

Risposta: controllare se il file PKI è valido e può essere accessibile senza problemi. Le dimensioni massime del file PKI devono essere

Domanda: Che cos'è il contratto di servizio (SLA) per il caricamento PKI?

Risposta: il caricamento PKI è un'operazione asincrona e può richiedere fino a 30 minuti per il completamento.

Domanda: Come si genera il checksum SHA256 per il file PKI?

Risposta: Per generare il checksum SHA256 del file PKI.p7b, eseguire questo comando:

Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256

Passaggio 2: abilitare la CBA nel tenant

Importante

Un utente è considerato capace di eseguire l’MFA quando è nell'ambito dell'Autenticazione basata su certificati nei criteri dei metodi di autenticazione. Questo requisito di criterio 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, vengono bloccati e non possono registrare altri metodi per MFA. Gli amministratori dei criteri di autenticazione devono abilitare l'autenticazione ABA solo per gli utenti che dispongono di certificati validi. Non includere Tutti gli utenti per CBA. Usare solo gruppi di utenti con certificati validi disponibili. Per altre informazioni, vedere Autenticazione a più fattori di Microsoft Entra.

Per abilitare CBA nell'interfaccia di amministrazione di Microsoft Entra, completare i passaggi seguenti:

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

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

3. Passa a Protezione>Metodi di autenticazione>Autenticazione basata sui certificati.

4. In Abilita e destinazione, seleziona Abilita.

5. Selezionare Aggiungi gruppi per selezionare gruppi specifici come quello creato. Usare gruppi specifici anziché Tutti gli utenti.

   

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

Nota

L'amministratore di rete deve consentire l'accesso all'endpoint certauth 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 venga accolta come parte dell'handshake TLS.

Passaggio 3: Configurare i criteri di associazione di autenticazione

I criteri di associazione dell'autenticazione consentono di determinare la forza dell'autenticazione a fattore singolo o MFA Il livello di protezione predefinito per i certificati nel tenant è l'autenticazione a fattore singolo.

Un amministratore dei criteri di autenticazione può modificare il valore predefinito da fattore singolo a più fattori e configurare regole dei criteri personalizzate. Le regole di associazione di autenticazione eseguono il mapping degli attributi del certificato, ad esempio Autorità emittente o ID oggetto criteri (OID, Policy Object ID), a un valore e selezionare il livello di protezione predefinito per tale regola. Puoi 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 almeno come Amministratore dei criteri di autenticazione.

2. Passare a Protezione>Metodi di autenticazione>Criteri.

3. In Gestisciselezionare Metodi di autenticazione>Autenticazione basata su certificato.

   

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

5. L'attributo del livello di protezione ha un valore predefinito di Autenticazione a fattore singolo. Selezionare Autenticazione a più fattori per cambiare dal valore predefinito a MFA.

   Nota

   Il valore predefinito del livello di protezione è attivo se non vengono aggiunte delle regole personalizzate. Se vengono aggiunte delle 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 dei certificati client. La configurazione può essere effettuata utilizzando sia il campo soggetto dell'autorità di certificazione sia l'OID dei criteri nel certificato.

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

   Per aggiungere regole personalizzate, selezionare Aggiungi regola.

   

   Per creare una regola in base all’autorità di certificazione, selezionare Autorità di certificazione.

   1. Selezionare un Identificatore dell'autorità di certificazione nella casella di riepilogo.

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

      

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

   1. Immettere un valore per OID dei criteri.

   2. Selezionare Autenticazione a più fattori, Bassa associazione di affinità e quindi fare clic su Aggiungi. Quando richiesto, fai clic su Conferma per terminare l'aggiunta della regola.

      

   Per creare una regola in base all'Autorità di certificazione e all’OID dei criteri:

   1. Selezionare Autorità di certificazione e OID dei criteri.

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

   3. Per il livello di autenticazione selezionare Autenticazione a singolo fattore o Autenticazione a più fattori.

   4. Per l’associazione di affinità selezionare Bassa.

      

   5. Selezionare Aggiungi.

      

   6. Autenticarsi con un certificato provvisto di un OID dei criteri 3.4.5.6 e rilasciato da CN=CBATestRootProd. L'autenticazione dovrebbe avere esito positivo e ottenere un'attestazione a più fattori.

Importante

Si è verificato un problema noto per cui un amministratore dei criteri di autenticazione del tenant di Microsoft Entra configura una regola dei criteri di autenticazione CBA usando sia l'OID autorità di certificazione che l'OID criteri. Il problema influisce su alcuni scenari di registrazione dei dispositivi, tra cui:

• Iscrizione 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 di aggiunta al dispositivo Microsoft Entra 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 opzioni OID autorità di certificazione e criteri. Rimuovere il requisito Issuer o Policy OID e Salva. Oppure
• Rimuovere la regola dei criteri di autenticazione che usa sia l'OID autorità di certificazione che l'OID criteri. Creare regole che usano solo OID autorità di certificazione o criteri.

Microsoft sta lavorando per risolvere il problema.

Per creare una regola in base all'autorità di certificazione e al numero seriale:

1. Aggiungere un criterio di associazione di autenticazione. Il criterio richiede che qualsiasi certificato emesso da CN=CBATestRootProd con policyOID 1.2.3.4.6 richieda solo l'associazione di affinità elevata. Vengono usati l'autorità emittente e il numero di serie.

   

2. Seleziona il campo del certificato. In questo esempio selezionare Issuer (Autorità di certificazione) e Serial number (Numero di serie).

   

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

   

4. Seleziona Salva.

   Il log di accesso mostra l'associazione usata per l'accesso e i dettagli del certificato.

   

5. 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, immetti l'OID come 2.5.29.32.0 quando aggiungi la regola. La stringa Tutti i criteri di rilascio non è valida per l'editor delle regole e non ha effetto.

Passaggio 4: configurare i criteri di associazione del nome utente

Il criterio di associazione del nome utente aiuta a convalidare il certificato dell'utente. Per impostazione predefinita, il nome dell'entità di sicurezza nel certificato viene mappato in UserPrincipalName nell'oggetto utente per determinare l'utente.

Un amministratore dei criteri di autenticazione può sostituire l’impostazione predefinita e creare un mapping personalizzato. Per determinare come configurare l'associazione dei nomi utente, consulta Funzionamento dell'associazione dei nomi utente.

Per altri scenari che usano l'attributo certificateUserIds, vedere ID utente certificato.

Importante

Se un criterio di associazione del nome utente utilizza attributi sincronizzati, ad esempio certificateUserIds, onPremisesUserPrincipalName e userPrincipalName, attributo 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 amministrativi per Microsoft Entra Connect Server) possono apportare modifiche che influiscono su questi attributi in Microsoft 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 si trova nel certificato, ma il Microsoft Entra ID non trova un oggetto utente che usa tale valore, l'autenticazione non avrà esito positivo. Microsoft Entra ID proverà l'associazione successiva nell'elenco.

2. Seleziona Salva per salvare le modifiche.

La configurazione finale è simile alla seguente:

Passaggio 5: Verificare 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 dal browser del proprio dispositivo.

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

   

2. Selezionare Avanti.

   

   Se sono stati abilitati altri metodi di autenticazione, ad esempio l'accesso tramite telefono 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 per la selezione dei certificati client e selezionare OK.

   

5. Gli utenti devono accedere al Portale MyApps.

Se l'accesso ha esito positivo significa che:

• Viene effettuato il provisioning del certificato utente nel dispositivo di test.
• Microsoft Entra ID è 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 dettagliata. Vengono create due regole dei criteri di autenticazione, una usando l'autorità di certificazione soggetta a soddisfare l'autenticazione a fattore singolo e un'altra usando l'OID dei criteri per soddisfare l'autenticazione a più fattori.

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

   CN = WoodgroveCA

2. Creare una regola OID del criterio, con livello di protezione MFA e valore impostato su uno degli OID dei criteri nel certificato. Ad esempio 1.2.3.4.

   

3. Creare un criterio di accesso condizionale per l'utente per richiedere l'MFA seguendo la procedura descritta in Accesso condizionale - Richiedi MFA.

4. Passare a Portale MyApps. Immettere l'UPN e selezionare Avanti.

   

5. Selezionare Accedi con un certificato.

   

   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.

   

6. Selezionare il certificato client e selezionare Informazioni del certificato.

   

7. Viene visualizzato il certificato ed è possibile verificare i valori dell'autorità di certificazione e dell’OID 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.4e soddisfa l'MFA. Analogamente, l'autorità di certificazione nel certificato corrisponde al valore configurato di CN=WoodgroveCAe 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'MFA.

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

Testare i criteri di associazione del nome utente

Il criterio di associazione del nome utente aiuta a convalidare il certificato dell'utente. Esistono tre associazioni supportate per i criteri di associazione del 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 amministratore dei criteri di autenticazione può eseguire l'override del valore predefinito e creare un mapping personalizzato, come illustrato in precedenza.

Un amministratore dei criteri di autenticazione deve abilitare le nuove associazioni. Per prepararsi, è necessario assicurarsi che i valori corretti per le associazioni nome utente corrispondenti vengano aggiornati nell'attributo CertificateUserIds dell'oggetto utente:

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

Importante

Il formato dei valori di Autorità di certificazione, Soggetto e Numero di serie devono essere nell'ordine inverso del formato nel certificato. Non aggiungere spazio nell'autorità di certificazione o nel soggetto.

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 dell’autorità di certificazione da aggiungere è:

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

Per ottenere il valore corretto del numero di serie, eseguire questo comando 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

Ecco un esempio per il 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 dell’autorità di certificazione e del soggetto

Di seguito è riportato un esempio relativo al mapping manuale dell’autorità di certificazione e del soggetto. Il valore dell’autorità di certificazione è:

Il valore del soggetto è:

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 del soggetto

Ecco un esempio di mapping manuale del soggetto. Il valore del soggetto è:

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 almeno come Amministratore dei criteri di autenticazione.

2. Passare a Protezione>Metodi di autenticazione>Criteri.

3. In Gestisciselezionare Metodi di autenticazione>Autenticazione basata su certificato.

4. Seleziona Configura.

5. Impostare l’Associazione di affinità obbligatoria 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à obbligatoria a livello di 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 potrebbero essere bloccati.

   

6. Per eseguire il test, selezionare che l’Associazione di affinità obbligatoriasia bassa.

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 sarà 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 sarà simile alla schermata seguente:

    

12. Aggiornare l’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 l’MFA solo con il certificato.

Abilitare la CBA con l'API di Microsoft Graph

Per abilitare la CBA e configurare le associazioni di nomi utente tramite API Graph, segui questi passaggi.

1. Vai su Microsoft Graph Explorer.

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

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

4. Ottenere tutti i metodi di autenticazione con una richiesta GET:

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

5. Ottenere la configurazione per il metodo di autenticazione del certificato x509 con una richiesta GET:

   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 del 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. Testa la configurazione eseguendo l'accesso con un certificato che soddisfa i criteri.

Abilitare L'autorità di certificazione con Microsoft PowerShell

1. Aprire PowerShell.
2. Connettersi a Microsoft Graph:

   Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"
   

3. Creare una variabile per la definizione del gruppo per gli utenti CBA:

   $group = Get-MgGroup -Filter "displayName eq 'CBATestGroup'"
   

4. Definire il corpo della richiesta:

   $body = @{
   "@odata.type" = "#microsoft.graph.x509CertificateAuthenticationMethodConfiguration"
   "id" = "X509Certificate"
   "state" = "enabled"
   "certificateUserBindings" = @(
       @{
           "@odata.type" = "#microsoft.graph.x509CertificateUserBinding"
           "x509CertificateField" = "SubjectKeyIdentifier"
           "userProperty" = "certificateUserIds"
           "priority" = 1
       },
       @{
           "@odata.type" = "#microsoft.graph.x509CertificateUserBinding"
           "x509CertificateField" = "PrincipalName"
           "userProperty" = "UserPrincipalName"
           "priority" = 2
       },
       @{
           "@odata.type" = "#microsoft.graph.x509CertificateUserBinding"
           "x509CertificateField" = "RFC822Name"
           "userProperty" = "userPrincipalName"
           "priority" = 3
       }
   )
   "authenticationModeConfiguration" = @{
       "@odata.type" = "#microsoft.graph.x509CertificateAuthenticationModeConfiguration"
       "x509CertificateAuthenticationDefaultMode" = "x509CertificateMultiFactor"
       "rules" = @(
           @{
               "@odata.type" = "#microsoft.graph.x509CertificateRule"
               "x509CertificateRuleType" = "policyOID"
               "identifier" = "1.3.6.1.4.1.311.21.1"
               "x509CertificateAuthenticationMode" = "x509CertificateMultiFactor"
           }
       )
   }
   "includeTargets" = @(
       @{
           "targetType" = "group"
           "id" = $group.Id
           "isRegistrationRequired" = $false
       }
   ) } | ConvertTo-Json -Depth 5
   

5. Eseguire la richiesta PATCH:

   Invoke-MgGraphRequest -Method PATCH -Uri "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/x509Certificate" -Body $body -ContentType "application/json"
   

Passaggi successivi

• Panoramica di Microsoft Entra CBA
• Approfondimento tecnico su Microsoft Entra CBA
• Limitazioni con Microsoft Entra CBA
• Accesso tramite SmartCard di Windows con Microsoft Entra CBA
• Microsoft Entra CBA nei dispositivi mobili (Android e iOS)
• ID utente del certificato
• Come eseguire la migrazione di utenti federati
• Domande frequenti