Pianificare una distribuzione Windows Hello for Business
Questa guida alla pianificazione consente di comprendere le diverse topologie, architetture e componenti che costituiscono l'infrastruttura di Windows Hello for Business.
In questa guida viene illustrato il ruolo di ogni componente all'interno di Windows Hello for Business e come determinate scelte di distribuzione influenzano altri aspetti dell'infrastruttura.
Suggerimento
Se si dispone di un tenant Microsoft Entra ID, è possibile usare la procedura guidata online e interattiva senza password che illustra le stesse scelte anziché usare la guida manuale seguente. La Procedura guidata senza password è disponibile nel interfaccia di amministrazione di Microsoft 365.
Uso di questa guida
Sono disponibili molte opzioni per la distribuzione di Windows Hello for Business, garantendo la compatibilità con varie infrastrutture aziendali. Anche se il processo di distribuzione può sembrare complesso, la maggior parte delle organizzazioni scoprirà di aver già implementato l'infrastruttura necessaria. È importante notare che Windows Hello for Business è un sistema distribuito e richiede una pianificazione appropriata tra più team all'interno di un'organizzazione.
Questa guida mira a semplificare il processo di distribuzione consentendo di prendere decisioni informate su ogni aspetto della distribuzione Windows Hello for Business. Fornisce informazioni sulle opzioni disponibili e consente di selezionare l'approccio di distribuzione più adatto all'ambiente.
Come procedere
Leggere questo documento e registrare le decisioni. Al termine, è necessario disporre di tutte le informazioni necessarie per valutare le opzioni disponibili e determinare i requisiti per la distribuzione Windows Hello for Business.
Quando si pianifica una distribuzione Windows Hello for Business, è necessario considerare sette aree principali:
Opzioni di distribuzione
L'obiettivo di Windows Hello for Business è consentire le distribuzioni per tutte le organizzazioni di qualsiasi dimensione o scenario. Per fornire questo tipo di distribuzione granulare, Windows Hello for Business offre una scelta diversificata di opzioni di distribuzione.
Modelli di distribuzione
È fondamentalmente importante comprendere quale modello di distribuzione usare per una distribuzione corretta. Alcuni aspetti della distribuzione potrebbero essere già stati definiti in base all'infrastruttura corrente.
È possibile scegliere tra tre modelli di distribuzione:
| Modello di distribuzione | Descrizione | |
|---|---|---|
| 🔲 | Solo cloud | Per le organizzazioni che hanno solo identità cloud e non accedono alle risorse locali. Queste organizzazioni in genere uniscono i propri dispositivi al cloud e usano esclusivamente le risorse nel cloud, ad esempio SharePoint Online, OneDrive e altre. Inoltre, poiché gli utenti non usano risorse locali, non hanno bisogno di certificati per elementi come la VPN perché tutto ciò di cui hanno bisogno è ospitato nei servizi cloud. |
| 🔲 | Ibrido | Per le organizzazioni con identità sincronizzate da Active Directory a Microsoft Entra ID. Queste organizzazioni usano applicazioni registrate in Microsoft Entra ID e vogliono un'esperienza Single Sign-On (SSO) sia per le risorse locali che Microsoft Entra. |
| 🔲 | Locale | Per le organizzazioni che non hanno identità cloud o usano applicazioni ospitate in Microsoft Entra ID. Queste organizzazioni usano applicazioni locali, integrate in Active Directory, e vogliono un'esperienza utente SSO quando vi accedono. |
Nota
- Il caso d'uso principale della distribuzione locale è per "Ambienti amministrativi di sicurezza avanzata" noto anche come "Foreste rosse"
- La migrazione da una distribuzione locale a una ibrida richiede una ridistribuzione
Tipi di trust
Il tipo di attendibilità di una distribuzione definisce il modo in cui i client Windows Hello for Business eseguono l'autenticazione in Active Directory. Il tipo di trust non influisce sull'autenticazione per Microsoft Entra ID. Per questo motivo, il tipo di trust non è applicabile a un modello di distribuzione solo cloud.
Windows Hello for Business l'autenticazione per Microsoft Entra ID usa sempre la chiave, non un certificato (escluso l'autenticazione tramite smart card in un ambiente federato).
Il tipo di trust determina se si rilasciano certificati di autenticazione agli utenti. Un modello di attendibilità non è più sicuro dell'altro.
La distribuzione di certificati a utenti e controller di dominio richiede più configurazione e infrastruttura, che potrebbe anche essere un fattore da considerare nella decisione. Un'infrastruttura più necessaria per le distribuzioni di attendibilità dei certificati include un'autorità di registrazione del certificato. In un ambiente federato è necessario attivare l'opzione Writeback del dispositivo in Microsoft Entra Connect.
È possibile scegliere tra tre tipi di attendibilità:
| Tipo di trust | Descrizione | |
|---|---|---|
| 🔲 | Cloud Kerberos | Gli utenti eseguono l'autenticazione in Active Directory richiedendo un TGT da Microsoft Entra ID, usando Microsoft Entra Kerberos. I controller di dominio locali sono ancora responsabili dei ticket di servizio Kerberos e dell'autorizzazione. L'attendibilità Kerberos cloud usa la stessa infrastruttura necessaria per l'accesso alla chiave di sicurezza FIDO2 e può essere usata per distribuzioni di Windows Hello for Business nuove o esistenti. |
| 🔲 | Chiave | Gli utenti eseguono l'autenticazione al Active Directory locale usando una chiave associata al dispositivo (hardware o software) creata durante l'esperienza di provisioning Windows Hello. È necessario distribuire i certificati ai controller di dominio. |
| 🔲 | Certificato | Il tipo di attendibilità del certificato rilascia i certificati di autenticazione agli utenti. Gli utenti eseguono l'autenticazione usando un certificato richiesto usando una chiave associata al dispositivo (hardware o software) creata durante l'esperienza di provisioning Windows Hello. |
L'attendibilità chiave e l'attendibilità del certificato usano Kerberos basato sull'autenticazione del certificato quando si richiedono ticket kerberos-granting-tickets (TCT) per l'autenticazione locale. Questo tipo di autenticazione richiede un'infrastruttura a chiave pubblica per i certificati del controller di dominio e richiede certificati dell'utente finale per l'attendibilità dei certificati.
L'obiettivo di Windows Hello for Business trust Kerberos cloud è offrire un'esperienza di distribuzione più semplice rispetto agli altri tipi di trust:
- Non è necessario distribuire un'infrastruttura a chiave pubblica (PKI) o modificare un'infrastruttura a chiave pubblica esistente
- Non è necessario sincronizzare le chiavi pubbliche tra Microsoft Entra ID e Active Directory per consentire agli utenti di accedere alle risorse locali. Non c'è alcun ritardo tra il provisioning Windows Hello for Business dell'utente e la possibilità di eseguire l'autenticazione in Active Directory
- L'accesso alla chiave di sicurezza FIDO2 può essere distribuito con una configurazione aggiuntiva minima
Suggerimento
Windows Hello for Business trust Kerberos cloud è il modello di distribuzione consigliato rispetto al modello di attendibilità chiave. È anche il modello di distribuzione preferito se non è necessario supportare scenari di autenticazione del certificato.
L'attendibilità Kerberos cloud richiede la distribuzione di Microsoft Entra Kerberos. Per altre informazioni su come Microsoft Entra Kerberos consente l'accesso alle risorse locali, vedere Abilitazione dell'accesso con chiave di sicurezza senza password alle risorse locali.
Requisiti PKI
L'attendibilità Kerberos cloud è l'unica opzione di distribuzione ibrida che non richiede la distribuzione di certificati. Gli altri modelli ibridi e locali dipendono da un'infrastruttura a chiave pubblica aziendale come ancoraggio di trust per l'autenticazione:
- I controller di dominio per le distribuzioni ibride e locali necessitano di un certificato per i dispositivi Windows per considerare legittimo il controller di dominio
- Le distribuzioni che usano il tipo di attendibilità del certificato richiedono un'infrastruttura a chiave pubblica aziendale e un'autorità di registrazione certificati (CRA) per rilasciare certificati di autenticazione agli utenti. AD FS viene usato come cra
- Le distribuzioni ibride potrebbero dover rilasciare certificati VPN agli utenti per abilitare la connettività delle risorse locali
| Modello di distribuzione | Tipo di trust | PKI richiesto? | |
|---|---|---|---|
| 🔲 | Solo cloud | n/d | no |
| 🔲 | Ibrido | Cloud Kerberos | no |
| 🔲 | Ibrido | Chiave | sì |
| 🔲 | Ibrido | Certificato | sì |
| 🔲 | Locale | Chiave | sì |
| 🔲 | Locale | Certificato | sì |
Autenticazione in Microsoft Entra ID
Gli utenti possono eseguire l'autenticazione in Microsoft Entra ID usando l'autenticazione federata o l'autenticazione cloud (non federata). I requisiti variano in base al tipo di attendibilità:
| Modello di distribuzione | Tipo di trust | Autenticazione in Microsoft Entra ID | Requisiti | |
|---|---|---|---|---|
| 🔲 | Solo cloud | n/d | Autenticazione cloud | n/d |
| 🔲 | Solo cloud | n/d | Autenticazione federata | Servizio federativo non Microsoft |
| 🔲 | Ibrido | Trust Kerberos cloud | Autenticazione cloud | Sincronizzazione dell'hash delle password (PHS) o autenticazione pass-through (PTA) |
| 🔲 | Ibrido | Trust Kerberos cloud | Autenticazione federata | AD FS o servizio federativo non Microsoft |
| 🔲 | Ibrido | Trust chiave | Autenticazione cloud | Sincronizzazione dell'hash delle password (PHS) o autenticazione pass-through (PTA) |
| 🔲 | Ibrido | Trust chiave | Autenticazione federata | AD FS o servizio federativo non Microsoft |
| 🔲 | Ibrido | Trust certificato | Autenticazione federata | Questo modello di distribuzione non supporta PTA o PHS. Active Directory deve essere federato con Microsoft Entra ID usando AD FS |
Per altre informazioni:
- Federazione con Microsoft Entra ID
- Sincronizzazione dell'hash delle password (PHS)
- Autenticazione pass-through (PTA)
Registrazione del dispositivo
Per le distribuzioni locali, il server che esegue il ruolo Active Directory Federation Services (AD FS) è responsabile della registrazione del dispositivo. Per le distribuzioni solo cloud e ibride, i dispositivi devono registrarsi in Microsoft Entra ID.
| Modello di distribuzione | Tipo di join supportato | Provider del servizio di registrazione del dispositivo |
|---|---|---|
| Solo cloud | Microsoft Entra aggiunto Microsoft Entra registrato |
Microsoft Entra ID |
| Ibrido | Microsoft Entra aggiunto Microsoft Entra aggiunto ibrido Microsoft Entra registrato |
Microsoft Entra ID |
| Locale | Aggiunta al dominio active directory | AD FS |
Importante
Per Microsoft Entra linee guida per l'aggiunta ibrida, vedere Pianificare l'implementazione di join ibridi Microsoft Entra.
Autenticazione a più fattori
L'obiettivo di Windows Hello for Business è quello di allontanare le organizzazioni dalle password fornendo loro credenziali complesse che consentano un'autenticazione a due fattori semplice. L'esperienza di provisioning predefinita accetta le credenziali deboli dell'utente (nome utente e password) come primo fattore di autenticazione. Tuttavia, l'utente deve fornire un secondo fattore di autenticazione prima che Windows eserciti una credenziale avanzata:
- Per le distribuzioni solo cloud e ibride, esistono diverse opzioni per l'autenticazione a più fattori, tra cui Microsoft Entra MFA
- Le distribuzioni locali devono usare un'opzione a più fattori che può essere integrata come adattatore a più fattori di AD FS. Le organizzazioni possono scegliere tra opzioni non Microsoft che offrono un adattatore AD FS MFA. Per altre informazioni, vedere Metodi di autenticazione aggiuntivi microsoft e non Microsoft
Importante
A partire dal 1° luglio 2019, Microsoft non offre il server MFA per le nuove distribuzioni. Le nuove distribuzioni che richiedono l'autenticazione a più fattori devono usare l'autenticazione a più fattori Microsoft Entra basata sul cloud.
A partire dal 30 settembre 2024, le distribuzioni del server Azure Multi-Factor Authentication non supportano più le richieste MFA. Per garantire servizi di autenticazione ininterrotti e rimanere in uno stato supportato, le organizzazioni devono eseguire la migrazione dei dati di autenticazione degli utenti all'autenticazione a più fattori basata sul cloud di Azure.
| Modello di distribuzione | Opzioni MFA | |
|---|---|---|
| 🔲 | Solo cloud | Microsoft Entra MFA |
| 🔲 | Solo cloud | MFA non Microsoft, tramite il metodo di autenticazione esterna in Microsoft Entra ID o federazione |
| 🔲 | Ibrido | Microsoft Entra MFA |
| 🔲 | Ibrido | MFA non Microsoft, tramite il metodo di autenticazione esterna in Microsoft Entra ID o federazione |
| 🔲 | Locale | Scheda AD FS MFA |
Per ulteriori informazioni:
- Configurare Microsoft Entra impostazioni di autenticazione a più fattori
- Gestire un metodo di autenticazione esterno in Microsoft Entra ID
Autenticazione a più fattori e autenticazione federata
È possibile che i domini federati configurino il flag FederatedIdpMfaBehavior . Il flag indica a Microsoft Entra ID di accettare, applicare o rifiutare la richiesta di autenticazione a più fattori dal provider di identità federato. Per altre informazioni, vedere Valori federatedIdpMfaBehavior. Per controllare questa impostazione, usare il comando di PowerShell seguente:
Connect-MgGraph
$DomainId = "<your federated domain name>"
Get-MgDomainFederationConfiguration -DomainId $DomainId |fl
Per rifiutare l'attestazione MFA dall'IdP federato, usare il comando seguente. Questa modifica influisce su tutti gli scenari di autenticazione a più fattori per il dominio federato:
Update-MgDomainFederationConfiguration -DomainId $DomainId -FederatedIdpMfaBehavior rejectMfaByFederatedIdp
Se si configura il flag con un valore ( acceptIfMfaDoneByFederatedIdp predefinito) o enforceMfaByFederatedIdp, è necessario verificare che l'IDP federato sia configurato correttamente e che il provider e l'adattatore MFA usati dall'IdP siano configurati correttamente.
Registrazione della chiave
L'esperienza di provisioning Windows Hello for Business predefinita crea una coppia di chiavi asimmetriche associata al dispositivo come credenziali dell'utente. La chiave privata è protetta dai moduli di sicurezza del dispositivo. Le credenziali sono una chiave utente, non una chiave del dispositivo. L'esperienza di provisioning registra la chiave pubblica dell'utente con il provider di identità:
| Modello di distribuzione | Provider del servizio di registrazione delle chiavi |
|---|---|
| Solo cloud | Microsoft Entra ID |
| Ibrido | Microsoft Entra ID |
| Locale | AD FS |
Sincronizzazione della directory
Le distribuzioni ibride e locali usano tuttavia la sincronizzazione della directory per uno scopo diverso:
- Le distribuzioni ibride usano Microsoft Entra Connect Sync per sincronizzare le identità (utenti e dispositivi) o le credenziali di Active Directory tra se stesso e Microsoft Entra ID. Durante il processo di provisioning di Window Hello for Business, gli utenti registrano la parte pubblica delle credenziali di Windows Hello for Business con Microsoft Entra ID. Microsoft Entra Connect Sync sincronizza la chiave pubblica Windows Hello for Business in Active Directory. Questa sincronizzazione consente all'accesso Single Sign-On di Microsoft Entra ID e ai relativi componenti federati.
Importante
Windows Hello for Business è associato tra un utente e un dispositivo. Sia l'oggetto utente che l'oggetto dispositivo devono essere sincronizzati tra Microsoft Entra ID e Active Directory.
- Le distribuzioni locali usano la sincronizzazione della directory per importare gli utenti da Active Directory al server Azure MFA, che invia i dati al servizio cloud MFA per eseguire la verifica
| Modello di distribuzione | Opzioni di sincronizzazione della directory |
|---|---|
| Solo cloud | n/d |
| Ibrido | Microsoft Entra Connect Sync |
| Locale | Server Azure MFA |
Importante
A partire dal 30 settembre 2024, le distribuzioni del server Azure Multi-Factor Authentication non supportano più le richieste MFA. Per garantire servizi di autenticazione ininterrotti e rimanere in uno stato supportato, le organizzazioni devono eseguire la migrazione dei dati di autenticazione degli utenti all'autenticazione a più fattori basata sul cloud di Azure.
Opzioni di configurazione del dispositivo
Windows Hello for Business offre un set completo di impostazioni dei criteri granulari. Sono disponibili due opzioni principali per configurare Windows Hello for Business: provider di servizi di configurazione (CSP) e Criteri di gruppo .
- L'opzione CSP è ideale per i dispositivi gestiti tramite una soluzione MDM (Mobile Gestione dispositivi), ad esempio Microsoft Intune. I provider di servizi di configurazione possono anche essere configurati con pacchetti di provisioning
- L'oggetto Criteri di gruppo può essere usato per configurare i dispositivi aggiunti a un dominio e in cui i dispositivi non vengono gestiti tramite MDM
| Modello di distribuzione | Opzioni di configurazione del dispositivo | |
|---|---|---|
| 🔲 | Solo cloud | CSP |
| 🔲 | Solo cloud | Oggetto Criteri di gruppo (locale) |
| 🔲 | Ibrido | CSP |
| 🔲 | Ibrido | Oggetto Criteri di gruppo (Active Directory o locale) |
| 🔲 | Locale | CSP |
| 🔲 | Locale | Oggetto Criteri di gruppo (Active Directory o locale) |
Licenze per i requisiti dei servizi cloud
Ecco alcune considerazioni sui requisiti di licenza per i servizi cloud:
- Windows Hello for Business non richiede una sottoscrizione P1 o P2 Microsoft Entra ID. Tuttavia, alcune dipendenze, ad esempio la registrazione automatica MDM e l'accesso condizionale ,
- I dispositivi gestiti tramite MDM non richiedono una sottoscrizione Microsoft Entra ID P1 o P2. Eliminando la sottoscrizione, gli utenti devono registrare manualmente i dispositivi nella soluzione MDM, ad esempio Microsoft Intune o un MDM non Microsoft supportato
- È possibile distribuire Windows Hello for Business usando il livello gratuito Microsoft Entra ID. Tutti gli account gratuiti Microsoft Entra ID possono usare Microsoft Entra'autenticazione a più fattori per le funzionalità senza password di Windows
- Alcune Microsoft Entra funzionalità di autenticazione a più fattori richiedono una licenza. Per altre informazioni, vedere Funzionalità e licenze per l'autenticazione a più fattori Microsoft Entra.
- La registrazione di un certificato tramite l'autorità di registrazione di AD FS richiede che i dispositivi eseguano l'autenticazione al server AD FS, che richiede il writeback del dispositivo, una funzionalità Microsoft Entra ID P1 o P2
| Modello di distribuzione | Tipo di trust | Licenze dei servizi cloud (minimo) | |
|---|---|---|---|
| 🔲 | Solo cloud | n/d | non obbligatorio |
| 🔲 | Ibrido | Cloud Kerberos | non obbligatorio |
| 🔲 | Ibrido | Chiave | non obbligatorio |
| 🔲 | Ibrido | Certificato | Microsoft Entra ID P1 |
| 🔲 | Locale | Chiave | Azure MFA, se usato come soluzione MFA |
| 🔲 | Locale | Certificato | Azure MFA, se usato come soluzione MFA |
Importante
A partire dal 30 settembre 2024, le distribuzioni del server Azure Multi-Factor Authentication non supportano più le richieste MFA. Per garantire servizi di autenticazione ininterrotti e rimanere in uno stato supportato, le organizzazioni devono eseguire la migrazione dei dati di autenticazione degli utenti all'autenticazione a più fattori basata sul cloud di Azure.
Requisiti del sistema operativo
Requisiti di Windows
Tutte le versioni di Windows supportate possono essere usate con Windows Hello for Business. Tuttavia, l'attendibilità Kerberos cloud richiede versioni minime:
| Modello di distribuzione | Tipo di trust | Versione di Windows | |
|---|---|---|---|
| 🔲 | Solo cloud | n/d | Tutte le versioni supportate |
| 🔲 | Ibrido | Cloud Kerberos | - Windows 10 21H2, con KB5010415 e versioni successive - Windows 11 21H2, con KB5010414 e versioni successive |
| 🔲 | Ibrido | Chiave | Tutte le versioni supportate |
| 🔲 | Ibrido | Certificato | Tutte le versioni supportate |
| 🔲 | Locale | Chiave | Tutte le versioni supportate |
| 🔲 | Locale | Certificato | Tutte le versioni supportate |
Requisiti di Windows Server
Windows Hello for Business può essere usato per eseguire l'autenticazione in tutte le versioni di Windows Server supportate come controller di dominio. Tuttavia, l'attendibilità Kerberos cloud richiede versioni minime:
| Modello di distribuzione | Tipo di trust | Versione del sistema operativo del controller di dominio | |
|---|---|---|---|
| 🔲 | Solo cloud | n/d | Tutte le versioni supportate |
| 🔲 | Ibrido | Cloud Kerberos | - Windows Server 2016, con KB3534307 e versioni successive - Windows Server 2019, con KB4534321 e versioni successive - Windows Server 2022 - Windows Server 2025 |
| 🔲 | Ibrido | Chiave | Tutte le versioni supportate |
| 🔲 | Ibrido | Certificato | Tutte le versioni supportate |
| 🔲 | Locale | Chiave | Tutte le versioni supportate |
| 🔲 | Locale | Certificato | Tutte le versioni supportate |
I livelli di funzionalità del dominio e della foresta minimi richiesti sono Windows Server 2008 R2 per tutti i modelli di distribuzione.
Preparare gli utenti
Quando si è pronti per abilitare Windows Hello for Business nell'organizzazione, assicurarsi di preparare gli utenti spiegando come effettuare il provisioning e usare Windows Hello.
Per altre informazioni, vedere Preparare gli utenti.
Passaggi successivi
Dopo aver letto le diverse opzioni e requisiti di distribuzione, è possibile scegliere l'implementazione più adatta all'organizzazione.
Per altre informazioni sul processo di distribuzione, scegliere un modello di distribuzione e un tipo di attendibilità dagli elenchi a discesa seguenti: