La magia di Windows Autopilot
Se conoscete Windows Autopilot sapete quanto ci sia di “magico” in questo servizio Microsoft, che si è evoluto affermandosi come il vero metodo moderno per il deploy di Windows 10.
L’obiettivo che Microsoft si è preposta con Windows Autopilot è quella di rendere la vita facile sia all’utente finale, permettendogli di essere operativo con facilità e con una minima interazione (avete presente l’esperienza di quando si accende per la prima volta un nuovo iPhone?), sia al reparto IT riducendo i tempi che quest’ultimo utilizza nel configurare, mettere in sicurezza, gestire e dismettere i vostri laptop.
Per chi non conosce Windows Autopilot possiamo riassumere il processo in queste tre semplici fasi:
- l’IT Admin crea un profilo di deploy per Windows 10
- il produttore OEM da cui sono stati acquistati i device registra questi ultimi nel tenant Microsoft 365 e spedisce direttamente all’utente finale
- l’utente finale accende il device, inserisce le credenziali Microsoft 365 ed Autopilot fa tutto il resto
Con la crescita esponenziale delle persone che lavorano in modalità smartworking è cresciuta in egual maniera l’esigenza di potere effettuare il deploy dei laptop/desktop senza l’ausilio della rete aziendale o del supporto del personale IT, Windows Autopilot è uno strumento estremamente potente per rispondere a questa esigenza.
Tuttavia sono ancora moltissime le organizzazioni che utilizzano Active Directory on premise e che vogliono configurare i propri devices in modalità Hybrid Azure AD Joined in modo da sfruttare entrambe le potenzialità fornite da Active Directory Domain Service on premise ed Azure Active Directory nel cloud.
Autopilot Hybrid Join Over VPN
Per rispondere a questa esigenza Windows Autopilot ora supporta l’Hybrid Azure AD joining dei nuovi devices Windows 10 tramite VPN (anche di terze parti), questo processo non solo effettua la join del device ad Active Directory on premise ma lo registra in Azure Active Directory. Questa funzionalità era disponibile a partire da Windows 10 version 1809, ma con una importante restrizione: i devices dovevano essere connessi alla rete aziendale, i client Windows 10 dovevano poter “pingare” un domain controller locale come parte del processo di deployment di Hybrid Azure AD Join.
Ora questa restrizione è stata rimossa tramite il supporto alla connettività VPN e sfruttando l’installazione dei clients VPN (Win 32 apps) tramite Intune durante il processo di enrollment del device e rimuovendo la necessità del ping verso il domain controller.
Grazie a questa nuova feature i computer possono essere spediti direttamente all’utente finale, il quale dovrà semplicemente collegare il device ad internet, ed Autopilot si occuperà di tutto il processo di Hybrid Azure AD Join.
Proviamolo nel nostro Lab in Azure
Abbiamo voluto provare questa funzionalità di Windows Autopilot, che ci permette di spedire ai nostri colleghi i nuovi device Windows 10 che abbiamo appena acquistato, i quali dovranno poter fare la join ad Active Directory on premise tramite internet sfruttando Autopilot ed Intune.
Prerequisiti per poter realizzare il nostro esercizio di lab in Azure sono:
- Azure subscription
- Licenza Intune
- Un device Windows 10, VM oppure fisico, con i seguenti prerequisiti:
- Windows 10 1903 + December 10 Cumulative update (KB4530684, OS build 18362.535) or higher
- Windows 10 1909 + December 10 Cumulative update (KB4530684, OS build 18363.535) or higher
- Windows 10 2004 or later
Per facilità ho riportato di seguito la configurazione del networking effettuata durante il setup e gli step necessari per completare il nostro laboratorio:
- In questo articolo trovate:
- Step 1: Creazione Virtual Network
- Step 2: Creazione Virtual Network Gateway
- Step 3: Creazione Virtual Machines – (Domain Controller e Member Server)
- Step 4: Configurazione Domain Controller (Certification Authority e Azure AD Connect)
- Step 5: Configurazione DNS in Azure
- Step 6: Configurazione Member Server (NDES e connettori)
- Nella seconda parte dell’articolo saranno presenti:
- Step 7: Configurazione Azure VPN
- Step 8: Validazione VPN
- Step 9: Configurazione Intune
Step 1: Creazione Virtual Network
Procediamo con la creazione dell’infrastruttura di networking al cui interno metteremo le VM necessarie, iniziamo creando una Virtual Network.
- Sign-in a https://portal.azure.com/
- Click su Create a resource e cerchiamo Virtual Network.
- Selezioniamo la nostra Azure Subscription
- Creiamo un nuovo Resource Group per questo lab che chiameremo AUTOPILOT.
- Specifichiamo un Name per la Virtual Network.
- Scegliamo Europe come Region dove vogliamo che le nostre risorse risiedano.
- Infine click Review + Create (lasciando i valori di default per IP Address, Security e Tags).
- Click Create.
Queste saranno le configurazioni della nostra virtual network:
Step 2: Creazione Virtual Network Gateway
In questo step creiamo il Virtual Network Gateway che agirà da software VPN.
- Sign-in to https://portal.azure.com/
- Click su Create a resource e cerchiamo Virtual Network Gateway per crearne uno
- Selezioniamo la nostra Azure Subscription
- Specifichiamo un Name per il Virtual Network Gateway, noi abbiamo scelto AUTOPILOT-vpn.
- Selezioniamo la stessa Region che abbiamo scelto prima in fase di creazione della Virtual Network
- Gateway type = VPN
- VPN type = Route-based
- SKU = VpnGw1 (default)
- Generation = Generation1
- Indichiamo nella finestra Virtual Network il nome della Virtual Network creata allo step 1.
- Lasciamo la Gateway subnet di default
- Public IP address = Create new
- Specifichiamo un Public IP address name, in questo caso abbiamo scelto AUTOPILOT-vpn-ip
- Enable active-active = Disabled.
- Configure BGB = Disabled.
- Click Review + Create
- Click Create
ATTENZIONE: La creazione del Virtual Network Gateway dura alcune decine di minuti, non procedete oltre finchè l’attività non risulta completata
Step 3: Creazione Virtual Machines – Domain Controller e Member Server
Ora che abbiamo creato l’infrastruttura di networking possiamo procedere con la preparazione dell’infrastruttura on premise, la quale sarà composta da una VM Domain Controller e da una VM server di dominio, entrambi ospitati nella nostra sottoscrizione Azure.
- Sign-in a https://portal.azure.com/
- Click Create a resource e cerchiamo Virtual Machine sotto Computer
- Selezioniamo la nostra Azure Subscription.
- Selezioniamo il Resource Group creato allo step 1, nel nostro caso AUTOPILOT.
- Abbiamo scelto il Name delle VM, AUTOPILOT-DC1 e AUTOPILOT-NDES
- Region è auto popolato in base alla regione scelta allo Step 1.
- Availability option = No infrastructure redundancy required.
- In Image selezionamo la versione del sistema operativo, noi abbiamo utilizzato Windows Server 2019 Datacenter
- Azure spot instance = No
- Come Size abbiamo lasciato il default suggerito da Azure.
- Inserire Username e password.
- Inbound ports = RDP.
- Licensing = default.
- Click Review + Create.
- Click Create per completare il processo di creazione.
Il wizard di creazione sceglie in automatico gli indirizzi networking del Resource Group che abbiamo selezionato, nel nostro lab gli indirizzi IP che sono stati assegnati sono i seguenti:
AUTOPILOT-DC1 (Domain Controller) 10.1.0.4
AUTOPILOT-NDES (Member Server) 10.1.0.5
Quando entrambe le VM sono state create possiamo procedere con gli step successivi ovvero la configurazione delle virtual machine.
Step 4: Configurazione Domain Controller (Certification Authority e AADC)
Procediamo ora con la configurazione dalla prima virtual machine che abbiamo creato, la quale avrà il ruolo di primo (ed unico) Domain Controller del nostro nuovo dominio Active Directory AUTOPILOT.LOCAL.
- Installiamo quindi il ruolo Active Directory Domain Services con DNS server
Questa Virtual Machine non avrà solamente il ruolo di Domain Controller ma vi installeremo anche la Certification Authority ed Azure AD Connect.
- Installiamo il ruolo Active Directory Certificate Services (CA: Certification Authority) e selezioniamo nel setup Enterprise CA poiché la modalità Standalone non è supportata da NDES.
- Procediamo con il setup di Azure AD Connect per sincronizzare l’AD on premise con Azure AD e configuriamo Hybrid Azure AD Join, il quale abiliterà i nostri device nella foresta AD a registrarsi anche in Azure AD tramite un oggetto SCP (service connection point) creato nella nostro Active Directory.
Step 5: Configurazione DNS in Azure
Ora che abbiamo creato il nostro dominio Active Directory è necessario configurare il networking in Azure per utlizzare il server DNS del dominio AD.
Nell’oggetto Virtual Network AUTOPILOT-vnet creato in precedenza:
- Selezioniamo DNS Servers dal menu di sinistra.
- Scegliamo modalità Custom.
- Inseriamo l’indirizzo IP privato della prima virtual machine (nel nostro caso 10.1.0.4).
- Click Save.
- Eseguiamo Reboot su tutte le VM connesse a questa rete.
Step 6: Configurazione Member Server (NDES e connettori)
Sulla seconda VM installiamo il ruolo NDES e tutti i connettori necessari alla nostra soluzione, la ragione principale per cui è stata creata questa seconda virtual machine è quella per cui NDES e Certification Authority non possono convivere sullo stesso server.
- NDES (Network Device Enrollment Service) permette a software o apparati di rete eseguiti senza credenziali di dominio di potere ottenere certificati basati su SCEP (Simple Certificate Enrollment Protocol). NDES esegue le seguenti funzionalità:
- Genera e fornisce password one-time di enrollment
- Sottopone le richieste di enrollment alla CA
- Recupera i certificati emessi dalla CA e li gira agli apparati di rete
Effettuiamo ora il setup di NDES sulla virtual machine creata:
- Join della VM al dominio AUTOPILOT.LOCAL creato allo step 4.
- Creazione e configurazione del service account NDES.
- Installare il ruolo NDES. Per ulteriori informazioni è possibile fare riferimento a questa guida.
- Azure AD Application Proxy Connector ci permette di pubblicare il nostro server NDES e di generare un indirizzo FQDN esterno:
- Andiamo sul portale Azure e selezioniamo Enterprise Applications
- Click su New application
- Selezioniamo On-premise applications
- Eseguiamo il download del connettore Application Proxy che copieremo sulla nostra VM
- Se la VM dove installiamo il connettore è un server Windows 2019 è necessario disabilitare il supporto al protocollo HTTP2 tramite la seguenti chiave di registro:
Set-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp\' -Name EnableDefaultHTTP2 -Value 0
Inoltre deve essere abilitato TLS 1.2 prima di installare il connettore:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
Infine è necessario verificare che Internet Explorer Enhanced Security Configuration sia disabilitato per non incorrere in errori di visualizzazione della pagina di registrazione del connettore.
- Reboot della VM
- Eseguire il file di installazione del connettore durante il quale verrà richiesto di effettuare la login
- Creiamo l’app Intune NDES alle Enterprise Application sul portale Azure, per ulteriori informazioni fate riferimento alla seguente guida.
Ora la nostra applicazione è registrata nelle Enterprise Applications…
ed il connettore Azure AD Application Proxy risulta attivo.
Richiesta certificato web per NDES
Ora si rende necessario fare la richiesta di un certificato web per NDES, poiché tutte le richieste di certificato al server NDES arriveranno tramite internet creiamo un certificate template di tipo Web Server ed assegniamo ad esso autenticazione di tipo client\server.
La procedura è quella raccolta in questa guida.
Intune Certificate Connector
Arrivati a questo punto abbiamo è arrivato il momento di connettere il nostro servizio NDES on premise con Microsoft Intune nel cloud, per far questo l’interfaccia tra il nostro server NDES e Intune è appunto Microsoft Intune Connector.
Per approfondire la configurazione dell’infrastruttura per supportare SCEP con Intune è possibile leggere il seguente articolo.
- Effettuare download del connettore per SCEP e salvarlo sulla vm NDES.
- Eseguiamo il file pocanzi salvato e procediamo con l’installazione del connettore:
- Selezionamo il certificato NDES emesso precedentemente
- Selezionamo il certificato NDES emesso precedentemente
- Dopo che il wizard è completo, ma prima di chiuderlo, mettiamo il flag su Launch Intune Connector. Se inavvertitamente chiudete il wizard senza aver lanciati la Certificate Connector GUI, potete riaprirlo eseguendo il seguente comando:
<install_Path>\NDESConnectorUI\NDESConnectorUI.exe
- Fate sign-in con un account Global Administrator o Intune Administrator, quando il login sarà completato Intune potrà finalmente comunicare con il nostro server NDES.
- Restart del server NDES.
Intune Connector for Active Directory
- Intune Connector for Active Directory è l’ultimo connettore che occorre installare sulla virtual machine, esso si occuperà di creare i computer “autopilot-enrolled” all’interno del dominio Active Directory on premise.
Il computer che ospita il connettore deve avere i permessi per potere creare computer objects all’interno del dominio, quindi come step iniziale eseguiamo la preparazione dei requisiti su Active Directory on premise.
Soddisfatti i prerequisiti procediamo con l’installazione del connettore per potere effettuare la join al dominio Active Directory on premise.
- Collegarsi a Microsoft Endpoint Manager (Intune)
- Selezioniamo Devices > Windows > Windows enrollment > Intune Connector for Active Directory > Add
- Eseguiamo le istruzioni per effettuare il download del connettore
- Eseguiamo il file di setup ODJConnectorBootstrapper.exe sulla VM
- Anche in questo caso ci verrà chiesto di fare sign-in con un utente Global Administrator o Intune Administrator
- Andiamo in Intune per confermare che il connettore sia attivo
La prima parte dell’articolo si conclude qui; tra pochi giorni sarà online la seconda parte, conclusiva dell’articolo. Stay tuned 😉