Archivi categoria: Active Directory

Rinominare un dominio di Active Directory

Facebooktwittergoogle_plusredditlinkedin

È possibile rinominare un dominio Active Directory? La risposta è affermativa ma spesso sottovalutata. A seconda delle dimensioni del dominio da rinominare, questa azione si può rivelare un incubo anche per il sysadmin più esperto: nel caso di procedura errata il rischio di bloccare un utente o di dover rifare le operazioni di join di una macchina al dominio è elevatissimo.

Contestualmente esistono numerosissime applicazioni incompatibili con tali attività.

Nel caso in cui foste costretti ad intraprendere questa strada, Microsoft ha rilasciato una lunga checklist che, se compresa e verificata attentamente, facilita di molto l’attività in oggetto.

Punti critici

Prima di prendere in considerazione l’azione di cambio nome, è necessario sapere che:

  • Il livello funzionale della foresta deve essere almeno Windows Server 2003;
  • Exchange Server 2003 è l’unico che supporta questa procedura;
  • Dopo aver rinominato il dominio è verranno rinominati anche i nomi degli host joinati;
  • In caso di foresta con domini figli, a seguito del cambio di nome e quindi di posizione del domain controller padre, sarà necessario ricreare le relazioni di trust affinché possano parlarsi nuovamente;
  • Le zone DNS dovranno essere create manualmente per il nuovo dominio;
  • Ogni membro del dominio deve essere riavviato due volte a seguito dell’aggiornamento del domain controller;
  • Il suffisso DNS dei membri del dominio rinominato potrebbe non essere corretto per un certo periodo di tempo. Di solito questa configurazione DNS viene aggiornata automaticamente in caso di modifiche al dominio. Il periodo di tempo per il quale potrebbe non essere corretto è proporzionale alle dimensioni del dominio.

Applicazioni non compatibili

  • Microsoft Exchange 2000
  • Microsoft Exchange 2007
  • Microsoft Exchange 2010
  • Microsoft Internet Security and Acceleration (ISA) Server 2004
  • Microsoft Live Communications Server 2005
  • Microsoft Operations Manager 2005
  • Microsoft SharePoint Portal Server 2003
  • Microsoft Systems Management Server (SMS) 2003
  • Microsoft Office Communications Server 2007

Preparazione ed esecuzione

Come prima cosa, assicuriamoci che la feature Remote Server Administration Tools sia installata.

Figura 1: Server Manager – Roles and features

Dobbiamo rinominare il dominio da contoso.local a laboratorio.local.

Predisponiamo, nel DNS primario, la nuova zona per il dominio:

Figura 2: DNS Manager – Creazione nuova zona

Figura 3: DNS Manager – Wizard – Tipo di zona

Figura 4: DNS Manager – Wizard – Replication scope

Figura 5: DNS Manager – Wizard – Nome zona

Figura 6: DNS Manager – Wizard – Gestione aggiornamenti

Figura 7: DNS Manager – Wizard – Riepilogo

Rimuoviamo l’associazione DNS con il vecchio dominio

Figura 8: DNS Manager – Rimozione zona

Figura 9: DNS Manager – Rimozione zona

Successivamente, da una macchina a dominio utilizzando il domain admin, eseguiamo una shell elevata ed eseguiamo il comando

rendom /list

Figura 10: Command line – Download XML

Il risultato sarà la generazione di un file xml, nel path dove viene eseguito il comando, che dovremo modificare

Figura 11: Modifica delle configurazioni

Modifichiamo ii nomi DNS e NetBios con quelli desiderati, nel mio caso:

Figura 12: XML – Modifica delle configurazioni

Verifichiamo le informazioni del dominio con il comando

rendom /showforest

Figura 13: Command line – Verifica configurazioni

Effettuiamo l’upload con il comando

rendom /upload

Figura 14: Command line – Upload

Verifichiamo che il dominio sia pronto ad effettuare il processo di ridenominazione con il comando

rendom /prepare

Figura 15: Command line – Preparazione ridenominazione

Eseguiamo la procedura con il comando

rendom /execute

Figura 16: Command line – Esecuzione

A questo punto il domain controller viene riavviato in maniera automatica.

A seguito del riavvio verifichiamo che la procedura sia andata a buon fine

Figura 17: Server Manager – Verifica dominio

Diverse configurazioni relative al nuovo nome dovranno essere eseguite a mano:

Figura 18: System Properties – Hostname errato

Il Full computer name del DC deve essere cambiato a mano. Per effettuare la ridenominazione, eseguire il comando

netdom computername LabDC.contoso.local /add:LabDC.laboratorio.local

Figura 19: Command line – Modifica hostname

Seguito dal comando

netdom computername LabDC.contoso.local /makeprimary:LabDC.laboratorio.local

Figura 20: Command line – Modifica hostname

Riavviamo il server, successivamente verifichiamo che sia stato rinominato correttamente

Figura 21: System Properties – Verifica hostname

Apriamo la console delle GPO

Cliccando sul nuovo nome configurato notiamo che punta ancora al vecchio dominio

Figura 22: Group Policy Management – Errore

Per correggere questo problema utilizziamo il comando

gpfixup /olddns:contoso.local /newdns:laboratorio.local

Figura 23: Command line – Fix GPO

seguito da

gpfixup /oldnb:CONTOSO /newnb:LABORATORIO

Figura 24: Command line – Fix GPO

A questo punto è necessario riavviare almeno due
volte tutti i server joinati al vecchio dominio in modo che recepiscano i cambiamenti avvenuti con la ridenominazione. Riavviare due volte assicura che ogni computer recepisca il cambio di dominio e propaghi a tutte le applicazioni le modifiche necessarie.

Attenzione: Il riavvio deve essere effettuato dopo aver fatto login sulla macchina. In caso di Power off e successivo avvio la procedura non funzionerà.

Una volta assicurati che tutti i membri del dominio siano allineati, proseguiamo con i comandi

rendom /clean

Figura 25: Command line – Pulizia dei riferimenti al vecchio dominio

infine

rendom /end

Figura 26: Command line – Termine delle configurazioni

In questo modo verranno rimossi i riferimenti al vecchio dominio.

Verifichiamo che lato DNS siano stati creati i record correttamente

Figura 27: DNS Manager – Verifica zona

Exchange

In caso di ridenominazione di AD con versioni di Exchange non supportate, sarà necessario creare una nuova foresta, installare nuovamente Exchange ed effettuare una migrazione dei contenuti esistenti.

Maggiori informazioni possono essere recuperate qui.

Una possibile soluzione in caso di Exchange incompatibile è registrare un nuovo dominio e creare delle regole di redirect in modo che le email inviate al vecchio dominio vengano inoltrate automaticamente ai nuovi indirizzi. In questo modo si evitano impatti agli utenti i quali utilizzeranno esclusivamente il nuovo indirizzo di posta.

Conclusioni

Con la dovuta attenzione ed una corretta analisi è possibile rinominare un dominio AD. In alcune situazioni attività del genere sono preferibili al rifacimento dell’intera infrastruttura ma se affrontate nel modo sbagliato possono diventare un incubo.

Per fortuna Microsoft fornisce tutte le informazioni necessarie per affrontare questa attività in sicurezza.

Implementare Azure AD Domain Services

Facebooktwittergoogle_plusredditlinkedin

Gli Azure AD Domain Services permettono di poter aggiungere (joinare) macchine virtuali ad un dominio gestito senza la necessità di distribuire e manutenere i domain controller. Abilitando gli Azure AD Domain Services, verranno create in Azure due macchine virtuali che diventeranno i domain controller del dominio che vorrete creare. Queste due macchine saranno collegate ad una Azure Virtual Network (VNET) e sarà possibile aggiungere computer sia ospitati in macchine virtuali Azure sia ospitati on-premises, se la vostra rete virtuale è collegata in modalità Site-to-Site alla vostra infrastruttura aziendale. Per poter accedere alle applicazioni potrete utilizzare le vostre credenziali di Azure AD.

Sfruttando le funzionalità offerte, sarà possibile utilizzare LDAP, NTLM (NT LAN Manager) e l’autenticazione Kerberos, ampiamente usate nelle aziende, per eseguire la migrazione in Azure di applicazioni legacy compatibili con le directory.

Per abilitare le funzionalità di Azure AD Domain Services è necessario prima avere una directory di Azure AD (sincronizzata con una directory locale oppure solo cloud).

