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 agli utenti e ai controller di dominio richiede una maggiore 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
🔲 Ibrido Certificato
🔲 Locale Chiave
🔲 Locale Certificato

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:

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. La distribuzione esistente in cui il server MFA è stato attivato prima del 1° luglio 2019 può scaricare la versione più recente, gli aggiornamenti futuri e generare le credenziali di attivazione. Per altre informazioni, vedere Introduzione al server Azure Multi-Factor Authentication.

Modello di distribuzione Opzioni MFA
🔲 Solo cloud Microsoft Entra MFA
🔲 Solo cloud MFA non Microsoft tramite Microsoft Entra ID controlli personalizzati o federazione
🔲 Ibrido Microsoft Entra MFA
🔲 Ibrido MFA non Microsoft tramite Microsoft Entra ID controlli personalizzati o federazione
🔲 Locale Scheda AD FS MFA

Per altre informazioni su come configurare l'autenticazione a più fattori Microsoft Entra, vedere Configurare le impostazioni di autenticazione a più fattori Microsoft Entra.

Per altre informazioni su come configurare AD FS per fornire l'autenticazione a più fattori, vedere Configurare Azure MFA come provider di autenticazione con AD FS.

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 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

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
  • 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

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

Tutte le versioni di Windows Server supportate possono essere usate con Windows Hello for Business 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
🔲 Ibrido Chiave Tutte le versioni supportate
🔲 Ibrido Certificato Tutte le versioni supportate
🔲 Locale Chiave Tutte le versioni supportate
🔲 Locale Certificato Tutte le versioni supportate

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: