Configurare l'autenticazione basata su certificato di Microsoft Entra

L'organizzazione può implementare un'autenticazione resistente al phishing, moderna e senza password tramite certificati utente X.509, usando l'autenticazione basata su certificati di Microsoft Entra (CBA).

Questo articolo illustra come configurare il tenant Microsoft Entra per consentire o richiedere agli utenti tenant di eseguire l'autenticazione usando certificati X.509. Un utente crea un certificato X.509 usando un'infrastruttura a chiave pubblica (PKI) aziendale per l'accesso all'applicazione e al browser.

Quando Microsoft Entra CBA è configurato, durante l'accesso, un utente visualizza un'opzione per l'autenticazione usando un certificato anziché immettendo una password. Se nel dispositivo si trovano più certificati corrispondenti, l'utente seleziona il certificato pertinente e il certificato viene convalidato rispetto all'account utente. Se la convalida ha esito positivo, l'utente accede.

Completare i passaggi descritti in questo articolo per configurare e usare Microsoft Entra CBA per i tenant nei piani Office 365 Enterprise e US Government. È necessario avere già configurato un'infrastruttura a chiave pubblica .

Prerequisiti

Verifica che siano soddisfatti i seguenti prerequisiti:

  • Almeno un'autorità di certificazione (CA) e tutte le ca intermedie sono configurate in Microsoft Entra ID.
  • L'utente ha accesso a un certificato utente rilasciato da un'infrastruttura a chiave pubblica attendibile configurata nel tenant destinato all'autenticazione client in Microsoft Entra ID.
  • Ogni CA ha 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, Microsoft Entra ID non esegue alcun controllo CRL, la revoca dei certificati utente non funziona e l'autenticazione non viene bloccata.

Considerazioni

  • Assicurarsi che l'infrastruttura a chiave pubblica sia sicura e non possa essere facilmente compromessa. Se si verifica una violazione, l'utente malintenzionato può creare e firmare certificati client e compromettere qualsiasi utente nel tenant, inclusi gli utenti sincronizzati dall'ambiente locale. Una strategia di protezione avanzata e altri controlli fisici e logici 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 della PKI.

  • Per le procedure consigliate per Microsoft Crittografia, inclusa la scelta di algoritmi, lunghezza della chiave e protezione dei dati, vedere Microsoft raccomandazioni. Assicurarsi di usare uno degli algoritmi consigliati, una lunghezza della chiave consigliata e le curve approvate da NIST.

  • Nell'ambito dei miglioramenti continui della sicurezza, Azure e gli endpoint Microsoft 365 hanno aggiunto il supporto per TLS 1.3. Il processo richiederà alcuni mesi per coprire migliaia di endpoint di servizio in Azure e Microsoft 365. L'endpoint Microsoft Entra usato da Microsoft Entra CBA è incluso nell'aggiornamento: *.certauth.login.microsoftonline.com e *.certauth.login.microsoftonline.us.

    TLS 1.3 è la versione più recente del protocollo di sicurezza distribuito più comunemente da Internet. TLS 1.3 crittografa i dati per fornire un canale di comunicazione sicuro tra due endpoint. Elimina gli algoritmi di crittografia obsoleti, migliora la sicurezza rispetto alle versioni precedenti e crittografa la maggior parte possibile dell'handshake. È consigliabile iniziare a testare TLS 1.3 nelle applicazioni e nei servizi.

  • Quando si valuta un'infrastruttura a chiave pubblica, è importante esaminare i criteri di rilascio e l'applicazione dei certificati. Come descritto in precedenza, l'aggiunta di ca a una configurazione di Microsoft Entra consente ai certificati rilasciati da tali ca di autenticare qualsiasi utente in Microsoft Entra ID.

    È importante considerare come e quando le CA sono autorizzate a rilasciare certificati e come implementano identificatori riutilizzabili. Gli amministratori devono solo assicurarsi che un certificato specifico possa essere usato per autenticare un utente, ma che devono usare esclusivamente associazioni di affinità elevata per ottenere un livello superiore di garanzia che solo un certificato specifico possa autenticare l'utente. Per altre informazioni, vedere Associazioni ad alta affinità.

Configurare e testare Microsoft Entra CBA

Prima di attivare Microsoft Entra CBA, è necessario completare alcuni passaggi di configurazione.

Un amministratore deve configurare le ca attendibili che rilasciano certificati utente. Come illustrato nel diagramma seguente, Azure usa il controllo degli accessi in base al ruolo per assicurarsi che siano necessari solo gli amministratori con privilegi minimi per apportare modifiche.

Importante

Microsoft consiglia di usare i ruoli con le autorizzazioni più poche. 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, è possibile configurare le associazioni di autenticazione per eseguire il mapping dei certificati all'autenticazione a fattore singolo o all'autenticazione a più fattori (MFA). Configurare le associazioni di nome utente per mappare il campo del certificato a un attributo dell'oggetto utente. Un amministratore dei criteri di autenticazione può configurare le impostazioni correlate all'utente.

Al termine di tutte le configurazioni, attivare Microsoft Entra CBA nel tenant.

Diagram che mostra una panoramica dei passaggi necessari per attivare Microsoft Entra'autenticazione basata su certificati.

Passaggio 1: Configurare le CA con un archivio di fiducia basato su PKI

Microsoft Entra ha un nuovo archivio di attendibilità CA basato su PKI. L'archivio trust mantiene le ca all'interno di un oggetto contenitore per ogni infrastruttura a chiave pubblica. Gli amministratori possono gestire le ca in un contenitore in base all'infrastruttura a chiave pubblica più facilmente di quanto possano gestire un elenco semplice di ca.

L'archivio attendibilità basato su PKI presenta limiti superiori rispetto all'archivio attendibilità classico per il numero di ca e le dimensioni di ogni file ca. Un archivio delle fiducie basato su PKI supporta fino a 250 Autorità di Certificazione e 8 KB per ogni oggetto CA.

Se si usa l'archivio attendibilità classico per configurare le ca, è consigliabile configurare un archivio attendibilità basato su PKI. L'archivio attendibilità basato su PKI è scalabile e supporta nuove funzionalità, ad esempio gli hint dell'autorità di certificazione.

Un amministratore deve configurare le ca attendibili che rilasciano certificati utente. Per apportare modifiche sono necessari solo gli amministratori con privilegi minimi. A un archivio di attendibilità basato su PKI viene assegnato il ruolo Amministratore dell'autenticazione privilegiata.

La funzionalità di caricamento PKI dell'archivio trust basato su PKI è disponibile solo con una licenza P1 o P2 Microsoft Entra ID. Tuttavia, con la licenza gratuita Microsoft Entra, un amministratore può caricare singolarmente tutte le CA anziché caricando un file PKI. Possono quindi configurare l'archivio trust basato su PKI e aggiungere i file CA caricati.

Configurare le ca usando il Interfaccia di amministrazione di Microsoft Entra

Creare un oggetto contenitore PKI (Interfaccia di amministrazione di Microsoft Entra)

Per creare un oggetto contenitore PKI:

  1. Accedere al Interfaccia di amministrazione di Microsoft Entra con un account assegnato al ruolo Amministratore di autenticazione privato.

  2. Passare a Entra ID>Punteggio di Sicurezza dell'Identità>Infrastruttura a chiave pubblica.

  3. Selezionare Create PKI (Crea infrastruttura a chiave pubblica).

  4. In Nome visualizzato immettere un nome.

  5. Fare clic su Crea.

    Diagramma che mostra i passaggi necessari per creare un'infrastruttura a chiave pubblica (PKI).

  6. Per aggiungere o eliminare colonne, selezionare Modifica colonne.

  7. Per aggiornare l'elenco delle infrastrutture a chiave pubblica, selezionare Aggiorna.

Eliminare un oggetto contenitore PKI

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 nell'infrastruttura a chiave pubblica.If the PKI contains CAs, enter the name of the PKI to acknowledg the deletion of all CAs in the PKI. Selezionare quindi Elimina.

Diagramma che mostra i passaggi necessari per eliminare un'infrastruttura a chiave pubblica.Diagram that shows the steps required to delete a PKI.

Caricare singole CA in un oggetto contenitore PKI