Una volta abilitata la funzionalità di Azure AD Domain Services sarà possibile eseguire i seguenti compiti amministrativi:

  • Aggiungere computer al dominio gestito.
  • Configurare le Group Policy per le unità organizzative (OU) “AADDC Computers” e “AADDC Users” nel dominio gestito.
  • Amministrare il DNS nel dominio gestito.
  • Creare e amministrare unità organizzative (OU) personalizzate nel dominio gestito.
  • Ottenere l’accesso amministrativo ai computer aggiunti al dominio gestito.

Privilegi amministrativi non disponibili in un dominio gestito

Il dominio viene gestito da Microsoft, incluse le attività quali applicazione di patch, monitoraggio ed esecuzione di backup. Il dominio è bloccato e non si hanno privilegi per eseguire alcune attività amministrative. Ecco alcuni esempi di attività che non è possibile eseguire:

  • Non vengono concessi privilegi di amministratore di dominio (Domain Admin) o amministratore dell’organizzazione (Enterprise Admin) per il dominio gestito.
  • Non è possibile estendere lo Schema del dominio gestito.
  • Non è possibile connettersi ai controller di dominio per il dominio gestito usando Desktop remoto.
  • Non è possibile aggiungere controller di dominio al dominio gestito.

Configurazione della directory di Azure

In questo articolo utilizzerò una directory di Azure che utilizza un dominio personalizzato chiamato “demolab.it”. Per aggiungere un dominio personalizzato alla vostra Azure Active Directory potete seguire le indicazioni contenute nell’articolo Aggiungere un nome di dominio personalizzato ad Azure Active Directory

Figura 1: Dominio personalizzato da utilizzare per gli Azure AD Domain Services

Poiché sto utilizzando un Directory esistente, ho anche alcuni gruppi ed alcuni utenti attivi. Agli utenti ho cambiato il logon name (username) in modo tale che utilizzino il dominio personalizzato “demolab.it”.

Figura 2: Utenti già esistenti in Azure AD

Abilitazione della funzionalità di Azure AD Domain Services

Dal portale di Azure scegliete di creare una nuova risorsa di tipo Azure AD Domain Services e scegliete quale sarà il DNS Domain Name che verrà utilizzato per creare il dominio gestito. Come già anticipato, io utilizzerò il dominio “demolab.it”. Indicate la sottoscrizione, il Resource Group e la Location dove creare le risorse.

Figura 3: Scelta del nome di dominio ce dovrà utilizzare Azure AD Domain Services

Nella schermata successiva scegliete a quale Virtual Network vorrete collegare i vostri Azure AD Domain Services ed il dominio gestito. Potete utilizzare una rete esistente oppure crearne una nuova. Nel mio caso ho deciso di creare una nuova rete virtuale.

Figura 4: Creazione di una nuova VNET da utilizzare con gli Azure AD Domain Services

Alla VNET verrà associato anche un Network Security Group, ottimizzato per proteggere gli Azure AD Domain Services.

Figura 5: Scelta della VNET e creazione di un Network Security Group associato

Nel passaggio successivo dovrete aggiungere gli utenti al gruppo AAD DC Administrators, uno speciale gruppo che avrà i privilegi nel dominio gestito che verrà creato. Questo gruppo verrà aggiunto al gruppo Administrators locale di tutte le macchine che verranno aggiunte al dominio gestito, come succede ai Domain Admins in Active Directory on-premises, e potranno connettersi in Desktop remoto alle macchine che verranno successivamente aggiunte (joinate) al dominio gestito.

NOTA: In un dominio gestito con Azure AD Domain Services non ci sono né Domain Admins né Enterprise Admins.

Figura 6: Aggiunta degli utenti al gruppo degli AAD DC Administrators

Controllate le configurazioni e cliccate su OK per completare la creazione degli Azure AD Domain Services. Ci vorranno circa 30 minuti per completare la creazione dei due domain controller.

Figura 7: Configurazione completata

Dopo circa 30 minuti sarà possibile verificare l’avvenuta creazione degli Azure AD Domain Services e sarà possibile aggiornare i DNS della vostra Virtual Network in modo tale che puntino agli indirizzi IP dei due domain controller creati per il dominio gestito. Cliccate su Configure e nel giro di pochi secondi la VNET verrà configurata automaticamente con i due IP da utilizzare per la risoluzione DNS.

Figura 8: Creazione completata e configurazione dei DNS

Infatti, se controllate le configurazioni della VNET vedrete che saranno stati modificati i server DNS.

Figura 9: Modifica dei server DNS della VNET compleltata

Nota: Durante il processo di provisioning, Azure AD Domain Services crea le applicazioni “Domain Controller Services” e “AzureActiveDirectoryDomainControllerServices” all’interno della directory dell’organizzazione. Queste applicazioni sono necessarie per far funzionare il dominio gestito ed è fondamentale che non vengono mai eliminate.

Figura 10: Applicazioni create per la gestione di Azure AD Domain Services

Connessione al dominio gestito

Per utilizzare il dominio gestito e per configurarlo è possibile creare una nuova VM e collegarla alla VNET utilizzata.

Figura 11: Creazione di una nuova VM per gestire Azure AD Domain Services

Terminata la creazione della VM potete collegarvi col le credenziali di amministratore locale che avete indicato al momento della creazione. Se controllate le configurazioni di rete della VM noterete che ha ottenuto i DNS corretti e quindi sarà capace di connettersi al dominio gestito “demolab.it”

Figura 12: La macchina virtuale ha ottenuto le configurazioni di rete corrette e può risolvere il nome del dominio gestito “demolab.it”

Per poter aggiungere la macchina al dominio gestito potete utilizzare le credenziali di un utente del gruppo AAD DC Administrators, come mostrato in figura:

Figura 13: aggiunta della VM al dominio gestito utilizzando le credenziali di un utente membro del gruppo AAD DC Administrators

Per autenticare gli utenti nel dominio gestito, Azure Active Directory Domain Services necessita dell’hash delle password in un formato idoneo per l’autenticazione NTLM e Kerberos. Azure AD non genera o archivia l’hash delle password nel formato necessario per l’autenticazione NTLM o Kerberos finché non si abilita Azure Active Directory Domain Services per il tenant. Per ovvi motivi di sicurezza, Azure AD non archivia nemmeno le credenziali di tipo password in un formato non crittografato. Azure AD quindi non può generare automaticamente questi hash delle password NTLM o Kerberos in base alle credenziali esistenti degli utenti.

Se avete configurato Azure AD per avere account utente solo cloud, tutti gli utenti che devono usare Azure Active Directory Domain Services devono cambiare le proprie password.

Se Azure Ad è sincronizzata con una directory on-premises (per mezzo di Azure AD Connect), è necessario abilitare la sincronizzazione degli hash NTLM e Kerberos per usare il dominio gestito. Fate riferimento all’articolo Abilitare la sincronizzazione password nel dominio gestito per gli account utente sincronizzati con l’istanza locale di AD per abilitare la sincronizzazione degli hash delle password.

Poiché l’utente che sto utilizzando per aggiungere la macchina virtuale al dominio gestito “demolab.it” era già presente in Azure AD (nel mio caso è solo Cloud) prima della creazione degli Azure AD Domain Services, non riesco a joinare la macchina al dominio gestito e ricevo un messaggio di errore (in realtà non chiarissimo).

Figura 14:Messaggio di errore dovuto alla mancanza di un hash delle password in formato corretto

Procedo quindi al cambiamento della password per l’utente admin@demolab.it, che avevo aggiunto al gruppo AAD DC Administrators. Il processo di modifica delle password determina la generazione in Azure AD degli hash delle password richiesti da Azure Active Directory Domain Services per l’autenticazione Kerberos e NTLM. È possibile impostare come scadute le password per tutti gli utenti del tenant che devono usare Azure Active Directory Domain Services oppure richiedere a tali utenti di cambiare le proprie password.

In questo caso mi sono collegato alla pagina https://mypass.microsoft.com e ho cambiato la password dell’utente admin@demolab.it, che stavo utilizzando per joinare la VM al dominio gestito.

Figura 15: Modifica della password dell’utente del gruppo AAD DC Administrators che stavo utilizzando per joinare la VM al dominio gestito

Dopo circa 20 minuti dalla modifica, la nuova password è utilizzabile in Azure Active Directory Domain Services. Ho riprovato ad aggiungere la VM al dominio gestito e questa volta non ho ricevuto nessun errore.

