Abilitare l'accesso tramite chiave di sicurezza senza password alle risorse locali tramite Microsoft Entra ID

  • Articolo

Questo argomento illustra come abilitare l'autenticazione senza password alle risorse locali per gli ambienti con dispositivi che eseguono Windows 10 versione 2004 o successiva. I dispositivi possono essere aggiunti a Microsoft Entra o aggiunti a Microsoft Entra ibrido. Questa funzionalità di autenticazione senza password offre accesso Single Sign-On (SSO) facile alle risorse locali quando si usano chiavi di sicurezza compatibili con Microsoft o con attendibilità di Windows Hello for Business Cloud.

Usare l'accesso SSO per accedere alle risorse locali usando le chiavi FIDO2

Microsoft Entra ID può emettere ticket di concessione ticket Kerberos (TGT) per uno o più domini di Active Directory. Con questa funzionalità, gli utenti possono accedere a Windows con credenziali moderne, ad esempio chiavi di sicurezza FIDO2, e quindi accedere alle risorse tradizionali basate su Active Directory. I ticket di servizio Kerberos e l'autorizzazione continuano a essere controllati dai controller di dominio Active Directory locale.

Nell'istanza di Active Directory locale viene creato un oggetto server Kerberos di Microsoft Entra e quindi pubblicato in modo sicuro in Microsoft Entra ID. L'oggetto non è associato ad alcun server fisico. Si tratta semplicemente di una risorsa che può essere usata da Microsoft Entra ID per generare TGT Kerberos per il dominio di Active Directory.

Diagramma che mostra come ottenere un TGT da Microsoft Entra ID e servizi Dominio di Active Directory.

  1. Un utente accede a un dispositivo Windows 10 con una chiave di sicurezza FIDO2 ed esegue l'autenticazione con Microsoft Entra ID.

  2. Microsoft Entra ID controlla la directory di una chiave server Kerberos corrispondente al dominio di Active Directory locale dell'utente.

    Microsoft Entra ID genera un TGT Kerberos per il dominio di Active Directory locale dell'utente. Il TGT include solo il SID dell'utente e nessun dato di autorizzazione.

  3. Il TGT viene restituito al client insieme al token di aggiornamento primario (PRT) dell'utente.

  4. Il computer client contatta un controller di dominio Active Directory locale e scambia il TGT parziale per un TGT completamente formato.

  5. Il computer client ha ora un token di aggiornamento primario Microsoft Entra e un TGT di Active Directory completo e può accedere sia alle risorse cloud che locali.

Prerequisiti

Prima di iniziare le procedure descritte in questo articolo, l'organizzazione deve completare le istruzioni in Abilitare l'accesso con chiave di sicurezza senza password ai dispositivi Windows 10.

È inoltre necessario soddisfare i requisiti di sistema seguenti:

  • I dispositivi devono eseguire Windows 10 versione 2004 o successiva.

  • I controller di dominio di Windows Server devono eseguire Windows Server 2016 o versione successiva e avere patch installate per i server seguenti:

  • AES256_HMAC_SHA1 deve essere abilitato quando la sicurezza di rete: configurare i tipi di crittografia consentiti per i criteri Kerberos nei controller di dominio.

  • Disporre delle credenziali necessarie per completare i passaggi nello scenario:

    • Un utente di Active Directory membro del gruppo Domain Amministrazione s per un dominio e un membro del gruppo Enterprise Amministrazione s per una foresta. Detto $domainCred.
    • Utente di Microsoft Entra membro del ruolo Global Amministrazione istrators. Detto $cloudCred.

  • Gli utenti devono avere gli attributi seguenti di Microsoft Entra ID popolati tramite Microsoft Entra Connessione:

    • onPremisesSamAccountName (accountName in Entra Connessione)
    • onPremisesDomainName (domainFQDN in Entra Connessione)
    • onPremisesSecurityIdentifier (objectSID in Entra Connessione)

    Entra Connessione sincronizza questi attributi per impostazione predefinita. Se si modificano gli attributi da sincronizzare, selezionare accountName, domainFQDN e objectSID per la sincronizzazione.

