• Cloud, Guide, Microsoft 365, Sicurezza, Sistemi Operativi
• 30 Marzo 2023

Microsoft sempre di più, soprattutto nell’ultimo periodo, stà spingendo sulla dismissione del metodo di autenticazione “Active Directory Federated Services” più comunemente chiamato ADFS, per l’accesso al vostro tenant Microsoft 365. Agli albori il metodo ADFS era l’unico modo per permettere la sincronizzazione dei vostri utenti verso il mondo Cloud e poter sfruttare quindi anche il Single Sign On per l’accesso agli applicativi e servizi cloud della casa di Redmond.

Di seguito potete trovare, per completezza di informazioni, lo schema di funzionamento dell’autenticazione ADFS

Figura 1: Architettura ADFS

Per eventuali approfondimenti sull’architettura e l’implementazione ADFS vi lascio il link all’articolo di Nicola Ferrini Configurare Active Directory Federation Services 2016 ed Office 365 con Azure AD Connect – ICT Power

Avendo descritto prima l’architettura ADFS, ora potete notare, l’immagine che vi fornisce una visualizzazione della metodologia PHS:

Figura 2: Architettura PHS

Quali sono le principali differenze tra i due metodi di autenticazione ?

Sicuramente vi state chiedendo quali sono le differenze tra i due metodi di autenticazione e riepilogo di seguito pro e contro di entrambe le soluzioni.

Password Hash Synchronization

Vantaggi

• Stesse password per autenticarvi on-premise e in cloud
  
• Facile gestione per piccole, medie e grandi imprese
  
• Utilizzo Single Sign-On per autenticazione verso numerosi servizi
  
• Metodo di autenticazione indicato da Microsoft come consigliato
  
• Facile implementazione con poco effort
  

Svantaggi

• Alcune aziende per policy interne “rifiutano” la sincronizzazione della propria Directory con il cloud

Active Directory Federated Services

Vantaggi

• Se un utente è dimissionario o lascia l’azienda è immediatamente escluso dall’accesso a risorse aziendale
  
• Supporta integrazioni con scenari che non sono attuabili con la sola Password Hash Synchronization (PHS)
  

Svantaggi

• Molti step necessari per la configurazione
• Alto effort di manutenzione
• Richiesta di Hardware o Virtual Machine
• Richiesta di step aggiuntivi per la configurazione del Single Sign-On
• Critical Point of Failure: se il server ADFS risulta down gli utenti non riescono a collegarsi ai vari servizi

In questo articolo vedrete come poter migrare la vostra infrastruttura ADFS, in Pass Hash Synchronization, sfruttando Azure AD Connect e senza fornire disservizio ai vostri utenti finali.

Esistono dei prerequisiti ?

Si esistono alcuni prerequisiti, che potete verificare direttamente dall’interfaccia di configurazione del software Azure AD Connect

Figura 3: Verifica configurazione AD Connect

Figura 4: Verifica configurazione AD Connect

Questa verifica è fondamentale, in quanto potete accertarvi che l’attributo di password hash sync è già in modalità Enabled e non dovete eseguire nessun altra verifica in merito. Se invece l’attributo risultasse in stato Disabled dovrete, come primo step, configurare i dovuti permessi dell’account che avete utilizzato per il servizio AD Connect, chiamato più comunemente ADConnectorAccount.

Vediamo quindi come configurare questi permessi dopo esserci collegati alla macchina che ospita Azure AD Connect:

Aprite Powershell con diritti Amministrativi ed eseguite il seguente comando Import-Module “C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1”; questo vi permetterà di importare i moduli PowerShell obbligatori per eseguire il successivo step.

Figura 5: Assegnazione Permessi Account

Successivamente, sempre attraverso la stessa sessione di PowerShell, dovete eseguire il comando Set-ADSyncPasswordHashSyncPermissions -ADConnectorAccountName “nome account usato” -ADConnectorAccountDomain dominiodiactivedirectory

Figura 6: Permessi Account AD Connect

Figura 7: Permessi AD Connect

A questo punto siete pronti per eseguire gli step necessari per la modifica del metodo di autenticazione.

Scenario

Nello scenario di demo che ho utilizzato c’è una macchina con sistema operativo Windows Server 2022 con installato il ruolo di “Active Directory Federation Services” ed una macchina con sistema operativo Windows Server 2022 che si comporta da WAP (Web Application Proxy) con installato il ruolo di “Remote Access – Web Application Proxy”. Specifico inoltro che il software “Azure AD Connect” è installato sulla macchina SRV2022.

Figura 8: Caratteristiche Macchina Proxy

Figura 9: Caratteristiche Macchina ADFS