Figura 16: Dopo la modifica della password e l’attesa di qualche minuto, il join al dominio gestito avviene senza problemi

Gestione di Azure AD Domain Services

Adesso che avete aggiunto la VM al dominio gestito potete installare le console per la gestione. Io ho aggiunto la Group Policy Console, tutti gli AD DS Tools ed anche la console per la gestione del DNS.

Figura 17: Aggiunta degli strumento di amministrazione

Come si può vedere nelle schermate successive, è ora possibile amministrare il dominio gestito. Potete utilizzare la console Active Directory Users and Computers, L’Active Directory Administrative Center oppure AD PowerShell.

Figura 18: Console Active Directory Users and Computers e visualizzazione dei Domain Controllers del dominio gestito

Nella OU AADDC Users potrete vedere tutti gli utenti che avere creato in Azure AD (sia che siano solo cloud, sia che siano sincronizzati con Active Directory on-premises). Si può notare che i pulsanti di creazione dei nuovi utenti e dei nuovi gruppi non sono abilitati. La gestione degli utenti dovrà continuare ad essere effettuata da Azure AD.

Figura 19: Utenti del dominio gestito, gli stessi presenti in Azure AD

Per creare un nuovo utente o un nuovo gruppo dovete collegarvi al Portale di Azure e effettuare l’operazione dal nodo Azure Active Directory. Come già detto prima, siate pazienti perché ci vorranno circa 20 minuti per sincronizzare Azure AD con Azure AD Domain Services e per vedere il nuovo utente apparire nella console di Active Directory Users and Computers.

Figura 20: Utenti di Azure AD

Per amministrare il DNS potete invece collegarvi ad uno dei domain controller che sono stati creati nel dominio gestito (recuperate i nomi nella OU dei DC)), come mostrato in figura:

Figura 21: Console di gestione del DNS

È possibile utilizzare la console Group Policy Management nella macchina virtuale aggiunta al dominio per amministrare le Group Policy (GPO) nel dominio gestito, a patto che siate membri del gruppo AAD DC Administrators.

Sono presenti diverse GPO nel dominio gestito, tra cui la Default Domain Policy, AADDC Computers GPO e AADDC users GPO. È possibile personalizzare queste GPO o crearne delle altre. Io ho creato una nuova Organizational Unit (OU) e una nuova Group policy (GPO), come mostrato in figura:

Figura 22: Console di gestione delle GPO del dominio gestito

Conclusioni

Molto spesso in azienda si usano applicazioni che usano LDAP per l’accesso in lettura o scrittura alla directory aziendale oppure usano l’autenticazione integrata di Windows (autenticazione NTLM o Kerberos) per autenticare gli utenti finali. Per spostare le applicazioni locali nel cloud, è necessario risolvere le dipendenze da Active Directory. Spesso gli amministratori adottano una delle soluzioni seguenti:

  • Creano una connessione VPN da sito a sito tra Azure e l’infrastruttura on-premises.
  • Creano un domain controller aggiuntivo dell’Active Directory aziendale in una VM di Azure
  • Creano in Azure un dominio separato, utilizzando una o più VM promosse a domain controller

Tutti questi approcci tuttavia prevedono costi elevati e un carico di lavoro amministrativo significativo. Gli amministratori devono distribuire i controller di dominio tramite macchine virtuali in Azure. In più, devono gestire, proteggere, applicare patch, monitorare, eseguire il backup e risolvere i problemi relativi a tali macchine virtuali. L’utilizzo di connessioni VPN alla directory locale rende i carichi di lavoro distribuiti in Azure suscettibili a errori o interruzioni di rete temporanee.

Azure Active Directory Domain Services è pensata per offrire un’alternativa più semplice.

Veeam Backup & Replication: recuperare le GPO

Facebooktwittergoogle_plusredditlinkedin

Uno degli scenari più frequenti che mi capita dover affrontare, quando mi trovo dai clienti, è il recupero delle Group Policy Object che vengono eliminate. Microsoft mette a disposizione diverse armi da questo punto di vista, a cominciare dal Recycle Bin di Active Directory, presente da Windows Server 2008 R2, che permette di recuperare gli oggetti eliminati entro un certo periodo di tempo.

Figura 1 – Recycle Bin AD

Un altro modo per proteggersi, è creare dei backup direttamente dalla console delle GPO, che permette di ripristinare le policy con il valore aggiunto di fare un rollback in caso si sia modificata una policy in modo errato.

Figura 2 – Backup GPO

Esiste anche una terza via, che è quella di utilizzare Microsoft Advanced Group Policy Management, un prodotto presente all’interno della suite MDOP, che permette di effettuare backup avanzati, fare restore, comparazioni e molto altro ancora.

Veeam Restore for Active Directory

Per chi volesse la vita semplificata, è possibile utilizzare Veeam Backup & Replication per fare il recupero degli oggetti Active Directory. Grazie all’integrazione nativa, introdotta dalla versione 8, è possibile ripristinare non solo utenti e gruppi, ma anche GPO eliminate.

NB: il restore funziona solo se si attiva l’Application-Aware Support.

Figura 3 – Ripristino AD Objects

La procedura di recupero è identica a quella adottata per gli altri oggetti, perciò avremo la nostra timeline in cui effettuare il restore, con annesse note.

Figura 4 – Timeline

Figura 5 – Elenco Oggetti

La cosa interessante della soluzione, sta nel poter effettuare le seguenti operazioni:

  • Restore su un Domain Controller
  • Export
  • Compare

Proprio il compare è una di quelle funzioni che può aiutare gli IT admin a fare non solo un ripristino, ma volendo è possibile recuperare solo la parte modificata. Ad esempio, potremmo avere la necessità di ripristinare solo le security policy perché qualcuno ha cancellato i target users.

Figura 6 – Confronto GPO

Non è possibile verificare cosa sia cambiato, ma di sicuro questa funzionalità aiuta parecchio a recuperare gli oggetti eliminati o modificati.

Conclusioni

Veeam Backup & Replication, se utilizzato al meglio, è sicuramente un valido alleato nel ripristino di tutte le tipologie di oggetti della propria infrastruttura IT. Grazie all’integrazione nativa, diventa facile e veloce recuperare gli elementi e riposizionarli all’interno della loro locazione iniziale.

Configurare Active Directory Federation Services 2016 e Azure Multi-Factor Authentication

Facebooktwittergoogle_plusredditlinkedin

Tra le novità introdotte in Active Directory Federation Services (AD FS) in Windows Server 2016 c’è la possibilità di integrare l’autenticazione con Microsoft Azure Multi-Factor Authentication (MFA), in modo tale da inserire una One-Time Password (OTP) invece che la password di dominio.

Tra le problematiche più note, infatti, si riscontra quella dovuta al blocco dell’account in Active Directory dopo che qualcuno ha tentato di indovinare la password e l’ha sbagliata diverse volte.

Figura 1: Numero massimo di tentativi di accesso falliti prima che l’account venga bloccato

Figura 2: Account bloccato dopo 10 tentativi di accesso falliti

Come avrete modo di leggere nell’articolo Azure AD and ADFS best practices: Defending against password spray attacks, utilizzare ADFS 2016 ed Azure MFA con sistema principale di autenticazione permette di ottenere un sistema passwordless, basato esclusivamente su un OTP.

Ho già avuto modo di farvi vedere come Configurare Active Directory Federation Services in Windows Server 2016 e come Configurare AD FS 2016 ed Office 365 con Azure AD Connect nei miei precedenti articoli. Oggi vi voglio mostrare quanto sia facile integrare ADFS 2016 con Azure MFA.

Registrazione degli utenti in Azure MFA

AD FS non permette che avvenga la registrazione degli utenti in Azure MFA (proofup), ma gli utenti devono essersi già registrati e aver attivato l’MFA. Per farlo possono collegarsi a https://account.activedirectory.windowsazure.com/Proofup.aspx oppure in alternativa a https://aka.ms/mfasetup ed eseguire la procedura di registrazione, in cui possono inserire il numero di telefono a cui ricevere messaggi SMS, le chiamate oppure posso collegare l’App per il cellulare (Azure Authenticator)

Figura 3: Configurazione della Multi-factor authentication

Azure MFA come autenticazione principale