Scenari supportati

Lo scenario di questo articolo supporta l'accesso SSO in entrambe le istanze seguenti:

  • Risorse cloud come Microsoft 365 e altre applicazioni abilitate per SAML (Security Assertion Markup Language).
  • Risorse locali e autenticazione integrata di Windows nei siti Web. Le risorse possono includere siti Web e siti di SharePoint che richiedono l'autenticazione IIS e/o le risorse che usano l'autenticazione NTLM.

Scenari non supportati

Gli scenari seguenti non sono supportati:

  • Distribuzione di Windows Server Dominio di Active Directory Services (AD DS) aggiunta (solo dispositivi locali).
  • Remote Desktop Protocol (RDP), vDI (Virtual Desktop Infrastructure) e scenari Citrix usando una chiave di sicurezza.
  • S/MIME usando una chiave di sicurezza.
  • Eseguire come usando una chiave di sicurezza.
  • Accedere a un server usando una chiave di sicurezza.

Installare il AzureADHybridAuthenticationManagement modulo

Il AzureADHybridAuthenticationManagement modulo fornisce funzionalità di gestione FIDO2 per gli amministratori.

  1. Aprire un prompt di PowerShell usando l'opzione Esegui come amministratore.

  2. Installare il AzureADHybridAuthenticationManagement modulo:

    # First, ensure TLS 1.2 for PowerShell gallery access.
