Condividi tramite

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 associati a Microsoft Entra o associati in modo ibrido a Microsoft Entra. 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 Kerberos (TGT) per uno o più dei tuoi 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 di dominio 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 Microsoft Entra Primary Refresh Token (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 Microsoft Entra PRT e un TGT completo di Active Directory e può accedere sia alle risorse cloud che on-premises.

Prerequisiti

Prima di iniziare le procedure descritte in questo articolo, l'organizzazione deve completare le istruzioni in Abilitare passkey (FIDO2) per l'organizzazione.

È 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 Kerberos è configurata nei controller di dominio.

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

    • Utente di Active Directory membro del gruppo Domain Admins per un dominio e membro del gruppo Enterprise Admins per una foresta. Indicato come $domainCred.
    • Un utente di Microsoft Entra con il ruolo Hybrid Identity Administrators . Riferito come $cloudCred.

  • Gli utenti devono avere i seguenti attributi di Microsoft Entra popolati tramite Microsoft Entra Connect:

    • onPremisesSamAccountName (accountName in Microsoft Entra Connect)
    • onPremisesDomainName (domainFQDN in Microsoft Entra Connect)
    • onPremisesSecurityIdentifier (objectSID in Microsoft Entra Connect)

    Microsoft Entra Connect sincronizza questi attributi per impostazione predefinita. Se si modificano gli attributi da sincronizzare, assicurarsi di selezionare accountName, domainFQDNe objectSID per la sincronizzazione.

Scenari supportati

Lo scenario di questo articolo supporta l'SSO in entrambi i casi 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

Non sono supportati gli scenari seguenti:

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

Installare il modulo AzureADHybridAuthenticationManagement

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 modulo AzureADHybridAuthenticationManagement:

    # 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

  • A partire dall'aggiornamento 2.3.331.0, il modulo AzureADHybridAuthenticationManagement non installa il modulo AzureADPreview.
  • È 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 Connect.
  • 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

Gli amministratori usano il AzureADHybridAuthenticationManagement modulo per creare un oggetto server Kerberos di Microsoft Entra nella directory locale. L'oggetto deve essere creato nel server Microsoft Entra Connect o in un server in cui è installata la dipendenza Microsoft.Online.PasswordSynchronization.Rpc.dll.

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

Suggerimento

Per ulteriori informazioni sul confronto tra i cloud commerciali e sovrani di Azure, vedere: Differenze tra i cloud commerciali e sovrani di Azure.

Esempio 1: richiesta per tutte le credenziali

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

# Enter an Azure Active Directory Hybrid Identity Administrator username and password.
$cloudCred = Get-Credential -Message 'An Active Directory user who is a member of the Hybrid Identity Administrators group for Microsoft Entra ID.'

# 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 Microsoft Entra ID 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 Microsoft Entra ID
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN

# Enter an Azure Active Directory Hybrid Identity Administrator username and password.
$cloudCred = Get-Credential

# Create the new Microsoft Entra ID 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 immettere tutte le credenziali con 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 di identità ibrida.

  • 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 di identità ibrida.
# Specify the on-premises Active Directory domain. A new Microsoft Entra ID
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN

# Enter a UPN of a Hybrid Identity Administrator
$userPrincipalName = "administrator@contoso.onmicrosoft.com"

# Enter a Domain Administrator username and password.
$domainCred = Get-Credential

# Create the new Microsoft Entra ID 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 Microsoft Entra ID.
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential $domainCred

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

Nota

Se si usa 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 di identità ibrida. È anche possibile ignorare il parametro "-DomainCredential". > - Sostituire administrator@contoso.onmicrosoft.com nell'esempio seguente con l'UPN di un amministratore di identità ibrida.

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

# Enter a UPN of a Hybrid Identity Administrator
$userPrincipalName = "administrator@contoso.onmicrosoft.com"

# Create the new Microsoft Entra ID 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 Microsoft Entra ID.
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 assicura che il tentativo di associazione RPC al controller di dominio avvenga tramite Kerberos in modo corretto. 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 ADConnect 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
Identificativo ID univoco dell'oggetto di Active Directory Domain Services (AD DS) DC. A volte questo ID è indicato come slot o ID ramo.
DomainDnsName (Nome Dns del Dominio) Nome di dominio DNS del dominio Di Active Directory.
ComputerAccount L'oggetto dell'account computer dell'oggetto server Kerberos di Microsoft Entra (il DC).
Account utente 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>.
Versione Chiave Versione chiave della chiave di crittografia TGT del server Kerberos di Microsoft Entra. 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 sono maggiori 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.
ChiaveAggiornataIl Data e ora in cui la chiave di crittografia TGT del server Microsoft Entra Kerberos è stata aggiornata o creata.
ChiaveAggiornataDa 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 nella 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.
CloudKeyAggiornatoSu KeyUpdatedOn dall'oggetto Microsoft Entra. Deve corrispondere al valore KeyUpdatedOn dalla sesta riga della tabella.

Ruotare la chiave Kerberos del server 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 di 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 di Microsoft Entra viene rappresentato in Microsoft Entra ID come oggetto KerberosDomain. Ogni dominio Active Directory locale è rappresentato come un singolo oggetto KerberosDomain in Microsoft Entra ID.

Ad esempio, supponiamo che l'organizzazione abbia una foresta di Active Directory con due domini denominati contoso.com e fabrikam.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. Apri Feedback Hub e assicurati 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

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 registrato per discutere come i loro dispositivi possono essere abilitati con un PIN o un metodo biometrico come secondo fattore.

Gli amministratori possono configurare le chiavi di sicurezza?

Stiamo lavorando su questa funzionalità per il rilascio per la disponibilità generale (GA) di questa caratteristica.

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 partecipante ibrido a Microsoft Entra, dopo l'aggiunta al dominio e il processo di riavvio, è necessario effettuare l'accesso con una password e attendere che le politiche vengano sincronizzate 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?

Accertati che siano state applicate patch a un numero sufficiente di controller di dominio per rispondere in tempo e soddisfare la richiesta di risorse. Per verificare se un controller di dominio esegue la funzionalità, eseguire il comando nltest /dsgetdc:contoso /keylist /kdc e quindi esaminare l'output.

Nota

L'opzione /keylist nel comando nltest è disponibile nel client Windows 10 v2004 e nelle 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 login Windows FIDO2 cerca un controller di dominio scrivibile per scambiare il TGT dell'utente. Finché si dispone di almeno un controller di dominio scrivibile per ogni sito, il login funziona correttamente.

Passaggi successivi

Altre informazioni sull'autenticazione senza password