Per caricare una CA in un contenitore PKI:

  1. Selezionare Aggiungi autorità di certificazione.

  2. Seleziona il file CA.

  3. Se la CA è un certificato radice, selezionare . In caso contrario, selezionare No.

  4. Per URL dell'elenco di revoca dei certificati, immettere l'URL accessibile da Internet per l'elenco di revoca dei certificati (CRL) di base della CA, che contiene tutti i certificati revocati. Se l'URL non è impostato, un tentativo di autenticazione tramite un certificato revocato non ha esito negativo.

  5. Per URL dell'elenco di revoche di certificati delta, inserire l'URL accessibile da internet per il CRL che contiene tutti i certificati revocati dalla pubblicazione dell'ultima CRL base.

  6. Se l'autorità di certificazione non deve essere inclusa nei suggerimenti dell'emittente, disattivare i suggerimenti dell'emittente. Il flag hint dell'emittente è disattivato per impostazione predefinita.

  7. Seleziona Salva.

  8. Per eliminare una CA, selezionare la CA e selezionare Elimina.

    Diagramma che mostra come eliminare un certificato della CA.

  9. Per aggiungere o eliminare colonne, selezionare Modifica colonne.

  10. Per aggiornare l'elenco delle infrastrutture a chiave pubblica, selezionare Aggiorna.

Inizialmente vengono visualizzati 100 certificati CA. Mentre scorri verso il basso nella finestra, ne appaiono di più.

Caricare tutte le CA in un oggetto contenitore PKI

Per caricare in blocco tutte le ca in un contenitore PKI:

  1. Creare un oggetto contenitore PKI o aprire un contenitore esistente.

  2. Selezionare Carica il PKI.

  3. Inserire l'URL HTTP accessibile da internet del file .p7b.

  4. Immettere il checksum SHA-256 del file.

  5. Selezionare il caricamento.

    Il processo di caricamento PKI è asincrono. Quando ogni CA viene caricata, è disponibile nella PKI. L'intero caricamento PKI può richiedere fino a 30 minuti.

  6. Seleziona Aggiorna per aggiornare l'elenco delle CA.

  7. Ogni attributo del punto finale CRL caricato viene aggiornato con il primo URL HTTP disponibile del certificato CA inserito come attributo dei punti di distribuzione CRL. È necessario aggiornare manualmente tutti i certificati foglia.

Per generare il checksum SHA-256 del file PKI .p7b , eseguire:

Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256

Modificare un'infrastruttura a chiave pubblica

  1. Nella riga PKI selezionare ... e selezionare Modifica.
  2. Immettere un nuovo nome PKI.
  3. Seleziona Salva.

Modificare un'Autorità di Certificazione

  1. Nella riga CA selezionare ... e selezionare Modifica.
  2. Immettere nuovi valori per il tipo CA (radice o intermedio), l'URL CRL, l'URL CRL delta o il flag 'hints abilitati' dell'emittente in base alle vostre esigenze.
  3. Seleziona Salva.

Modificare in blocco l'attributo suggerimenti dell'emittente

  1. Per modificare più CA e attivare o disattivare l'attributo suggerimenti dell'emittente abilitati, selezionare più CA.
  2. Selezionare Modifica e quindi Modifica suggerimenti per l'emittente.
  3. Selezionare la casella di controllo Suggerimenti del gestore abilitati per tutte le CA selezionate oppure deselezionare l'opzione per disattivare il flag Suggerimenti del gestore abilitati per tutte le CA selezionate. Il valore predefinito è Indeterminate.
  4. Seleziona 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 quindi selezionare Ripristina autorità di certificazione.

Configurare l'attributo isIssuerHintEnabled per una CA

I suggerimenti dell'emittente inviano un indicatore CA attendibile come parte dell'handshake Transport Layer Security (TLS). L'elenco delle CA attendibili è impostato sull'identità delle CA che il Tenant carica nell'archivio di fiducia di Microsoft Entra. Per altre informazioni, vedere Comprendere i suggerimenti dell'emittente.

Per impostazione predefinita, i nomi dei soggetti di tutte le CA nell'archivio di attendibilità di Microsoft Entra vengono inviati come suggerimenti. Se vuoi inviare una segnalazione solo per autorità di certificazione specifiche, imposta l'attributo dell'autorità di certificazione isIssuerHintEnabled su true.

