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.

Segui queste istruzioni per configurare e utilizzare Microsoft Entra CBA per i tenant nei piani Office 365 Enterprise e US Government. Dovrebbe essere già configurata una infrastruttura a chiave pubblica (PKI).

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. Ciò include l'endpoint Microsoft Entra utilizzato dall'autenticazione basata su certificato (CBA) di Microsoft Entra *.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.

Importante

Microsoft consiglia di usare i ruoli con il minor numero di autorizzazioni. Questa procedura consente di migliorare la sicurezza per l'organizzazione. L'amministratore globale è un ruolo con privilegi elevati che deve essere limitato agli scenari di emergenza o quando non è possibile usare un ruolo esistente.

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 di fiducia 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à basato su PKI conserva le CA all'interno di un contenitore per ogni diversa PKI. Gli amministratori possono gestire le CA in un contenitore basato su PKI più facilmente rispetto a un elenco piatto di CA.

L'archivio di fiducia basato su PKI presenta limiti più elevati per il numero di CA e le dimensioni di ogni file CA. Un archivio di fiducia basato su PKI supporta fino a 250 CA e una dimensione di 8 KB per ciascun oggetto CA. Consigliamo fortemente di usare il nuovo archivio di fiducia basato su PKI per l'archiviazione delle autorità di certificazione, che è scalabile e supporta nuove funzionalità come le indicazioni dell'emittente.

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 repository di fiducia basato su PKI ha il ruolo RBAC Privilege Authentication Administrator.

La funzionalità di caricamento PKI dell'archivio di attendibilità basato su PKI è disponibile solo con una licenza Microsoft Entra ID P1 o P2. 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. Effettua l'accesso al centro di amministrazione di Microsoft Entra come Amministratore dell'Autenticazione con Privilegi .

3. Passare a Protezione>Mostra di più>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 PKI.

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'URL dell'Elenco di Revoca dei Certificati, imposta l'URL di base esposto a Internet per la CA CRL che contiene tutti i certificati revocati. Se l'URL non è impostato, l'autenticazione con certificati revocati non fallisce.

   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. L'indicatore Suggerimenti dell'Emittente è abilitato per impostazione predefinita. Disattivare i suggerimenti dell'emittente se l'autorità di certificazione non deve essere inclusa nei suggerimenti dell'emittente.

   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. Seleziona 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 il 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 nella PKI. Il completamento del caricamento PKI può richiedere fino a 30 minuti.
   7. Cliccare Aggiorna per aggiornare i 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 un'Autorità di Certificazione

1. Per modificare la CA, selezionare ... nella riga CA e selezionare Modifica.
2. Immettere nuovi valori per il tipo di autorità di certificazione (radice/intermedia), URL CRL, URL CRL Delta e l'indicatore dei suggerimenti dell'emittente abilitato, se necessario, e selezionare Salva.

Ripristinare una PKI (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 CA e selezionare Ripristina autorità di certificazione.

Informazioni sull'attributo isIssuerHintEnabled nella CA

I suggerimenti dell'emittente inviano un'indicazione di CA attendibile come parte dell'handshake TLS (Transport Layer Security). L'elenco CA attendibili è impostato in base ai CAs caricati dal cliente nell'archivio di fiducia Entra. Per ulteriori informazioni sugli indizi dell'emittente, vedere Understanding Issuer Hints.

Per impostazione predefinita, i nomi dei soggetti di tutte le Autorità di Certificazione (CA) nell'archivio di fiducia di Microsoft Entra vengono inviati come indicazioni. Se vuoi inviare un hint solo ad autorità di certificazione specifiche, imposta l'attributo 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

Ottieni l'oggetto PKI tramite l'ID PKI

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

Carica le autorità di certificazione con un file .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"
}

Ottieni tutte le CA in una PKI

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 il flag di suggerimento dell'emittente CA specifico

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>
   

Registro di controllo

Tutte le operazioni CRUD su un'infrastruttura a chiave pubblica o un'autorità di certificazione all'interno del repository di fiducia 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 implica che un utente non può utilizzare la conferma come parte del processo di 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 CBA solo per gli utenti con 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 su certificato.

4. In Abilita e destinazione, selezionare Abilitae fare clic su Riconosco.

5. Fare clic su Selezionare i gruppi, fare clic su Aggiungi gruppi.

6. Scegliere gruppi specifici come quello creato e fare clic su Selezionare. Usare gruppi specifici anziché Tutti gli utenti.

7. Al termine, fare clic su Salva.

   

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 vincolo di autenticazione

La politica di associazione dell'autenticazione aiuta a determinare il livello di sicurezza dell'autenticazione, sia a fattore singolo che a multifattore. Il livello di protezione predefinito per tutti i certificati nel tenant è 'autenticazione a fattore singolo. L'associazione di affinità predefinita a livello di tenant è bassa. Un amministratore dei criteri di autenticazione può modificare il valore predefinito da un singolo fattore a più fattori e, in caso di modifiche, tutti i certificati nel tenant verranno considerati di livello l'autenticazione a più fattori. Analogamente, l'associazione di affinità a livello di tenant può essere impostata su alto, il che significa che tutti i certificati verranno convalidati usando solo attributi di affinità elevata.

Importante

L'amministratore deve impostare il valore predefinito del tenant su un valore applicabile per la maggior parte dei certificati e creare regole personalizzate solo per certificati specifici che devono avere un livello di protezione e/o un'associazione di affinità diversa rispetto all'impostazione predefinita del tenant. La configurazione di tutti i metodi di autenticazione viene inserita nello stesso file di criteri, in modo che la creazione di più regole ridondanti possa raggiungere il limite di file dei criteri.