Se si utilizza Azure MFA come Primary Authentication in AD FS si può evitare di inserire la password durante il login ad Azure AD, ad Office365 oppure ad altre applicazioni SaaS ed utilizzare un codice temporaneo OTP. Se stiamo utilizzando un pc sconosciuto per autenticarci allora è il caso di prendere il massimo delle precauzioni (potrebbe esserci un keylogger sulla macchina oppure qualcuno potrebbe vedere la password che digitiamo).

Prerequisiti

Per poter connettere ADFS a Azure MFA dovete accertarvi di avere i seguenti prerequisiti:

  • Installazione on-premises di un’infrastruttura AD FS basa su Windows Server 2016
  • Federazione dell’infrastruttura con Azure AD
  • Aver installato il modulo PowerShell per Azure AD (Msoline)
  • Permessi di Global Administrator nella sottoscrizione di Azure AD
  • Credenziali di Enterprise Administrator per configurare la Farm ADFS per Azure MFA

Configurazioni dei server ADFS

Come prima operazione creeremo un certificato digitale da utilizzare per MFA. Il certificato dovrà essere creato su TUTTI i server AD FS della vostra Farm. Per creare un certificato relativo alla nostra Azure AD useremo la cmdlet di PowerShell

$certbase64=New-AdfsAzureMfaTenantCertificate -TenantIdnicolaferrini.onmicrosoft.com

Ovviamente sostituite il TenantID con quello della vostra directory di Azure AD

Figura 4: Creazione del certificato da utilizzare per Azure MFA

Il certificato verrà salvato nello store Local Computer

Figura 5: Certificato da utilizzare per Azure MFA creato

Connettetevi al vostro tenant di Azure AD con il comando Connect-MsolService e successivamente aggiungete le credenziali al Service Principal Name (SPN) del client di Azure Multi-Factor Auth utilizzando il comando PowerShell

New-MsolServicePrincipalCredential -AppPrincipalId 981f26a1-7f43-403b-a875-f8b09b8cd720 -Type asymmetric -Usage verify -Value $certBase64

981f26a1-7f43-403b-a875-f8b09b8cd720 è il guid dell’ Azure Multi-Factor Auth Client

Figura 6: Aggiunta delle credenziali al Service Principal Name (SPN) del client di Azure Multi-factor Auth

Configurazione della Farm AD FS

Dopo aver completato i passaggi precedenti in ogni server della Farm ADFS, è necessario impostare il servizio Azure MFA come fattore di autenticazione. Lanciate, una sola volta e su un server ADFS qualsiasi, il comando PowerShell

Set-AdfsAzureMfaTenant -TenantId nicolaferrini.onmicrosoft.com -ClientId981f26a1-7f43-403b-a875-f8b09b8cd720

Ovviamente sostituite il TenantID con quello della vostra directory di Azure AD.

Riavviate il Servizio di Active Directory Federation Service su tutte le macchina ADFS della vostra Farm.

Figura 7: Impostazione del servizio Azure MFA come fattore di autenticazione

Verificate che il nuovo metodo di autenticazione Azure MFA sia presente ed abilitato nella console AD FS Management, come mostrato in figura:

Figura 8: Azure MFA è adesso un Primary Authentcation method per la nostra Farm ADFS

Nel mio caso ho abilitato Azure MFA solo per l’accesso dall’esterno e non dall’interno dell’infrastruttura.

Verifica della presenza di Azure MFA come Primary Authentication method