Il server può restituire al client TLS una risposta massima di 16 KB per gli hint dell'autorità di certificazione (il nome soggetto della CA). È consigliabile impostare l'attributo isIssuerHintEnabled su true solo per le ca che rilasciano certificati utente.

Se più ca intermedie dello stesso certificato radice rilasciano certificati utente, per impostazione predefinita, tutti i certificati vengono visualizzati nella selezione certificati. Se imposti isIssuerHintEnabled su true per le CA specifiche, nella selezione certificati verranno visualizzati solo i certificati utente pertinenti.

Configurare le ca usando le API di Microsoft Graph

Gli esempi seguenti illustrano come usare Microsoft Graph per eseguire operazioni Create, Read, Update e Delete (CRUD) tramite metodi HTTP per un'infrastruttura a chiave pubblica o a una CA.

Creare un oggetto contenitore PKI (Microsoft Graph)

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 un oggetto PKI in base all'ID PKI

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-ID>/
ConsistencyLevel: eventual

Caricare le autorità di certificazione utilizzando 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 in 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 suggerimenti di un 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 ca tramite PowerShell

Per questi passaggi, usare Microsoft Graph PowerShell.

  1. Avviare PowerShell usando l'opzione Esegui come amministratore .

  2. Installare e importare il SDK PowerShell di Microsoft Graph:

    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>
    

Definizione delle priorità tra un archivio trust basato su PKI e un archivio ca classico

Se esiste una CA in un archivio CA basato su PKI e in un archivio CA classico, l'archivio di fiducia basato su PKI è prioritario.

Un Archivio CA classico è prioritario in questi scenari:

  • Esiste una CA in entrambi gli archivi, l'archivio basato su PKI non ha un CRL, ma la CA di archiviazione classica ha un CRL valido.
  • Esiste una CA in entrambi gli archivi e il CRL della CA dell'archivio basato su PKI è diverso dal CRL della CA dell'archivio classico.

Log di accesso

Una voce del log di accesso di Microsoft Entra interrotta ha due attributi nei Dati aggiuntivi per indicare se l'archivio di attendibilità classico o legacy è stato usato in qualsiasi modo durante l'autenticazione.

  • L'archivio legacy usato ha un valore pari a 0 per indicare che viene usato un archivio basato su PKI. Il valore 1 indica che viene usato un archivio classico o legacy.
  • Le informazioni sull'uso dell'archivio legacy visualizzano il motivo per cui viene usato l'archivio classico o legacy.

Screenshot che mostra una voce di log di accesso per l'uso di un archivio basato su PKI o di un archivio CA classico

Registro di controllo

Tutte le operazioni CRUD eseguite in un'infrastruttura a chiave pubblica o presso un'autorità di certificazione nell'archivio fidato vengono visualizzate nei log di controllo di Microsoft Entra.

Screenshot che mostra il riquadro Log di controllo.

Eseguire la migrazione da un archivio CA classico a un archivio basato su PKI

Un amministratore del tenant può caricare tutte le CA nell'archivio basato su PKI. L'archivio CA PKI ha quindi la priorità su un archivio classico e tutte le autenticazioni CBA vengono eseguite tramite l'archivio basato su PKI. Un amministratore tenant può rimuovere le CA da un archivio classico o legacy dopo aver confermato l'assenza di indicazioni nei log di accesso che indicano l'utilizzo dell'archivio classico o legacy.

Domande frequenti

Perché il caricamento dell'infrastruttura a chiave pubblica fallisce?

Verificare che il file PKI sia valido e che sia accessibile senza problemi. La dimensione massima del file PKI è di 2 MB (250 CA e 8 KB per ogni oggetto CA).

Che cos'è il contratto di servizio per il caricamento PKI?

Il caricamento PKI è un'operazione asincrona e può richiedere fino a 30 minuti.

Come si genera un checksum SHA-256 per un file PKI?

Per generare il checksum SHA-256 del file PKI .p7b , eseguire questo comando:

Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256

Passaggio 2: Attivare CBA per il cliente

Importante

