Accedere a Windows e alle risorse interne con la chiave FIDO2: oggetto Kerberos e Cloud Kerberos Trust!.
Cosa serve perché la chiave funzioni anche per aprire il PC e raggiungere cartelle di rete e applicazioni di Active Directory: requisiti, comandi PowerShell, criteri e limiti.
Con una chiave FIDO2 registrata si entra in Microsoft 365. Per aprire il PC Windows e continuare a usare cartelle di rete, stampanti e applicazioni integrate con Active Directory serve un passaggio in più: Entra ID deve poter emettere un ticket Kerberos per il dominio. Si ottiene creando una volta per dominio un oggetto server Kerberos di Entra.
Requisiti
PC client
- Windows 10 versione 2004 o successiva (la pagina Microsoft non cita Windows 11 in modo esplicito: provalo su un PC pilota), uniti a Entra ID oppure in hybrid join. I PC uniti solo ad Active Directory non sono supportati.
Domain controller
- Windows Server 2016 o successivo con le patch KB4534307 (Server 2016) o KB4534321 (Server 2019) installate.
- Almeno un DC scrivibile per sito. I DC di sola lettura sono ammessi purché ci sia un DC scrivibile.
- Se hai il criterio "Configura i tipi di crittografia consentiti per Kerberos", deve essere abilitato AES256_HMAC_SHA1.
Attributi sincronizzati: onPremisesSamAccountName, onPremisesDomainName, onPremisesSecurityIdentifier. Entra Connect li sincronizza di default: non escluderli se personalizzi.
Account per la procedura: un utente AD membro di Domain Admins ed Enterprise Admins e un utente Entra con ruolo Hybrid Identity Administrator.
Prima di tutto: le passkey FIDO2 devono già essere abilitate nel tenant (articolo precedente).
1. Creare l'oggetto Kerberos
Sul server di Entra Connect (o su un server con la DLL Microsoft.Online.PasswordSynchronization.Rpc.dll), in PowerShell come amministratore:
[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber
$domain = $env:USERDNSDOMAIN
$cloudCred = Get-Credential # utente Entra, Hybrid Identity Administrator
$domainCred = Get-Credential # utente AD, Domain + Enterprise Admins
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred
Se il tenant impone MFA o FIDO2 anche per la password, al posto di -CloudCredential si usa -UserPrincipalName con l'UPN dell'amministratore Entra.
Verifica che gli identificativi cloud e on-premises coincidano:
Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $upn -DomainCredential (Get-Credential)
Confronta CloudId, CloudDomainDnsName, CloudKeyVersion e CloudKeyUpdatedOn.
Nel dominio compare un oggetto computer AzureADKerberos nell'unità Domain Controllers: sembra un RODC ma non è un server fisico. Non allentare i criteri di replica delle password di quell'oggetto per far funzionare gli account privilegiati.
Il comando va ripetuto per ogni dominio che contiene utenti Entra. La chiave si ruota con -RotateServerKey, in linea con la rotazione di krbtgt; usa solo questo strumento per farlo.
2. Criteri sui PC (Intune)
Per l'accesso a Windows con Windows Hello for Business con cloud trust, crea un criterio Settings catalog assegnato ai dispositivi:
- Use Windows Hello For Business — Valore: true
- Use Cloud Trust For On Prem Auth — Valore: Enabled
- Require Security Device — Valore: true
Se non usi Intune, esistono i criteri di gruppo equivalenti; l'elenco con i percorsi esatti è nella pagina Microsoft sulle impostazioni di Windows Hello for Business. Se applichi sia GPO sia Intune, prevalgono i GPO. Non deve essere configurato "Usa certificato per l'autenticazione locale", che ha la precedenza.
Per la sola chiave di sicurezza come credenziale di accesso a Windows, nei criteri dei dispositivi va abilitata l'opzione di accesso con chiave di sicurezza; la pagina Microsoft sulle passkey in Windows contiene i passaggi.
3. Test
PC Windows 11 in hybrid join, schermata di accesso → Opzioni di accesso → icona della chiave di sicurezza → inserire la chiave, PIN, toccare. Poi prova a raggiungere una cartella condivisa: non deve chiedere la password.
Subito dopo una nuova installazione di un PC, accedi con la password e attendi la sincronizzazione dei criteri; verifica con dsregcmd /status che compaiano AzureAdJoined : YES e DomainJoined : YES.
Limiti da conoscere
- Non funziona per RDP, VDI e Citrix con la chiave, per S/MIME, per "esegui come" e per l'accesso a un server con la chiave. Per questi casi serve ancora la password di dominio.
- Se la password è scaduta, l'accesso con la chiave è bloccato finché non viene reimpostata.
- Il token Kerberos supporta al massimo 1.010 gruppi.
- Il resto delle risorse (cartelle, applicazioni) ottiene l'SSO solo se il DC risponde: se compaiono richieste NTLM dopo l'accesso, controlla con
nltest /dsgetdc:<dominio> /keylist /kdcche abbastanza DC siano aggiornati.
Cosa significa per l'organizzazione
La password di dominio resta: serve per i server, per le sessioni remote e come strada di emergenza. L'obiettivo realistico è che nel lavoro quotidiano nessuno la digiti più.