In questo caso, non è stata configurata l’alta affidabilità con 4 macchine (2 ADFS e 2 WAP), ma la procedura di cambio del metodo di autenticazione che vedremo sarà il medesimo.

Servono delle licenze specifiche per configurare il metodo di autenticazione Password Hash Synchronization ?

No, non avete necessità di acquistare licenze aggiuntive per la configurazione di PHS, in quanto il software Azure AD Connect (che potete scaricare dalla pagina Microsoft Download Microsoft Azure Active Directory Connect from Official Microsoft Download Center) è rilasciato in modo gratuito per permettervi di sincronizzare i vostri utenti e sfruttare quindi un’unica identità per accedere sia a livello di Active Directory locale, sia per la parte cloud di Microsoft 365.

Esperienza Utente con Autenticazione ADFS

Per dimostrarvi l’esperienza della login ai servizi cloud di Microsoft 365, vi mostrerò gli step di login verso il portale Microsoft

Figura 10: Login con autenticazione ADFS

Cliccando su “Next” vedrete il caricamento della pagina di login con il reindirizzamento al servizio ADFS

Figura 11: Login con autenticazione ADFS

Dopo pochi secondi, verrete reindirizzati alla pagina di Login (nel mio caso la pagina è personalizzata con immagine di sfondo)

Figura 12: Pagina Personalizzata di login ADFS

Inserendo la password dell’utente accederete al portale

Figura 13: Login con Autenticazione ADFS

Figura 14: Portale Microsoft 365

Migrazione Autenticazione ADFS in Password Hash Synchronization

Ora siete pronti a procedere con l’attività di cambio del metodo di autenticazione. Come anticipato, svolgerete l’attività sfruttando solo ed esclusivamente Azure AD Connect, quindi l’attività vi risulterà molto semplice.

Recatevi all’interno del server su cui avete installato Azure AD Connect, nel mio caso SRV2022, doppio click sull’icona “Azure AD Connect”

Figura 15: Azure Ad Connect

Vi apparirà la schermata per la configurazione del servizio. Fate click su “Configure” per iniziare il processo di configurazione.

Figura 16: Azure AD Connect

Ora dovrete eseguire il click su “Change user sign-in” e successivamente su “Next”

Figura 17: Azure AD Connect

Vi apparirà la schermata dove dovrete inserire username e password di un account Global Admin del vostro tenant Microsoft 365 e successivamente cliccare su “Next”

Figura 18: Azure AD Connect

Una volta che avrete eseguito il click su “Next” il sistema verificherà il corretto inserimento delle credenziali e dell’utente oltre ai permessi dello stesso

Figura 19: Azure AD Connect

NB: Nel caso in cui troviate l’errore riportato nella schermata sottostante, vuol dire che l’inserimento di Username o Password non è corretto

Figura 20: Errore Autenticazione Global Administrator

Nel seguente passaggio dovrete selezionare sia “Password Hash Synchronization” che “Warning:….” e successivamente click su Next.

La parte evidenziata in giallo “Enable single sign-on” è opzionale e non obbligatoria, ma fortemente consigliata; se decidete di selezionarla vi sono delle operazioni preliminari da fare per questo motivo vi rimando alla documentazione ufficiale Microsoft Azure AD Connect: Seamless single sign-on – Microsoft Entra | Microsoft Learn

Figura 21: Azure AD Connect

Ora vi troverete di fronte alla schermata dove verrà eseguito un check dei componenti

Figura 22: Controllo dei componenti installati

Figura 23: Azure AD Connect è pronto per configurare la Password Hash Synchronization

Figura 24: Azure AD Connect

Figura 25: Azure AD Connect

E se aveste abilitato la funzionalità di SSO ?

È molto utile, soprattutto per i vostri utenti, avere un accesso in modalità SSO verso gli applicativi Microsoft, soprattutto per quanto riguarda l’accesso via web. Di seguito vi mostrerò gli step aggiuntivi nel caso l’opzione di SSO con servizio PHS risulti attiva.

Figura 26: Configurazione SSO

Una volta che spuntate l’opzione di “Enable single sign-on” e click su “Next” verranno richieste delle credenziali di domain administrator del vostro dominio locale

Figura 27: Configurazione SSO

Una volta inserito il vostro amministratore di dominio locale, potete proseguire con la configurazione.

Figura 28: Configurazione SSO

Figura 29:Configurazione SSO

Figura 30: Configurazione SSO

Figura 31: Configurazione SSO

A questo punto la vostra configurazione SSO, per quanto riguarda AD Connect è completata

Figura 32: Configurazione SSO