Un utente è considerato in grado di completare l'autenticazione a più fattori quando è designato come incluso nell'ambito dei CBA nei criteri dei metodi di autenticazione. Questo requisito di criterio significa che un utente non può usare la prova dell'identità come parte dell'autenticazione per registrare altri metodi disponibili. Se l'utente non ha accesso ai certificati, l'utente viene bloccato e non può registrare altri metodi per l'autenticazione a più fattori. Gli amministratori a cui è assegnato il ruolo di Amministratore dei criteri di autenticazione devono attivare CBA 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 Microsoft Entra autenticazione a più fattori.

Per attivare l'autenticazione basata su certificato tramite il centro amministrativo di Microsoft Entra:

  1. Accedere al Interfaccia di amministrazione di Microsoft Entra con un account assegnato almeno al ruolo Amministratore criteri di autenticazione.

  2. Passare a Gruppi>Tutti i gruppi.

  3. Selezionare Nuovo gruppo e creare un gruppo per gli utenti CBA.

  4. Passare a Entra ID> Metodi di autenticazione>Autenticazione basata su certificati.

  5. In Abilita e destinazione selezionare Abilita e quindi selezionare la casella di controllo Conferma .

  6. Scegliere Seleziona gruppi>Aggiungi gruppi.

  7. Scegliere gruppi specifici, ad esempio quello creato e quindi scegliere Seleziona. Usare gruppi specifici anziché Tutti gli utenti.

  8. Seleziona Salva.

    Screenshot che mostra come attivare l'Autenticazione Basata su Certificato.

Dopo l'attivazione del CBA per il tenant, tutti gli utenti nel tenant visualizzano l'opzione per accedere usando un certificato. Solo gli utenti che sono in grado di usare LBA possono eseguire l'autenticazione usando un certificato X.509.

Nota

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

Passaggio 3: Configurare una policy di associazione per l'autenticazione

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

L'associazione di affinità predefinita a livello di tenant è bassa affinità. Un amministratore dei criteri di autenticazione può modificare il valore predefinito dall'autenticazione a fattore singolo a MFA. Se il livello di protezione cambia, tutti i certificati nel tenant vengono impostati su MFA. Analogamente, l'associazione di affinità a livello di tenant può essere impostata su affinità elevata. Tutti i certificati vengono quindi convalidati usando solo attributi di affinità elevata.

Importante

Un amministratore deve impostare il valore predefinito del tenant su un valore applicabile per la maggior parte dei certificati. Creare regole personalizzate solo per certificati specifici che richiedono un livello di protezione diverso o un'associazione di affinità rispetto all'impostazione predefinita del tenant. Tutte le configurazioni del metodo di autenticazione si trovano nello stesso file di criteri. La creazione di più regole ridondanti potrebbe superare il limite di dimensioni del file di criteri.

Le regole di associazione di autenticazione eseguono il mapping degli attributi del certificato, ad esempio Issuer, Policy Object ID (OID) e Issuer e Policy OID a un valore specificato. Le regole impostano il livello di protezione predefinito e il vincolo di affinità per tale regola.

Per modificare le impostazioni predefinite del tenant e creare regole personalizzate tramite il Interfaccia di amministrazione di Microsoft Entra:

  1. Accedere al Interfaccia di amministrazione di Microsoft Entra con un account assegnato almeno al ruolo Amministratore criteri di autenticazione.

  2. Passare a Entra ID> Metodi di autenticazione>Policies.

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

    Screenshot che mostra come impostare un criterio di autenticazione.

  4. Per configurare l'associazione di autenticazione e l'associazione di nome utente, selezionare Configura.

  5. Per modificare il valore predefinito in MFA, selezionare Autenticazione a più fattori. L'attributo del livello di protezione ha un valore predefinito di Autenticazione a fattore singolo.

    Nota

    Il livello di protezione predefinito è attivo se non vengono aggiunte regole personalizzate. Se si aggiunge una regola personalizzata, il livello di protezione definito a livello di regola viene rispettato anziché il livello di protezione predefinito.

    Screenshot che mostra come modificare i criteri di autenticazione predefiniti in MFA.

  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. È possibile configurare le regole usando l'oggetto dell'autorità emittente o l'OID dei criteri, o entrambi i campi, nel certificato.

    Le regole di associazione di autenticazione mappano gli attributi del certificato (OID di criteri o dell'autorità di certificazione) a un valore. Il valore imposta il livello di protezione predefinito per tale regola. È possibile creare più regole. Nell'esempio seguente si supponga che l'impostazione predefinita del tenant sia Autenticazione a più fattori e Bassa per l'associazione di affinità.

    Per aggiungere regole personalizzate, selezionare Aggiungi regola.

    Screenshot che mostra come aggiungere una regola personalizzata.

    Per creare una regola in base all'autorità emittente del certificato:

    1. Selezionare Autorità di certificazione.

    2. In Identificatore autorità di certificazione selezionare un valore pertinente.

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

    4. Per Associazione di affinità selezionare Bassa.

    5. Selezionare Aggiungi.

    6. Quando richiesto, selezionare la casella di controllo Conferma per aggiungere la regola.

      Screenshot che mostra come eseguire il mapping di un criterio MFA a un'associazione ad alta affinità.

    Per creare una regola in base all'OID della politica:

    1. Selezionare Criteri OID.

    2. Per OID della politica, immettere un valore.

    3. In Livello di autenticazione selezionare Autenticazione a singolo fattore.

    4. Per Associazione di affinità selezionare Bassa per l'associazione di affinità.

    5. Selezionare Aggiungi.

    6. Quando richiesto, selezionare la casella di controllo Conferma per aggiungere la regola.

      Screenshot che mostra la mappatura all'OID dei criteri con un'associazione a bassa affinità.

    Per creare una regola basata sull’emittente e sull'OID dei criteri:

    1. Selezionare Autorità di certificazione e OID del criterio.

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

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

    4. Per Associazione di affinità selezionare Bassa.

    5. Selezionare Aggiungi.

      Screenshot che mostra come selezionare un'associazione di affinità bassa.

      Screenshot che mostra come aggiungere un'associazione di affinità bassa.

    6. Autenticarsi con un certificato che ha un OID di criteri di 3.4.5.6 ed è emesso da CN=CBATestRootProd. Verificare che l'autenticazione passi per una richiesta a più fattori.

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

    1. Aggiungere un criterio di associazione di autenticazione. Il criterio richiede che qualsiasi certificato emesso da CN=CBATestRootProd con un OID di criteri 1.2.3.4.6 necessiti solo di un'associazione ad alta affinità. Vengono usati l'emittente e il numero di serie.

      Screenshot che mostra l'emittente e il numero di serie aggiunti nel Interfaccia di amministrazione di Microsoft Entra.

    2. Seleziona il campo del certificato. Per questo esempio, selezionare Autorità di certificazione e numero di serie.

      Screenshot che mostra come selezionare Emittente e numero di serie.

    3. L'unico attributo utente supportato è certificateUserIds. Selezionare certificateUserIds e selezionare Aggiungi.

      Schermata che mostra come aggiungere Emittente e numero di serie.

    4. Seleziona Salva.

      Il registro di accesso mostra il vincolo usato durante l'accesso e i dettagli del certificato.

      Screenshot che mostra i dettagli del registro degli accessi.

  7. Selezionare OK per salvare le regole personalizzate.

Importante

Immettere l'OID dei criteri usando il formato dell'identificatore di oggetto. Ad esempio, se il criterio di certificato indica Tutti i criteri di rilascio, inserire l'OID del criterio 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 ha effetto.

Passaggio 4: Configurare i criteri di associazione nome utente

I criteri di associazione nome utente consentono di convalidare il certificato di un utente. Per impostazione predefinita, per determinare l'utente, si esegue il mapping Principal Name nel certificato a userPrincipalName nell'oggetto utente.

Un amministratore dei criteri di autenticazione può sostituire l’impostazione predefinita e creare un mapping personalizzato. Per altre informazioni, vedere Funzionamento dell'associazione di nomi utente.

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

Importante

Se un criterio di associazione nome utente usa attributi sincronizzati come certificateUserIds, onPremisesUserPrincipalName e l'attributo userPrincipalName dell'oggetto utente, gli account con autorizzazioni amministrative nei Windows Server Active Directory locali possono apportare modifiche che influiscono su questi attributi in Microsoft Entra ID. Ad esempio, gli account con diritti delegati per gli oggetti utente o un ruolo di amministratore in Microsoft Entra Connect Server possono apportare questi tipi di modifiche.

  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 binding di nome utente ha la priorità più alta e così via.

    Screenshot che mostra una politica di associazione del nome utente.

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

  2. Seleziona Salva.

La configurazione finale è simile all'esempio seguente:

Screenshot che mostra la configurazione finale.

Passaggio 5: Verificare la configurazione

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

Testare il certificato

Nel primo test di configurazione tentare di accedere al portale MyApps usando il browser del dispositivo.

  1. Immettere il nome principale utente (UPN).

    Screenshot che mostra il nome principale utente.

  2. Selezionare Avanti.

    Screenshot che mostra un accesso usando un certificato.

    Se sono stati resi disponibili altri metodi di autenticazione, ad esempio l'accesso tramite telefono o FIDO2, gli utenti potrebbero visualizzare una finestra di dialogo di accesso diversa.

    Screenshot che mostra una finestra di dialogo di accesso alternativa.

  3. Selezionare Accedi con un certificato.

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

    Screenshot che mostra l'interfaccia utente della selezione certificati.

  5. Verificare di aver eseguito l'accesso al MyApps portal.

Se l'accesso ha esito positivo, allora sai che:

  • Il certificato utente è configurato nel tuo dispositivo di test.
  • Microsoft Entra ID è configurato correttamente per l'uso di ca attendibili.
  • L'associazione nome utente è configurata correttamente. L'utente viene trovato e autenticato.

Testare le regole personalizzate di associazione per l'autenticazione

Completare quindi uno scenario in cui si convalida l'autenticazione avanzata. Si creano due regole dei criteri di autenticazione: una usando un'autorità emittente per soddisfare l'autenticazione a singolo fattore e un'altra usando l'OID dei criteri per soddisfare l'autenticazione a più fattori.

  1. Creare una regola dell'oggetto dell'autorità di certificazione con un livello di protezione di autenticazione a fattore singolo. Impostare il valore per il soggetto della CA.

    Ad esempio:

    CN=WoodgroveCA

  2. Creare una regola OID per i criteri con un livello di protezione che prevede l'autenticazione multifattoriale. Impostare il valore su uno degli OID dei criteri nel certificato. Un esempio è 1.2.3.4.

    Screenshot che mostra la regola dei criteri OID.

  3. Creare una politica di accesso condizionale di Microsoft Entra affinché l'utente richieda l'autenticazione a più fattori. Completare i passaggi descritti in Accesso condizionale - Autenticazione a più fattori.

  4. Vai al portale MyApps. Immettere l'UPN e selezionare Avanti.

    Screenshot che mostra il nome principale utente.

  5. Selezionare Usa un certificato o una smart card.

    Screenshot che mostra l'accesso usando un certificato.

    Se sono stati resi disponibili altri metodi di autenticazione, ad esempio l'accesso tramite telefono o le chiavi di sicurezza, gli utenti potrebbero visualizzare un'altra finestra di dialogo di accesso.

    Screenshot che mostra l'accesso alternativo di login.

  6. Selezionare il certificato client e quindi selezionare Informazioni sul certificato.

    Screenshot che mostra il selettore client.

    Viene visualizzato il certificato ed è possibile verificare i valori dell'emittente e dell’OID dei criteri.

    Screenshot che mostra l'autorità emittente.

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

    Screenshot che mostra i dettagli dell'autenticazione.

  8. Selezionare il certificato client e selezionare OK.

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

Poiché la regola OID dei criteri ha la precedenza sulla regola dell'emittente, il certificato soddisfa l'autenticazione a più fattori.

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

Testare i criteri di associazione dello username

Il criterio di associazione del nome utente aiuta a convalidare il certificato dell'utente. Sono supportate tre associazioni per il criterio di associazione del nome utente:

  • IssuerAndSerialNumber > certificateUserIds
  • IssuerAndSubject > certificateUserIds
  • Subject > certificateUserIds

Per impostazione predefinita, Microsoft Entra ID esegue il mapping di Nome principale 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 descritto in precedenza.

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

Importante

Il formato dei valori di Issuer, Subject e Serial number deve essere nell'ordine inverso del formato nel certificato. Non aggiungere spazi nei valori Issuer o Subject .

Mappatura manuale dell'emittente e del numero di serie

Nell'esempio seguente viene illustrata la mappatura manuale dell'emittente 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

Screenshot che mostra la mappatura manuale per il valore Issuer.

Per ottenere il valore corretto per il numero di serie, eseguire il comando seguente. 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 certutil comando :

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 numero di serie da aggiungere certificateUserId è:

b24134139f069b49997212a86ba0ef48

Il certificateUserIds valore è:

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

Mapping manuale dell'emittente e del soggetto

Nell'esempio seguente viene dimostrato il mapping manuale dell'emittente e del soggetto.

Il valore issuer è:

Screenshot che mostra il valore Issuer quando viene usato con più binding.

Il valore Subject è:

Screenshot che mostra il valore Subject.

Il certificateUserId valore è:

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

Nell'esempio seguente viene illustrata la mappatura manuale del soggetto.

Il valore Subject è:

Screenshot che mostra un altro valore di soggetto.

Il certificateUserIds valore è:

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

Testare l'associazione di affinità

  1. Accedere al Interfaccia di amministrazione di Microsoft Entra con un account assegnato almeno al ruolo Amministratore criteri di autenticazione.

  2. Passare a Entra ID> Metodi di autenticazione>Policies.

  3. In Gestisci selezionare Autenticazione basata su certificati>.

  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 il valore binding di affinità richiesta per il tenant e non si dispone di valori corretti nell'oggetto utente. Analogamente, se si crea una regola personalizzata che si applica a tutti gli utenti e richiede un'associazione ad alta affinità, gli utenti nel tenant potrebbero essere bloccati.

    Screenshot che mostra come impostare l'associazione di affinità richiesta.

  6. Per effettuare il test, selezionare Basso per il Binding di affinità obbligatorio.

  7. Aggiungere un'associazione ad alta affinità, ad esempio l'identificatore di chiave del soggetto (SKI). In Associazione nome utente, selezionare Aggiungi regola.

  8. Selezionare SKI e selezionare Aggiungi .

    Screenshot che mostra come aggiungere un'associazione di affinità.

    Al termine, la regola è simile all'esempio seguente:

    Screenshot che mostra un'associazione di affinità completata.

  9. Per tutti gli oggetti utente, aggiornare l'attributo certificateUserIds con il valore SKI corretto dal certificato utente.

    Per altre informazioni, vedere Modelli supportati per CertificateUserIDs.

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

  11. Selezionare Aggiungi.

    Screenshot che mostra un binding di autenticazione personalizzato.

    Verificare che la regola completata sia simile all'esempio seguente:

    Screenshot che mostra una regola personalizzata.

  12. Aggiornare il valore utente certificateUserIds con il valore SKI corretto dal certificato e dall'OID dei criteri di 9.8.7.5.

  13. Eseguire il test usando un certificato con l'OID della politica di 9.8.7.5. Verificare che l'utente sia autenticato con il binding SKI e che venga richiesto di accedere utilizzando solo MFA e certificato.

Configurare CBA usando le API di Microsoft Graph

Per configurare l'autenticazione basata su certificato e impostare le associazioni di nome utente usando le API di Microsoft Graph:

  1. Passare a Microsoft Graph Explorer.

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

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

  4. Ottenere 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 X.509:

    GET https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy/authenticationMethodConfigurations/X509Certificate
    
  6. Per impostazione predefinita, il metodo di autenticazione del certificato X.509 è disattivato. Per consentire agli utenti di accedere usando un certificato, è necessario attivare 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 PATCH richiesta.

    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. Verificare che 204 No content restituisca un codice di risposta. Eseguire nuovamente la GET richiesta per assicurarsi che i criteri vengano aggiornati correttamente.

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

Configurare CBA usando Microsoft PowerShell

  1. Aprire PowerShell.

  2. Connettersi a Microsoft Graph:

    Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"
    
  3. Creare una variabile da usare per definire un 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 PATCH richiesta:

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