[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12

# Install the AzureADHybridAuthenticationManagement PowerShell module.
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

Nota

  • Il AzureADHybridAuthenticationManagement modulo usa il modulo PowerShell AzureADPreview per fornire funzionalità avanzate di gestione di Microsoft Entra. Se il modulo PowerShell di Azure Active Directory è già installato nel computer locale, l'installazione descritta qui potrebbe non riuscire a causa di un conflitto. Per evitare conflitti durante l'installazione, assicurarsi di includere il flag di opzione "-AllowClobber".
  • È possibile installare il AzureADHybridAuthenticationManagement modulo in qualsiasi computer da cui è possibile accedere al controller di dominio Active Directory locale, senza dipendenze dalla soluzione Microsoft Entra Connessione.
  • Il AzureADHybridAuthenticationManagement modulo viene distribuito tramite PowerShell Gallery. PowerShell Gallery è il repository centrale per i contenuti PowerShell. In esso è possibile trovare moduli di PowerShell utili che contengono comandi di PowerShell e risorse DSC (Desired State Configuration).

Creare un oggetto Server Kerberos

Amministrazione istrators usano il AzureADHybridAuthenticationManagement modulo per creare un oggetto server Kerberos di Microsoft Entra nella directory locale.

Eseguire i passaggi seguenti in ogni dominio e foresta dell'organizzazione che contengono utenti di Microsoft Entra:

  1. Aprire un prompt di PowerShell usando l'opzione Esegui come amministratore.
  2. Eseguire i comandi di PowerShell seguenti per creare un nuovo oggetto server Kerberos di Microsoft Entra sia nel dominio Active Directory locale che nel tenant di Microsoft Entra.

Selezionare Cloud di Azure (il valore predefinito è Azure Commercial)

Per impostazione predefinita, il Set-AzureADKerberosSever cmdlet userà gli endpoint cloud commerciali. Se si configura Kerberos in un altro ambiente cloud, è necessario impostare il cmdlet per usare il cloud specificato.

Per ottenere un elenco dei cloud disponibili e il valore numerico necessario per modificare, eseguire le operazioni seguenti:
Get-AzureADKerberosServerEndpoint

Output di esempio:

Current Endpoint = 0(Public)
Supported Endpoints:
   0 :Public
   1 :China
   2 :Us Government

Prendere nota del valore numerico accanto all'ambiente cloud desiderato.

Per impostare quindi l'ambiente cloud desiderato, eseguire quanto segue:
(ad esempio: per il cloud del governo degli Stati Uniti)
Set-AzureADKerberosServerEndpoint -TargetEndpoint 2

Esempio 1 richiesta di tutte le credenziali

# Specify the on-premises Active Directory domain. A new Azure AD
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN

# Enter an Azure Active Directory global administrator username and password.
$cloudCred = Get-Credential -Message 'An Active Directory user who is a member of the Global Administrators group for Azure AD.'

# Enter a domain administrator username and password.
$domainCred = Get-Credential -Message 'An Active Directory user who is a member of the Domain Admins group.'

# Create the new Azure AD Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred

Esempio 2 richiesta di credenziali cloud

Nota

Se si usa un computer aggiunto a un dominio con un account con privilegi di amministratore di dominio, è possibile ignorare il parametro "-DomainCredential". Se il parametro "-DomainCredential" non è specificato, le credenziali di accesso di Windows correnti vengono usate per accedere al controller di dominio Active Directory locale.

# Specify the on-premises Active Directory domain. A new Azure AD
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN

# Enter an Azure Active Directory global administrator username and password.
$cloudCred = Get-Credential

# Create the new Azure AD Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
# Use the current windows login credential to access the on-premises AD.
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred

Esempio 3: richiesta di tutte le credenziali con l'autenticazione moderna

Nota

Se l'organizzazione protegge l'accesso basato su password e applica metodi di autenticazione moderni, ad esempio l'autenticazione a più fattori, FIDO2 o la tecnologia smart card, è necessario usare il -UserPrincipalName parametro con il nome dell'entità utente (UPN) di un amministratore globale.

  • Sostituire contoso.corp.com nell'esempio seguente con il nome di dominio Active Directory locale.
  • Sostituire administrator@contoso.onmicrosoft.com nell'esempio seguente con l'UPN di un amministratore globale.
# Specify the on-premises Active Directory domain. A new Azure AD
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN

# Enter a UPN of an Azure Active Directory global administrator
$userPrincipalName = "administrator@contoso.onmicrosoft.com"

# Enter a domain administrator username and password.
$domainCred = Get-Credential

# Create the new Azure AD Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
# Open an interactive sign-in prompt with given username to access the Azure AD.
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential $domainCred

Esempio 4: richiesta di credenziali cloud con l'autenticazione moderna

Nota

Se si lavora su un computer aggiunto a un dominio con un account con privilegi di amministratore di dominio e l'organizzazione protegge l'accesso basato su password e applica metodi di autenticazione moderni, ad esempio l'autenticazione a più fattori, FIDO2 o la tecnologia smart card, è necessario usare il -UserPrincipalName parametro con il nome dell'entità utente (UPN) di un amministratore globale. È anche possibile ignorare il parametro "-DomainCredential". > - Sostituire administrator@contoso.onmicrosoft.com nell'esempio seguente con l'UPN di un amministratore globale.

# Specify the on-premises Active Directory domain. A new Azure AD
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN

# Enter a UPN of an Azure Active Directory global administrator
$userPrincipalName = "administrator@contoso.onmicrosoft.com"

# Create the new Azure AD Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
# Open an interactive sign-in prompt with given username to access the Azure AD.
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName

Visualizzare e verificare il server Kerberos di Microsoft Entra

È possibile visualizzare e verificare il server Kerberos Microsoft Entra appena creato usando il comando seguente:

 # When prompted to provide domain credentials use the userprincipalname format for the username instead of domain\username
Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential (get-credential)

Questo comando restituisce le proprietà del server Kerberos Microsoft Entra. È possibile esaminare le proprietà per verificare che tutto sia in buon ordine.

Nota

L'esecuzione su un altro dominio specificando le credenziali nel formato dominio\nomeutente si connetterà tramite NTLM e quindi avrà esito negativo. Tuttavia, l'uso del formato userprincipalname per l'amministratore di dominio garantisce che l'associazione RPC al controller di dominio venga tentata correttamente usando Kerberos. Se gli utenti si trovano nel gruppo di sicurezza Utenti protetti in Active Directory, completare questi passaggi per risolvere il problema: Accedere come un altro utente di dominio in AD Connessione e non fornire "-domainCredential". Viene usato il ticket Kerberos dell'utente attualmente connesso. È possibile verificare eseguendo whoami /groups per verificare se l'utente dispone delle autorizzazioni necessarie in Active Directory per eseguire il comando precedente.

Proprietà Descrizione
ID ID univoco dell'oggetto DC di Active Directory Domain Services. Questo ID viene talvolta definito slot o ID ramo.
DomainDnsName Nome di dominio DNS del dominio Di Active Directory.
ComputerAccount Oggetto account computer dell'oggetto server Kerberos Microsoft Entra (dc).
UserAccount Oggetto account utente disabilitato che contiene la chiave di crittografia TGT del server Microsoft Entra Kerberos. Il nome di dominio di questo account è CN=krbtgt_AzureAD,CN=Users,<Domain-DN>.
KeyVersion Versione chiave della chiave della chiave di crittografia TGT del server Microsoft Entra Kerberos. La versione viene assegnata al momento della creazione della chiave. La versione viene quindi incrementata ogni volta che la chiave viene ruotata. Gli incrementi sono basati sui metadati di replica e probabilmente maggiore di uno. Ad esempio, l'oggetto KeyVersion iniziale potrebbe essere 192272. La prima volta che viene ruotata la chiave, la versione potrebbe passare a 212621. L'aspetto importante da verificare è che KeyVersion per l'oggetto locale e CloudKeyVersion per l'oggetto cloud siano gli stessi.
KeyUpdatedOn Data e ora in cui la chiave di crittografia TGT del server Microsoft Entra Kerberos è stata aggiornata o creata.
KeyUpdatedFrom Controller di dominio in cui è stata aggiornata l'ultima chiave di crittografia TGT del server Microsoft Entra Kerberos.
CloudId ID dell'oggetto Microsoft Entra. Deve corrispondere all'ID dalla prima riga della tabella.
CloudDomainDnsName DomainDnsName dall'oggetto Microsoft Entra. Deve corrispondere a DomainDnsName dalla seconda riga della tabella.
CloudKeyVersion KeyVersion dall'oggetto Microsoft Entra. Deve corrispondere a KeyVersion dalla quinta riga della tabella.
CloudKeyUpdatedOn KeyUpdatedOn dall'oggetto Microsoft Entra. Deve corrispondere a KeyUpdatedOn dalla sesta riga della tabella.

Ruotare la chiave del server Kerberos di Microsoft Entra

Le chiavi krbtgt di crittografia del server Kerberos di Microsoft Entra devono essere ruotate regolarmente. È consigliabile seguire la stessa pianificazione usata per ruotare tutte le altre chiavi krbtgt del controller di dominio Active Directory.

Avviso

Ci sono altri strumenti che potrebbero ruotare le chiavi krbtgt . Tuttavia, è necessario usare gli strumenti indicati in questo documento per ruotare le chiavi krbtgt del server Kerberos di Microsoft Entra. In questo modo, le chiavi vengono aggiornate sia in Active Directory locale che in Microsoft Entra ID.

Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred -RotateServerKey

Rimuovere il server Kerberos Microsoft Entra

Se si vuole ripristinare lo scenario e rimuovere il server Kerberos Di Microsoft Entra sia dal Active Directory locale che dall'ID Entra Microsoft, eseguire il comando seguente:

Remove-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred

Scenari multiforesta e multidominio

L'oggetto server Kerberos Microsoft Entra è rappresentato in Microsoft Entra ID come oggetto KerberosDomain . Ogni dominio Active Directory locale è rappresentato come un singolo oggetto KerberosDomain in Microsoft Entra ID.

Si supponga, ad esempio, che l'organizzazione abbia una foresta Active Directory con due domini e contoso.comfabrikam.com. Se si sceglie di consentire a Microsoft Entra ID di emettere TGT Kerberos per l'intera foresta, sono presenti due oggetti KerberosDomain in Microsoft Entra ID, un oggetto KerberosDomain per contoso.com e l'altro per fabrikam.com. Se sono presenti più foreste di Active Directory, è presente un oggetto KerberosDomain per ogni dominio in ogni foresta.

Seguire le istruzioni in Creare un oggetto Server Kerberos in ogni dominio e foresta dell'organizzazione che contiene gli utenti di Microsoft Entra.

Comportamento noto

Se la password è scaduta, l'accesso con FIDO viene bloccato. L'aspettativa è che gli utenti reimpostano le password prima di poter accedere usando FIDO. Questo comportamento si applica anche all'accesso utente sincronizzato locale ibrido con attendibilità Kerberos del cloud Windows Hello for Business.

Risoluzione dei problemi e commenti e suggerimenti

Se si verificano problemi o si vuole condividere commenti e suggerimenti su questa funzionalità di accesso con chiave di sicurezza senza password, condividere tramite l'app Hub di Windows Feedback seguendo questa procedura:

  1. Aprire Hub di Feedback e assicurarsi di aver eseguito l'accesso.
  2. Inviare commenti e suggerimenti selezionando le categorie seguenti:
    • Categoria: Sicurezza e privacy
    • Sottocategoria: FIDO
  3. Per acquisire i log, usare l'opzione Ricrea il problema .

Domande frequenti sulla chiave di sicurezza senza password

Suggerimento

I passaggi descritti in questo articolo possono variare leggermente in base al portale da cui si inizia.

Ecco alcune risposte alle domande frequenti sull'accesso senza password:

L'accesso con chiave di sicurezza senza password funziona nell'ambiente locale?

La funzionalità non funziona in un ambiente di Active Directory Domain Services locale puro.

L'organizzazione richiede l'autenticazione a due fattori per accedere alle risorse. Cosa è possibile fare per supportare questo requisito?

Le chiavi di sicurezza sono disponibili in diversi fattori di forma. Contattare il produttore del dispositivo di record per illustrare come i dispositivi possono essere abilitati con un PIN o una biometria come secondo fattore.

Gli amministratori possono configurare le chiavi di sicurezza?

Questa funzionalità viene usata per la versione disponibile a livello generale di questa funzionalità.

Dove è possibile trovare chiavi di sicurezza conformi?

Per informazioni sulle chiavi di sicurezza conformi, vedere Chiavi di sicurezza FIDO2.

Cosa è possibile fare se si perde la chiave di sicurezza?

Per eliminare una chiave di sicurezza registrata, accedere al myaccount.microsoft.com e quindi passare alla pagina Informazioni di sicurezza.

Cosa è possibile fare se non è possibile usare la chiave di sicurezza FIDO subito dopo aver creato un computer aggiunto ibrido a Microsoft Entra?

Se si sta eseguendo l'installazione pulita di un computer aggiunto ibrido a Microsoft Entra, dopo l'aggiunta al dominio e il processo di riavvio, è necessario accedere con una password e attendere che il criterio venga sincronizzato prima di poter usare la chiave di sicurezza FIDO per accedere.

  • Controllare lo stato corrente eseguendo dsregcmd /status in una finestra del prompt dei comandi e verificare che sia gli stati AzureAdJoined che DomainJoined siano visualizzati come SÌ.
  • Questo ritardo nella sincronizzazione è una limitazione nota dei dispositivi aggiunti a un dominio e non è specifico di FIDO.

Cosa accade se non è possibile ottenere l'accesso Single Sign-On alla risorsa di rete NTLM dopo l'accesso con FIDO e ottenere una richiesta di credenziali?

Assicurarsi che siano state applicate patch a un numero sufficiente di controller di dominio per rispondere in tempo per gestire la richiesta di risorsa. Per verificare se un controller di dominio esegue la funzionalità, eseguire nltest /dsgetdc:contoso /keylist /kdce quindi esaminare l'output.

Nota

L'opzione /keylist nel nltest comando è disponibile nel client Windows 10 v2004 e versioni successive.

Le chiavi di sicurezza FIDO2 funzionano in un account di accesso di Windows con controller di dominio di sola lettura presente nell'ambiente ibrido?

Un account di accesso di Windows FIDO2 cerca un controller di dominio scrivibile per scambiare il TGT dell'utente. Se si dispone di almeno un controller di dominio scrivibile per sito, l'account di accesso funziona correttamente.

Passaggi successivi

Altre informazioni sull'autenticazione senza password