Ora che la configurazione lato Azure AD Connect è terminata, dovrete procedere a creare delle Group Policy all’interno del vostro dominio, per configurare il “Seamless SSO“. Per approfondimenti potete consultare la documentazione ufficiale Microsoft Quickstart: Azure Active Directory Seamless single sign-on – Microsoft Entra | Microsoft Learn

Quando si abilita Single Sign-On in Azure AD Connect, viene creato un account computer denominato AZUREADSSOACC nell’Active Directory locale e la chiave di decrittografia di Kerberos è condivisa con Azure AD. Inoltre, vengono creati due Service Principal Name (SPN) Kerberos per indicare gli URL del cloud usati durante l’autenticazione tra il client e Azure AD. Verificate che l’account computer sia stato creato utilizzando la console Active Directory Users and Computer.

Figura 33: Oggetto Computer SSO

Se voleste approfondire l’utilità dell’oggetto computer sopra descritto, vi lascio a completezza di informazioni il link ufficiale Azure Active Directory Seamless Single Sign-On: Technical deep dive

Configurazione Group Policy per SSO

Aprite “Group Policy Management Editor” e selezionate/create una policy che venga applicata a tutti i vostri utenti sincronizzati. Per comodità useremo la “Default Domain Policy” e modificheremo nel percorso User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page il paramentro Site to Zone Assignment List.

Figura 34: Configurazione Group Policy

Figura 35: Creazione Group Policy

Facendo clic sul pulsante Show potremo inserire l’URL richiesto https://autologon.microsoftazuread-sso.com e come value “1”, come mostrato nella figura sotto:

Figura 36: Creazione Group Policy

Ora sempre nella medesima policy dovrete recarvi nel seguente percorso User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Intranet Zone. Selezionate la voce Allow updates to status bar via script e impostate il valore su Enable.

Figura 37: Creazione Group Policy

Figura 38: Creazione Group Policy

Arrivati a questo punto, vi manca solo l’ultima configurazione della “Default Domain Policy“, posizionatevi in questo percorso User Configuration > Preferences > Windows Settings > Registry > New > Registry item

Figura 39: Configurazione Group Policy

Inserite i seguenti valori:

• Key Path: Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\microsoftazuread-sso.com\autologon
• Value name: https
• Value type: REG_DWORD
• Value data: 00000001

Figura 40: Configurazione Group Policy

Per compatibilità riferite a browser web vi rimango al link Microsoft Quickstart: Azure Active Directory Seamless single sign-on – Microsoft Entra | Microsoft Learn

Ho modo di eseguire un test una volta configurate le Group Policy ?

Certamente, ho modo di eseguire un test, ma dovete rispettare alcuni importanti punti:

• L’utente esegue la login da un dispositivo aziendale (quindi collegato a dominio)
• Il computer dell’utente deve poter contattare il domain controller (anche in VPN)
• Il computer deve aver necessariamente recepito la Group Policy Creata

Verificati tutti i prerequisiti, potete eseguire il test con due differenti scenari:

• Utente inserisce UserName, ma non la password per accedere a https://myapps.microsoft.com/
• Utente NON inserisce username e password per accedere a https://myapps.microsoft.com/contoso.com (sostituire contoso.com con il vostro dominio)

Ora la procedura è terminata e avrete a disposizione il metodo di autenticazione PHS, e potreste, volendo dismettere la farm ADFS. Inoltre per verificare che l’attività sia andata a buon fine potete accedere al portale di Azure Active Directory, nella sezione AD Connect (per comodità riporto il link diretto AAD Connect – Microsoft Azure) e verificare che “Federation” sia impostata a “Disabled”

Figura 41: Portale Azure

Per completezza di informazioni vi riporto la stessa schermata precedente all’attività

Figura 42: Portale Azure prima dell’attività

Conclusioni

Con il metodo di autenticazione PHS, abilitando l’esperienza del Single Sign-on, avrete dato ai vostri utenti un’esperienza molto simile ad ADFS, quindi senza andare a stravolgere la loro attività quotidiana, ma allo stesso tempo avrete ridotto notevolmente il tempo impiegato per eseguire manutenzione alla farm ADFS, in quanto non dovete più eseguire aggiornamenti dei sistemi operativi delle macchine della farm. Inoltre ,per ultimo, ma non per importanza darete più ridondanza all’autenticazione in quanto se per qualsiasi motivo il server su cui avete installato Azure AD Connect risultasse essere in Down, tutti gli Hash delle password risulteranno sincronizzati con Azure AD e gli utenti riuscirebbero comunque ad avere fruibili i servizi Cloud, cosa che non sarebbe potuta attuarsi se i server ADFS fossero stati non raggiungibili.