Per verificare che tutto funzioni perfettamente è possibile collegarsi alla pagina di login del vostro server ADFS (nel mio caso è https://sts.nicolaferrini.cloud/adfs/ls/idpinitiatedsignon.htm)

Poiché ho federato la mia ADFS con Office 365, vado sul portale di autenticazione https://portal.office.com ed inserisco le credenziali di un utente del dominio e testo l’autenticazione dall’ESTERNO della mia infrastruttura.

Figura 9: Connessione al portale di Office 365

Figura 10: Il dominio di Azure AD è federato e vengo reindirizzato al mio Federation Server

Nella pagina di login è apparso un nuovo link che mi permette di utilizzare la Azure Multi-Factor Authentication.

Figura 11: Nella pagina di login del Federation Server è presente il link per utilizzare la Azure Multi-Factor Authentication

Cliccando però sul link ricevo un messaggio di errore. L’utente che sta tentando di connettersi non ha infatti effettuato il ProofUp, cioè la registrazione di Azure MFA. Per poter accedere deve prima collegarsi a https://account.activedirectory.windowsazure.com/Proofup.aspx oppure in alternativa a https://aka.ms/mfasetup ed eseguire la procedura di registrazione. Successivamente potrà riprovare a loggarsi con ADFS e Azure MFA.

Figura 12: Pagina di errore se l’accesso viene effettuato da un utente che non si è registrato in Azure MFA

Se invece tento di accedere con un utente che si è precedentemente registrato in Azure MFA, mi viene presentata una pagina dove posso inserire il codice di verifica che ho sulla mia App Azure Auhtenticator oppure posso utilizzare altre opzioni (SMS, telefonata, notifica sull’App)

Figura 13: Inserimento della One-Time Password (OTP) per l’autenticazione

Personalizzazione del portale di accesso di AD FS

AD FS non permette che avvenga la registrazione degli utenti in Azure MFA (proofup) e abbiamo visto che se un utente non si è precedentemente registrato non riuscirà ad utilizzare Azure MFA. È possibile però apportare delle modifiche alle pagine del portale di autenticazione ADFS e fare in modo di venire rediretti automaticamente alla pagina a https://account.activedirectory.windowsazure.com/Proofup.aspx oppure in alternativa a https://aka.ms/mfasetup per eseguire la procedura di registrazione.

Per poter personalizzare l’aspetto della pagina di Sign-In di ADFS è possibile seguire la procedura descritta nell’articolo Advanced Customization of AD FS Sign-in Pages

In questo esempio farò apparire un errore personalizzato, che avvisa gli utenti che devono prima registrarsi ad Azure MFA e successivamente provare a loggarsi al portale.

Come prima operazione clonerò il tema di default delle pagine di Sign-In (che chiamerò AzureMFA) e lo esporterò in modo tale da poterne modificare il file onload.js. La procedura deve essere effettuata da PowerShell su tutti i server ADFS della vostra Farm utilizzando i comandi:

#Creazione di un nuovo tema per il portale ADFS
New-AdfsWebTheme –Name AzureMFA –SourceName default

#Esportazione del tema per poter effettuare le modifiche
Export-AdfsWebTheme –Name AzureMFA –DirectoryPath c:\AzureMFAtheme

Figura 14: Creazione di un nuovo tema per la pagina di Sign-In di ADFS

Nella cartella C:\AzureMFATheme\script troverete il file onload.js, che dovrete modificare inserendo alla fine del file le seguenti righe:

// Se Azure MFA non è disponibile per l'utente si riceve un messaggio che fornisce la procedura corretta per la registrazione
if (document.getElementById('errorMessage').innerHTML.search("The selected authentication method is not available") ) { 
// Show message with redirect link
	errorMessage.innerHTML = 'E\' necessario prima registrarsi per la Multi-Factor Authentication. Collegarsi al portale <a href="https://aka.ms/mfasetup">https://aka.ms/mfasetup</a>, inserire per l\'autenticazione la propria password, registrarsi ad Azure MFA e riprovare successivamente a loggarsi a questa pagina utilizzando la Multi-Factor Authentication.';
}

Figura 15: Modifica del file onload.js con il messaggio di errore personalizzato

Terminata la modifica del file è necessario inserirlo nel tema che avete clonato (nel mio caso si chiama AzureMFA) eseguendo il comando PowerShell

#Aggiornamento del tema con il file onload.js personalizzato
Set-AdfsWebTheme -TargetName AzureMFA -AdditionalFileResource @{Uri=‘/adfs/portal/script/onload.js’;path=“c:\AzureMFAtheme\script\onload.js”}

Successivamente rendete il tema attivo, sostituendo quello di default, con il comando:

#Applicazione del tema personalizzato
Set-AdfsWebConfig -ActiveThemeName AzureMFA

Figura 16: Modifiche apportate al tema di ADFS

Adesso se un utente non ha effettuato il ProofUp, cioè non si è registrato ad Azure AD, invece che ricevere un messaggio di errore che gli indica la procedura corretta di registrazione ad Azure MFA.

Figura 17: Accesso al portale con le credenziali di un utente che non ha effettuato il ProofUp

Figura 18: Messaggio di errore che avvisa l’utente che non può usare la Azure MFA perché deve prima registrarsi (proofup)

Figura 19: L’utente si deve autenticare con la password per poter attivare Azure MFA

Figura 20: L’utente viene reindirizzato al portale di registrazione di Azure MFA

Conclusioni

Per rendere più sicura l’infrastruttura, per evitare che gli utenti vengano bloccati in Active Directory per troppi tentativi di indovinare la password e per stare più tranquilli quando si autenticano utilizzando AD FS da un computer che non è il loro, la soluzione di integrare AD FS 2016 con Azure MFA ed utilizzare un OTP per l’autenticazione è decisamente la migliore e vi permette di sfruttare al massimo le tecnologie disponibili per impedire attacchi di password spray o di password guessing.

Configurare AD FS 2016 ed Office 365 con Azure AD Connect

Facebooktwittergoogle_plusredditlinkedin

Azure AD Connect è un tool gratuito che integra le directory locali (dominio) con Azure Active Directory. Questo permette di sincronizzare utenti e password on-premises con il tenant di Office 365 e con tutte le applicazioni SaaS che usano Azure AD per l’autenticazione.

In alcuni casi però le aziende preferiscono non sincronizzare le password dei propri utenti con Azure AD. Per poter consentire l’accesso ai servizi cloud si può ricorrere all’autenticazione basata sugli Active Directory Federation Services. Grazie all’accesso federato, gli utenti possono accedere ai servizi basati su Azure AD con le proprie password locali e, se si collegano da un computer all’interno della rete aziendale (joinato al dominio), non devono immettere di nuovo le password per autenticarsi (Single Sign-On).

Per configurare un’infrastruttura basata su ADFS potete leggere il mio articolo Configurare Active Directory Federation Services in Windows Server 2016

Figura 1: Autenticazione ai servizi SaaS effettuata con Active Directory Federation Services

In questo articolo vi voglio mostrare come il tool Azure AD Connect vi permetta facilmente di configurare la federazione con Active Directory Federation Services (ADFS) locale e Azure AD. Usando l’opzione di federazione con ADFS, è possibile distribuire una nuova installazione di ADFS oppure specificare un’installazione esistente in una farm ADFS di Windows Server 2012 R2 o di Windows Server 2016.

Assicuratevi di aver verificato tutti i Prerequisiti di Azure AD Connect e procedete al download del tool Azure AD Connect. In questo momento è disponibile la versione 1.1.819.0 del 14/05/2018.

Lanciate il wizard di installazione e accettate la licenza, come mostrato in figura:

Figura 2: Lancio del wizard di installazione di Azure Ad Connect

La configurazione che vogliamo applicare richiede che venga effettuata una Installazione personalizzata di Azure AD Connect, pertanto cliccate sul tasto Customize

Figura 3: Scelta dell’installazione personalizzata di Azure Ad Connect

Figura 4: Installazione dei componenti richiesti

Terminata l’installazione dei componenti, scegliamo in quale modo gli utenti faranno il Sign-in. Ho già avuto modo di affrontare in un altro articolo i vantaggi della Azure AD Pass-through Authentication, mentre in questo articolo vi mostro come configurare la Federation con AD FS.

Figura 5: scelta della modalità di Sign-in per gli utenti

Figura 6: Connessione al tenant di Azure AD con le credenziali di Global Admin

Figura 7: Connessione all’Active Directory locale

Cliccate sul pulsante Add Directory ed inserite le credenziali di un utente che abbia permessi sufficienti per leggere le informazioni dal dominio locale. È anche possibile creare un nuovo utente.

Figura 8: Selezione di un utente di AD locale

Figura 9: Connessione all’AD locale effettuata

Assicuratevi di aver configurato correttamente i suffissi UPN per gli utenti del vostro AD locale. Trovate maggiori informazioni leggendo l’articolo How to prepare a non-routable domain for directory synchronization

Figura 10: LIsta dei dominio presenti on-premises e verifica dei domini personalizzati aggiunti online

Nella schermata successiva sarà possibile scegliere quali domini della vostra foresta volete sincronizzare e quali OU. Sarà possibile modificare i filtri anche in un secondo momento, come ho già avuto modo di spiegare nel mio articolo Configurare i filtri in Azure AD Connect

Figura 11: Filtro dei domini e delle OU da sincronizzare

Figura 12: Scelta dell’identificativo univoco con cui vengono rappresentati utenti, gruppi e dispositivi

Figura 13: Eventuale filtro in base al Distinguished Name di un gruppo di AD

Nella schermata relativa alle Optional features potete scegliere se abilitare la Password hash Synchronization o l’attribute filtering. Obiettivo di questo articolo è quello di usare i Federation Services per l’autenticazione ed evitare di sincronizzare le password con il Cloud e per questo motivo lasciate invariate tutte le scelte di default.

Figura 14: Scelta delle Optional features

A questo punto siete pronti per configurare Azure AD Connect con la vostra Farm ADFS. Inserite le credenziali di un amministratore del dominio in cui si torva la vostra Farm ADFS e cliccate su Next.

Figura 15: Inserimento credenziali dell’amministratore del dominio

È possibile creare una nuova AD FS Farm oppure utilizzare una Farm esistente. Nel mio caso ho già una Farm (che ho creato con gli steps descritti nel mio articolo Configurare Active Directory Federation Services in Windows Server 2016). Specifico quindi il server che ospita la Farm ADFS e proseguo con il wizard.

Figura 16: Scelta del server che ospita la Farm ADFS

Figura 17: Selezione del dominio online da federare con la directory on-premises

Figura 18: Conferma dell’installazione di Azure AD Connect

Figura 19: Configurazione completata

Terminata l’installazione di Azure AD Connect potete procedere alla verifica della funzionalità di connettività. Il vostro dominio personalizzato di Azure AD è stato convertito da Standard a Federato ed il Federation Server Gateway di Microsoft adesso punta per l’autenticazione al vostro Web Application Proxy (nel mio caso è sts.nicolaferrini.cloud). Assicuratevi di aver configurato correttamente la risoluzione dei nomi (sia internamente che esternamente alla vostra infrastruttura) e di aver aperto le porte del firewall.

Figura 20: Verifica della funzionalità di federation

Figura 21: Funzionalità verificata

Test di autenticazione – Accesso dall’ESTERNO dell’organizzazione

Adesso che avete configurato tutto correttamente vi basterà collegarvi ad una applicazione Saas che usa Azure AD per l’autenticazione. Ad esempio potete collegarvi ad Office365 tramite il portale https://portal.office.com. Verrete subito reindirizzati al Federation Gateway di Microsoft (https://login.microsoftonline.com) e potrete inserire le credenziali del vostro utente di dominio.

Figura 22: Connessione al portale Office365

Il Microsoft Federation Gateway si accorgerà che il dominio è federato e vi farà collegare direttamente al vostro Web Application Proxy. A quel punto potrete inserire la password del vostro account di dominio, che tramite il vostro Active Directory Federation Server verrà verificata col domain controller.

Figura 23: Reindirizzamento da parte del Microsoft Federation Gateway verso il Web Application Proxy aziendale

Figura 24: Pagina di autenticazione del Federation Server aziendale

Se le credenziali inserite sono corrette verrete reindirizzati alla pagina del Federation Gateway di Microsoft (https://login.microsoftonline.com)

Figura 25: Funzionalità “Mantieni l’accesso (KMSI)”. Questa funzionalità concede l’accesso agli utenti che tornano alle applicazioni senza richiedere di immettere nuovamente il nome utente e password

Figura 26: Accesso al portale di Office365 completato

Test di autenticazione – Accesso dall’INTERNO dell’organizzazione

Se vi collegate da una macchina in dominio e siete loggati con lo stesso utente con cui volete fare il Sign-In ad Azure AD, Active Directory Federation Services provvederà ad usare il token Kerberos che già possedete e ad utilizzare la Windows Integrated Authentication (WIA) per farvi accedere ad Azure AD (Single Sign-On). Però appena utilizzerete il browser vi accorgerete che vi apparirà lo stesso una finestra di autenticazione. Per evitare di reinserire le credenziali ed utilizzare il Single Sign-On sarà necessario considerare attendibile l’url del Federation Server ed inserirlo nella Local Intranet.

Figura 27: Richiesta delle credenziali di accesso anche da una macchina in dominio

Figura 28: Aggiunta nelle Internet Options dell’url del Federation Server nei Local Intranet Trusted Sites

Se non usate Internet Explorer ma usate Google Chrome non avrete problemi perché per impostazione predefinita Chrome usa lo stesso insieme di URL di siti attendibili di Internet Explorer.

È anche possibile utilizzare una Group Policy per poter automatizzare questa impostazione. Ci basterà creare una nuova GPO da collegare al dominio e in User Configuration\Policies\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page dobbiamo modificare la voce Site to Zone Assignment List

Figura 29: Aggiunta ai Trusted Sites dell’url del Federation Server tramite GPO centralizzata

Connessione tramite i browser Google Chrome, Mozilla Firefox e Microsoft Edge

Se volete effettuare la connessione da browser alternativi ad Internet Explorer sarà necessario, dopo aver inserito nella Local Intranet l’url del Federation Server, apportare alcune modifiche alla configurazione del server ADFS, come spiegato nell’articolo

Configurazione autenticazione intranet basata su form per i dispositivi che non supportano WIA

Infatti sarà necessario modificare la lista dei client che possono supportare la Windows Integrated Authentication (WIA). Per farlo vi basterà eseguire sul server ADFS, da un prompt di PowerShell eseguito con privilegi elevati, i seguenti comandi:

#Verifica dei client attualmente supportati
Get-ADFSProperties Select -ExpandProperty WIASupportedUserAgents

#Aggiunta dei browser Firefox, Chrome e Edge
Set-AdfsProperties –WIASupportedUserAgents @(“MSAuthHost/1.0/In-Domain”,“MSIE 6.0”,“MSIE 7.0”,“MSIE 8.0”,“MSIE 9.0”,“MSIE 10.0”,“Trident/7.0”, “MSIPC”,“Windows Rights Management Client”,“Mozilla/5.0”,“Edge/12”)

#Riavvio dei servizio Active Directory Federation Services
Restart-Service ADFSSRV

Figura 30: Modifica dei client che supportano la WIA in ADFS

Active Directory Federation Services 2016 e Azure Multi-Factor Authentication

Tra le novità introdotte in Active Directory Federation Services (AD FS) in Windows Server 2016 c’è la possibilità di integrare l’autenticazione con Microsoft Azure Multi-Factor Authentication (MFA), in modo tale da inserire una One-Time Password (OTP) invece che la password di dominio. Alla pagina Active Directory Federation Services 2016 e Azure Multi-Factor Authentication troverete tutti gli step necessari ad integrare le due funzionalità.

Conclusioni

Azure AD Connect vi permette di configurare facilmente la federazione con Active Directory Federation Services (ADFS) locale e Azure AD. In questo modo gli utenti potranno beneficiare del Single Sign-On (SSO) e le aziende non saranno costrette a dover sincronizzare le password degli utenti con Azure AD. Con pochi semplici passaggi l’autenticazione avviene in azienda e i nostri dati sono al sicuro, permettendo di rispettare i requisiti di privacy e di compliance.

Active Directory Federation Services in Windows Server 2016

Facebooktwittergoogle_plusredditlinkedin

Gli Active Directory Federation Services (ADFS) permettono di identificare, autenticare ed autorizzare gli utenti e di offrire il web single sign-on per applicazioni che non sono ospitate nei server del vostro dominio.

Supponete infatti di voler utilizzare un applicativo web creato da un’azienda esterna alla vostra organizzazione (Resource Partner) e di non voler comunicare a questa azienda username e password dei vostri utenti di dominio (Account Partner). ADFS vi permette di reindirizzare le autenticazioni per l’applicazione web verso il vostro Federation Server e di usare il vostro domain controller come database per le autenticazioni. Basta quindi installare due Federation Server ed aprire un’unica porta (il traffico tra i server è HTTPS) per poter avere la possibilità di loggarsi senza reinserire le credenziali e allo stesso tempo non doverle comunicare a nessuno.

Figura 1: Principio di funzionamento di ADFS

In questo articolo mi occuperò della configurazione di una nuova Farm ADFS in Windows Server 2016. Per conoscere tutte le novità della nuova versione di ADFS vi rimando alla lettura dell’articolo What’s new in Active Directory Federation Services per Windows Server 2016

Prima però di avventurarci nella configurazione vera e propria della nostra Farm ADFS vi consiglio di leggere l’articolo Checklist: Deploying a Federation Server Farm e l’articolo Best practices for securing Active Directory Federation Services

L’infrastruttura tipica di una Farm ADFS è quella presentata nella figura 2. All’interno della LAN abbiamo il domain controller e le macchine in dominio, tra cui i server ADFS, mentre nella DMZ abbiamo il Web Application Proxy, che rimarrà in workgroup e che si occuperà di proteggere le connessioni da Internet verso il server ADFS.

Figura 2: Infrastruttura di ADFS che verrà realizzata

Gestione dei certificati per il Namespace ADFS

Come prima operazione procuratevi un certificato digitale per il nome del vostro ADFS Namespace. Utilizzate le informazioni contenute alla pagina Requisiti del certificato per ADFS per conoscere le caratteristiche che deve avere il certificato da installare su tutti i server della vostra infrastruttura ADFS, compresi i Web Application Proxy.

NOTA: Tutti i server ADFS e i server Web Application Proxy necessitano di un certificato SSL per soddisfare le richieste HTTPS per il servizio federativo. Il certificato da installare deve essere esattamente
lo stesso su tutti i server dell’infrastruttura ADFS.

Nel mio caso utilizzerò il certificato con il nome sts.nicolaferrini.cloud. Dopo che avrete installato lo stesso certificato sia sulla macchina ADFS (in dominio) che sulla macchina Web Application Proxy (in workgroup) potete procedere con la configurazione del server ADFS

Requisiti per il dominio

ADFS 2016 richiede che il controller del dominio sia almeno Windows Server 2008 (il livello funzionale del dominio può invece essere ancora Windows Server 2003) e che tutte le macchine ADFS della Farm siano joinate allo stesso dominio. Per la creazione della Farm ADFS potete utilizzare uno standard service account oppure un Group Managed Service Account (gMSA). Per utilizzare un gMSA è necessario che i domain controller sia almeno Windows Server 2012 e uno dei vantaggi più evidenti del loro utilizzo è che la password dell’account viene aggiornata automaticamente.

Io preferisco utilizzare i Group Managed Service Account (gMSA),
e poiché sto usando un ambiente nuovo ed è la prima volta che ne creo uno devo prima creare la Key Distribution Services KDS Root Key, necessaria al domain controller per generare le password dei gMSA. Per poter creare la chiave è sufficiente eseguire, con privilegi elevati, in un domain controller il seguente comando PowerShell

Add-KdsRootKey –EffectiveImmediately

I domain controller aspetteranno fino a 10 ore dal momento della creazione della chiave prima di poter permettere la creazione di un Group Managed Service Account (gMSA), in modo tale da consentire a tutti i domain controller presenti nel dominio di poter replicare la chiave appena creata. In un ambiente di laboratorio potete accelerare questa operazione eseguendo con privilegi elevati in un domain controller il seguente comando PowerShell:

Add-KdsRootKey –EffectiveTime (Get-Date).AddHours(-10)

Figura 3: Creazione della Key Distribution Services KDS Root Key per la generazione delle password dei Group Managed Service Account (gMSA).

Requisiti per il database di ADFS

Per l’installazione di ADFS è possibile utilizzare sia il Windows Internal Database (WID) che Microsoft SQL Server (sono supportate le versioni SQL Server 2008 e successive). Per maggiori informazioni vi rimando alla lettura dell’articolo Requisiti del database di configurazione di una Farm ADFS. In questo articolo utilizzerò il Windows Internal Database.

Installazione del primo server della Farm ADFS

Aprite il Server Manager in Windows Server 2016 e lanciate il wizard per l’aggiunta di un nuovo ruolo. Io sto utilizzando la macchina ADFS1.cloud. lab, che ho joinato al dominio, e procedo all’installazione del ruolo di Active Directory Federation Services, come mostrato in figura:

Figura 4: Installazione del ruolo Active Directory Federation Services

Figura 5: Riepilogo delle funzionalità offerte dal ruolo ADFS

Figura 6: Installazione del ruolo ADFS completata

Cliccando sul collegamento Configure the federation service in this server potrete lanciare il wizard che vi permetterà di creare il primo server della vostra Farm ADFS. Verificate anche dal link AD FS prerequisites di aver completato tutti i prerequisiti d’installazione e procedete cliccando su Next.

Figura 7: Creazione del primo Federation Server nella Farm

Figura 8: Account di dominio da utilizzare per la configurazione del server ADFS

Nella schermata successiva scegliete dal menù a tendina il certificato da utilizzare (che dovrete aver precedentemente installato) ed il Federation Service Name, che vi servirà successivamente per configurare il Web Application Proxy. Indicate anche il nome da visualizzare nella pagina di autenticazione di ADFS.

Figura 9: Certificato, Federation Service Name e nome della Farm ADFS da creare

Nella schermata successiva specificate il Service Account che farà girare i servizi ADFS. Utilizzerò, come già detto, un Group Managed Service Account chiamato ADFSservice

Figura 10: Creazione del Group Managed Service Account

Figura 11: Utilizzo del Windows Internal Database (WID)

Figura 12: Schermata riassuntiva delle configurazioni scelte

Figura 13: Controllo dei prerequisiti

Figura 14: Configurazione della Farm ADFS completata

La creazione della Farm ADFS è completata, ma è necessario riavviare la macchina. Notate alcuni warning che mi sono apparsi nella schermata finale. I warning si riferiscono ad alcuni nomi che mancano nel certificato (certauth.sts.nicolaferrini.cloud e enterpriseregistration.nicolaferrini.cloud). La mancanza di questi nomi non permetterà di registrare i dispositivi tramite ADFS e non permetterà l’autenticazione tramite certificato (novità della versione 4.0 di ADFS). Ricordatevi quindi di utilizzare certificati di tipo SAN con tutti i nomi. Il certificato corretto da utilizzare nel mio dominio avrebbe dovuto includere questi nomi:

  • Subject Name (CN): sts.nicolaferrini.cloud
  • Subject Alternative Name (DNS): sts.nicolaferrini.cloud
  • Subject Alternative Name (DNS): certauth.sts.nicolaferrini.cloud
  • Subject Alternative Name (DNS): enterpriseregistration.nicolaferrini.cloud

Dopo il riavvio potete connettervi alla AD FS Management console e verificare le configurazioni del vostro server. Aprendo le proprietà potrete accertarvi di aver utilizzato i nomi corretti, come mostrato in figura:

Figura 15: ADFS Management console e Federation Service Properties

Creazione della zona DNS e record per il server ADFS

Per permettere la corretta risoluzione dei nomi del server ADFS ho creato nel domain controller una zona con il nome pubblico nicolaferrini.cloud e ho creato un record host per sts.nicolaferrini.cloud, in modo tale che le macchine interne sappiano come contattare il server ADFS. Il dominio interno ed il dominio esterno infatti differiscono ed è necessario configurare correttamente la risoluzione dei nomi.

Figura 16: Creazione della zona e del record DNS per il server ADFS

Verifica della funzionalità ed accesso alla pagina di Sign-In

ADFS in Windows Server 2016 disabilita di default la pagina idpinitiatedsignon, utile per testare se l’installazione è avvenuta correttamente. È possibile riabilitarla lanciando sul server ADFS il comando Powershell, eseguito con privilegi elevati

Set-AdfsProperties -EnableIdPInitiatedSignonPage $true

Figura 17: Abilitazione della pagina idpinitiatedsignon

Collegatevi quindi all’indirizzo https://<FQDN DEL SERVER ADFS>/adfs/ls/idpinitiatedsignon.htm per verificare che tutto funzioni. Nel mio caso ho digitato l’indirizzo https://sts.nicolaferrini.cloud/adfs/ls/idpinitiatedsignon.htm e ho potuto verificare di avere accesso alla pagina di Sign-In

Figura 18: Verifica dell’accesso alla pagina di Sign-In

È anche possibile verificare che sia attivo l’url relativo ai Federation Service Metadata collegandosi a https://<FQDN DEL SERVER ADFS>/federationmetadata/2007-06/federationmetadata.xml. Nel mio caso ho utilizzato l’indirizzo https://sts.nicolaferrini.cloud/federationmetadata/2007-06/federationmetadata.xml

Figura 19: Verifica dell’accesso ai Federation Service Metadata

Aggiunta dei altri server ADFS alla Farm esistente

In caso il server ADFS non funzionasse i vostri utenti non potrebbero loggarsi. È quindi opportuno aggiungere un ulteriore server alla Farm ADFS che avete appena realizzato. La procedura è ben descritta nell’articolo Add a Federation Server to a Federation Server Farm. Dopo aver aggiunto il secondo server alla Farm sarà necessario anche utilizzare un bilanciatore di carico a monte dei due server per assicurarne l’alta disponibilità. Ulteriori informazioni sono disponibili alla pagina Load Balancer Requirements for ADFS 2016

Installazione del Web Application Proxy

Il Web Application Proxy (WAP), da installare in DMZ e da lasciare in Workgroup, è necessario per proteggere i server ADFS ed evitare di esporli direttamente ad Internet. Il WAP si comporta da Reverse Proxy e permette l’accesso sicuro alle applicazioni on-premises dall’esterno dell’infrastruttura aziendale. Maggiori dettagli sono disponibili nell’articolo Web Application Proxy in Windows Server 2016

Prerequisiti per la configurazione del proxy

  • Installare esattamente lo stesso certificato che avete installato sui server ADFS
  • Assicurarsi che il WAP possa risolvere il nome interno del vostro server ADFS o del VIP del vostro Load Balancer
  • Creare un record DNS pubblico per il WAP, in modo tale che possa essere contattato dall’esterno
  • Aprire le porte del firewall (la porta 443 per l’HTTPS deve essere aperta dall’esterno verso il WAP e dal WAP verso ADFS)

Installazione del Web Application Proxy

L’installazione del Web Application Proxy è molto semplice. Dal Server Manager lanciate il wizard per aggiungere un nuovo ruolo e scegliete il ruolo Remote Access, come mostrato in figura:

Figura 20: Aggiunta del ruolo Remote Access, necessario per l’installazione del Web Application Proxy

Figura 21: Descrizione delle funzionalità offerta dal ruolo Remote Access

Scegliete di installare il role service Web Application Proxy e aggiungete tutte le funzionalità richieste dal ruolo

Figura 22: Installazione del role service Web Application Proxy

Figura 23: Installazione del ruolo completata

Fate clic sul link Open the Web Application Proxy Wizard per lanciare la configurazione del WAP

Figura 24Web Application Proxy Configuration Wizard

Indicate quale sarà il server ADFS a cui dovrà puntare il WAP quando riceverà le richieste di autenticazione ed autorizzazione. Nel mio caso il server è sts.nicolaferrini.cloud

Figura 25: Configurazione del Federation Server da contattare

Figura 26: Scelta del certificato digitale

Figura 27: Comandi PowerShell che verranno eseguiti per la configurazione del WAP

Terminata la configurazione potrete aprire la Remote Access Management console e verificare che tutti i servizi siano perfettamente funzionanti, come mostrato in figura:

Figura 28: Remote Access Management console

Accesso dall’esterno dell’organizzazione

Per verificare che tutto funzioni perfettamente potete collegarvi da una macchina ESTERNA alla vostra infrastruttura e collegarvi al WAP. Modificate il DNS pubblico in modo tale che punti all’IP pubblico del WAP, controllate le configurazioni dei firewall e connettetevi al vostro server (nel mio caso sts.nicolaferrini.cloud) tentando di raggiungere la pagina idpinitiatedsignon, esattamente come avete fatto prima. Se avete configurato tutto correttamente vi collegherete al WAP che inoltrerà la richiesta al server ADFS (o al bilanciatore).

Figura 29: Connessione al server ADFS avvenuta dall’esterno dell’organizzazione, tramite WAP

Accesso dall’interno dell’organizzazione

Se provate a collegarvi da una macchina in dominio, usando qualsiasi browser, alla pagina di autenticazione https://sts.nicolaferrini.cloud/adfs/ls/idpinitiatedsignon.htm vi apparirà un messaggio che vi richiederà di inserire le credenziali. Per poter garantire l’accesso automatico dell’utente è prima necessario impostare nella Local Intranet l’url del Federation Server. Questa impostazione consente al browser di inviare automaticamente le credenziali dell’utente connesso sotto forma di un ticket Kerberos per AD FS.

Figura 30: Richiesta di credenziali anche dalla macchina in dominio

Figura 31: Aggiunta nelle Internet Options dell’url del Federation Server nei Local Intranet Trusted Sites

Se non usate Internet Explorer ma usate Google Chrome non avrete problemi perché per impostazione predefinita Chrome usa lo stesso insieme di URL di siti attendibili di Internet Explorer.

È anche possibile utilizzare una Group Policy per poter automatizzare questa impostazione. Ci basterà creare una nuova GPO da collegare al dominio e in User Configuration\Policies\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page dobbiamo modificare la voce Site to Zone Assignment List

Figura 32: Aggiunta ai Trusted Sites dell’url del Federation Server tramite GPO centralizzata

Connessione tramite i browser Google Chrome, Mozilla Firefox e Microsoft Edge

Se volete effettuare la connessione da browser alternativi ad Internet Explorer sarà necessario, dopo aver inserito nella Local Intranet l’url del Federation Server, apportare alcune modifiche alla configurazione del server ADFS, come spiegato nell’articolo Configurazione autenticazione intranet basata su form per i dispositivi che non supportano WIA

Infatti sarà necessario modificare la lista dei client che possono supportare la Windows Integrated Authentication (WIA). Per farlo vi basterà eseguire sul server ADFS, da un prompt di PowerShell eseguito con privilegi elevati, i seguenti comandi:

#Verifica dei client attualmente supportati
Get-ADFSProperties Select -ExpandProperty WIASupportedUserAgents

#Aggiunta dei browser Firefox, Chrome e Edge
Set-AdfsProperties –WIASupportedUserAgents @(“MSAuthHost/1.0/In-Domain”,“MSIE 6.0”,“MSIE 7.0”,“MSIE 8.0”,“MSIE 9.0”,“MSIE 10.0”,“Trident/7.0”, “MSIPC”,“Windows Rights Management Client”,“Mozilla/5.0”,“Edge/12”)

#Riavvio dei servizio Active Directory Federation Services
Restart-Service ADFSSRV

Figura 33: Modifica dei client che supportano la WIA in ADFS

Configurazione di Active Direcotry Federation Service con Office 365

Per configurare AD FS 2016 con Office 365 è possibile utilizzare il tool Azure AD Connect, che si occuperà di automatizzare la procedura. Alla pagina Configurare AD FS 2016 ed Office 365 con Azure AD Connect trovate tutti i passaggi necessari per eseguire l’integrazione di AD FS 2016 con Azure AD e Office 365.

Active Directory Federation Services 2016 e Azure Multi-Factor Authentication

Tra le novità introdotte in Active Directory Federation Services (AD FS) in Windows Server 2016 c’è la possibilità di integrare l’autenticazione con Microsoft Azure Multi-Factor Authentication (MFA), in modo tale da inserire una One-Time Password (OTP) invece che la password di dominio. Alla pagina Active Directory Federation Services 2016 e Azure Multi-Factor Authentication troverete tutti gli step necessari ad integrare le due funzionalità.

Conclusioni

I vantaggi offerti dai Federation Services sono notevoli, perché permettono il Single Sign-On ed evitano che le password dei nostri utenti vengano memorizzate al di fuori della nostra organizzazione. Sia per motivi burocratici, che di privacy, sarebbe impossibile rivolgersi a fornitori di servizi esterni, che dovrebbero archiviare e gestire (e quindi mantenere aggiornate) le nostre credenziali. Con ADFS l’autenticazione avviene in azienda e i nostri dati sono al sicuro!

Active Directory Password Policies: facciamo un po’ di chiarezza

Facebooktwittergoogle_plusredditlinkedin

Sempre più spesso mi capita, quando sono in azienda o durante i corsi, di riscontrare perplessità o inesattezze sulla corretta applicazione delle password policies da parte degli amministratori di dominio. Per questo motivo oggi voglio scrivere un articolo che faccia chiarezza sulla corretta applicazione delle policy e sull’esatto ordine con cui questa avviene.

Quante password policies posso applicare ad un singolo dominio?

Rispondere a questa domanda è semplice: una ed una sola!

  • Solo le policy applicate a livello di DOMINIO vengono considerate valide e verranno distribuite agli utenti. Le policy applicate a livello di OU (Organizational Unit), inclusa la OU dei Domain Controllers, vengono ignorate.
  • Se a livello di dominio ci sono più policy (ad esempio la Default Domain Policy ed una policy creata da voi) verranno considerati tutti i settaggi delle due policy (viene cioè fatto un merge), ma in caso di conflitto avrà la precedenza il settaggio della policy con la precedenza più alta (cioè la policy che ha un numero inferiore al quello della Default Domain Policy – Link Order più basso).
  • La password policy viene gestita dal domain controller che ha il ruolo FSMO di PDC Emulator.

Quindi, ci può essere solo una password policy per ogni account database e un dominio di Active Directory è considerato un singolo account database, come succede con i computer standalone.

Figura 1: in caso di più policy, vince quella con il LInk Order più basso

Quando viene applicata la password policy?

La password policy è sempre applicata alla macchina e non all’utente. Quindi quando avviene un aggiornamento della policy, questa viene applicata in background ogni 90 minuti di default (Background Refresh of Group Policy), all’avvio del computer oppure utilizzando il comando GPupdate.

Quando gli utenti vengono impattati?

Se cambio la password policy e stabilisco che la lunghezza minima della password sia 8 invece che 6 caratteri, gli utenti non si accorgono della modifica fino a quando la password non scade o gli viene chiesto di cambiarla (perché un amministratore l’ha resettata).

Quindi la modifica non è così “impattante” come si penserebbe e non costringerebbe tutti gli utenti del dominio a cambiare la password lo stesso giorno, per essere compliant con la nuova lunghezza minima imposta.

Quando vengono distribuite le modifiche apportate ad una password policy?

Nel momento in cui modificate la password policy, i seguenti settaggi vengono distribuiti immediatamente:

  • Minimum password length
  • Password must meet complexity requirements
  • Reversible encryption

Mentre gli altri settaggi vengono distribuiti solo dopo un logon, logoff, reboot oppure un GPO refresh

  • Minimum password age
  • Maximum password age
  • Lockout duration
  • Lockout threshold
  • Observation window

Attenzione sempre a distinguere tra distribuzione della policy e applicazione dei nuovi settaggi, che avvengono in momenti distinti a seconda del settaggio stesso, come ho già sottolineato.

Cos’è la Fine-Grained Password Policy?

A partire da Windows Server 2008 (e solo se il livello funzionale del dominio è innalzato a Windows Server 2008) è possibile applicare una password policy direttamente agli utenti o ai gruppi di sicurezza globale (global security groups) di Active Directory. Questa funzionalità, chiamata Fine-Grained Password Policy, permette di definire configurazioni differenti per le password e le account lockout policy per differenti tipi di utenti all’interno del dominio.

Supponiate infatti che la password policy per gli amministratori di dominio o per gli utenti privilegiati richieda un numero minino di caratteri superiore a quelli di un utente limitato. Con la Fine-Grained Password Policy (FGPP) potete applicare la policy direttamente al gruppo di utenti interessato.

Non potete comunque applicare la policy alla singola Organizational Unit (OU). Potreste però creare uno Shadow Group, cioè un gruppo a cui vengono aggiunti tutti gli utenti di una determinata OU con uno script PowerShell automatico ed applicare la FGPP allo Shadow Group. Online trovate decine di esempi di script su come creare uno Shadow Group ed aggiungerci in maniera automatica gli utenti presenti nella OU.

Per creare una FGPP vi rimando alla lettura dell’articolo Step-by-Step: Enabling and Using Fine-Grained Password Policies in AD

Figura 2: Configurazione di una Fine-Grained Password Policy per il gruppo Domain Admins

All’atto pratico, la Fine-Grained Password Policy non modifica nessuna Group Policy, ma modifica un attributo dell’utente chiamato msDS-ResultantPSO. È importante applicare alla FGPP una precedenza, perché nel caso l’utente appartenga a gruppi diversi e a questi gruppi siano state applicate diverse FGPP, la precedenza diventa determinante perché vincerà la FGPP con il valore di precedenza più basso.

Figura 3: Verifica della corretta applicazione della FGPP ad un utente del gruppo a cui è stata applicata la policy

Conclusioni

Spero con questo articolo di aver dipanato alcuni dubbi in merito all’applicazione delle password policy, soprattutto per quanto riguarda le tempistiche di applicazione dopo che avete modificato alcuni parametri, e di avervi indicato il giusto modo per procedere ad una corretta configurazione delle stesse.

Buon lavoro!

Nic