Le regole di associazione di autenticazione mappano gli attributi del certificato, come l'autorità di emissione, l'ID oggetto criteri (OID) o una combinazione di autorità di emissione e OID dei criteri, a un valore e selezionano sia il livello di protezione predefinito che l'associazione di affinità per quella regola. Per modificare le impostazioni predefinite del tenant e creare regole personalizzate 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 per i certificati client che richiedono valori diversi per il livello di protezione o l'associazione di affinità rispetto all'impostazione predefinita del tenant. Le regole possono essere configurate usando l'oggetto dell'autorità emittente o l'OID dei criteri o entrambi i campi nel certificato.

   Le regole di associazione di autenticazione associano gli attributi del certificato (OID autorità di certificazione o criteri) a un valore e selezionano il livello di protezione predefinito per tale regola. È possibile creare più regole. Per la configurazione seguente, si supponga che l'impostazione predefinita del tenant sia autenticazione multifattore e associazione a bassa affinità.

   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 multifattoriale ma legame di alta affinità, 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 di policy.

   2. Selezionare autenticazione a fattore singolo, legame di bassa 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'Emittente e all'OID della policy:

   1. Selezionare Emittente del certificato e OID dei criteri.

   2. Selezionare un emittente e immettere l'OID della polizza.

   3. Per la forza di autenticazione, selezionare Autenticazione a più fattori.

   4. Per l'associazione di affinità, selezionare Alto.

      

   5. Selezionare Aggiungi.

      

   6. Autenticarsi con un certificato con l'OID della policy di 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 in cui un amministratore dei criteri di autenticazione del tenant di Microsoft Entra configura una regola di autenticazione CBA utilizzando sia l'OID dell'emittente che l'OID dei 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 tramite Workplace Join, l'ID Microsoft Entra e gli scenari di aggiunta di dispositivi Microsoft Entra ibridi non sono interessati. Le regole dei criteri di autenticazione CBA che utilizzano l'OID dell'emittente oppure l'OID dei criteri non subiscono modifiche. Per attenuare il problema, gli amministratori devono:

• Modificare le regole dei criteri di autenticazione basate su certificati che usano opzioni OID sia per l'emittente che per i criteri. Rimuovi il requisito di Issuer o di Policy OID e Salva. Oppure
• Rimuovere la regola dei criteri di autenticazione che usa sia l'emittente OID che l'OID dei criteri. Creare regole che usano solo OID emittente o OID della politica.

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, selezioniamo Issuer e Serial number.

   

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

   

4. Seleziona Salva.

   Il registro di accesso mostra quale vincolo è stato utilizzato 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, Nome Principale nel certificato viene mappato nel UserPrincipalName nell'oggetto utente per identificare 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 principale dell'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, allora sai che:

• Il certificato utente viene provisionato 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 personalizzate di associazione per l'autenticazione

Verrà ora illustrato uno scenario in cui viene convalidata l'autenticazione dettagliata. Vengono create due regole delle politiche di autenticazione, una usando il soggetto emittente per soddisfare l'autenticazione a fattore singolo e un'altra usando l'OID della politica per soddisfare l'autenticazione multifattoriale.

1. Crea una regola per il soggetto dell'emittente con il livello di protezione impostato su autenticazione monofattore e il valore impostato sul valore soggetto della tua Autorità di Certificazione. Ad esempio:

   CN = WoodgroveCA

2. Creare una regola OID del criterio, con livello di protezione come autenticazione a più fattori 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. Accedere al 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'emittente 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.4 e soddisfa l'autenticazione multifattore. Analogamente, l'emittente nel certificato corrisponde al valore configurato di CN=WoodgroveCA e soddisfa l'autenticazione a fattore singolo.

11. Poiché la regola OID della politica ha la precedenza sulla regola dell'emittente, il certificato soddisfa l'autenticazione multifattoriale.

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 vincoli supportati per i criteri di vincolo del nome utente.

• IssuerAndSerialNumber>CertificateUserIds
• IssuerAndSubject>CertificateUserIds
• Oggetto>CertificateUserIds

Per impostazione predefinita, Microsoft Entra ID mappa il Nome Principale nel certificato al 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 alcuno spazio nell'Emittente o nel Soggetto.

Mappatura manuale dell'emittente e del numero di serie

Ecco un esempio di mappatura manuale per l'Emittente e il Numero di Serie. Il valore dell'emittente 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 

Mappatura manuale di questioni e argomenti

Ecco un esempio di mappatura manuale di Problema e Soggetto. Il valore dell'emittente è:

Il valore dell'oggetto è:

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

Mappatura manuale delle materie

Ecco un esempio di mappatura manuale del soggetto. Il valore dell'oggetto è:

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 del tenant.

   Importante

   Fai 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. Aggiungi un legame ad alta affinità, come SKI. Selezionare Aggiungi regola nella sezione Associazione nome utente.

8. Selezionare SKI e selezionare Aggiungi .

   

   Al termine, la regola sarà simile alla schermata seguente:

   

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

10. Creare una regola personalizzata per il binding di autenticazione.

11. Selezionare Aggiungi.

    

    Al termine, la regola sarà simile alla schermata seguente:

    Screenshot di una regola personalizzata.

12. Aggiornare CertificateUserIds con il valore SKI corretto dal certificato con l'OID della politica 9.8.7.5.

13. Eseguire il test con un certificato che ha l'OID dei criteri 9.8.7.5; l'utente deve essere autenticato tramite il vincolo SKI ed effettuare l'MFA utilizzando solo 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. Seleziona Accedi a Graph Explorer e accedi al tuo 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. Ottieni un 204 No content codice di 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'autenticazione basata su certificati 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 su dispositivi mobili (Android e iOS)
• ID utente del certificato
• Come eseguire la migrazione di utenti federati
• Domande frequenti