• Guide, Sicurezza, Sistemi Operativi
• 7 Febbraio 2021

Ogni volta che affrontiamo le tematiche di migrazione di Active Directory dobbiamo in qualche modo fare i conti con I livelli funzionali. Ne abbiamo anche fatto cenno in occasione della recente #POWERCON2020 durante la sessione Migrare Active Directory a Windows Server 2019.

In parole molto semplici il livello funzionale è un insieme di caratteristiche che Active Directory mette a disposizione degli amministratori, ma anche una forma di protezione che impedisce la promozione a Domain Controller di versioni obsolete di sistema operativo.

Active Directory è strutturata in domini e foreste; il primo dominio che viene installato quando si esegue la “promozione” del primo server a Domain Controller di fatto installa anche la prima Foresta che avrà il nome del dominio stesso.

Da quando, con Windows 2000, è nata Active Directory ogni versione ha caratteristiche proprie che sono identificate con i livelli funzionali.

Di versione in versione i vari livelli funzionali hanno introdotto nuove caratteristiche, ed evoluzioni, senza deprecarne di già presenti.

I livelli funzionali di Foresta e di Dominio non necessariamente devono essere allineati, anche per il fatto che ad una foresta possono appartenere più domini. In generale, quindi, possiamo considerare che il livello di funzionalità del dominio può essere di un valore maggiore rispetto al livello di funzionalità della foresta, ma non su un valore minore. Il livello funzionale della foresta definisce quindi il livello funzionale minimo di un dominio che può essere collegato alla foresta stessa.

Compatibilità tra livelli funzionali di AD e versioni di Sistema Operativo

Nella pratica quotidiana, ci si può trovare in scenari in cui il livello funzionale di una infrastruttura è rimasto ad una versione non allineata con il sistema operativo del domain controller; a questo scopo è bene prestare attenzione a questa tabella di compatibilità

Tabella 1 Compatibilità tra Versioni di sistema Operativo e Livelli Funzionali

Può apparire strano l’aver riportato sistemi operativi come 2000 o 2003, ma in realtà potrebbe esserci la situazione in cui un dominio/foresta è attivo a livello funzionale 2003 ma fisicamente installato su un server 2012 R2. In questo scenario, l’installazione di un nuovo Domain Controller di ultima versione richiederà di elevare il livello funzionale dell’infrastruttura.

Considerazioni relative alla Sicurezza

Come possiamo notare il fatto di avere definito un ben preciso livello funzionale impone che i Domain Controller appartenenti al dominio non possano essere di versione inferiore. Questa peculiarità fa sì che su infrastrutture molto grandi e distribuite non vengano inseriti come funzioni di DC sistemi operativi non aggiornati.

Vediamo ora quelle che sono le funzioni proprie dei vari livelli funzionali sia di dominio che di foresta, con una descrizione (breve) delle caratteristiche introdotte nei vari livelli funzionali di Active Directory

Livello Funzionale 2000

Dominio

• Disponibilità dei gruppi universali di Distribuzione e Sicurezza
• Possibilità di “annidamento” dei gruppi
• Possibilità di conversione tra gruppi di sicurezza e distribuzione
• Disponibilità del SID History

Foresta

• Disponibili le funzioni “Native” della prima versione di AD

Livello Funzionale 2000 (Mixed)

• Il livello funzionale Windows 2000 Mixed è stato concepito per supportare la transizione e la migrazione da ambienti NT 4 a domini Active Directory 2000
  

Livello Funzionale 2003

Dominio

• È possibile rinominare i Domain Controller tramite il tool Netdom.exe
• Aggiornamento e replica tra DC dell’attributo logonTime Stamp
• Al fine di una piena rispondenza alla RFC 2798 è disponibile la classe inetOrgPerson all’interno della directory AD, è anche possibile all’interno della stessa classe impostare l’attributo userPassword. Questa caratteristica può essere utile e quindi utilizzata appieno negli scenari di migrazione da altre directory verso AD
• Possibilità di ridefinire i contenitori di default di creazione dei nuovi utenti e computer, nella versione precedente questi venivano creati di default in cn=Computers, e cn=Users
• Authorization Manager (AM) utilizza Active Directory per archiviare le proprie informazioni. AM è il framework utilizzato per il controllo degli accessi in base al ruolo.
• Constrained Delegation
  • È un’estensione del Protocollo Kerberos che permette di richiedere un Kerberos Service Ticket senza autenticazione presso il KDC, È possibile specificare la delega in modo granulare per specifici servizi.
• Selective Authentication
  • La Selective authentication permette di specificare in modo puntuale quali gruppi p1ossono autenticarsi a risorse specifiche in un Trust di Foreste

Foresta

• Da questa versione di AD È stato introdotto il Trust tra Foreste
• Dal livello funzionale 2003 di AD è possibile rinominare il Dominio
  
• Linked-value replication (LVR)
  • LVR è una funzione di ottimizzazione dei dati replicati all’interno di AD, ad esempio anziché replicare completamente tutti i membri di un gruppo, qualora questo cambi, si trasferiscono solamente le variazioni. Questa implementazione previene anche la perdita di informazioni quando vengono contemporaneamente modificati gli stessi oggetti su più Domain Controller
    
• Da questa versione è introdotta la funzionalità di Read Only Domain Controller (RODC);
  • Il RODC può essere utile in realtà in cui è necessario portare una sorgente di autenticazione del dominio, all’esterno del perimetro di sicurezza del dominio stesso. Il Read Only Domain controller permette le autenticazioni e la disponibilità dei servizi di un DC senza consentire modifiche alla Directory. Il Domain controller in modalità Read-Only deve essere almeno di versione 2008 così come il server che ospita il ruolo di PDC Emulator, tuttavia il livello funzionale della Foresta può anche essere 2003
• Migliorato l’algoritmo del servizio di controllo Knowledge Consistency Checker (KCC), a cui è demandato il compito di replica dei metadati di AD, generando uno schema di replica inter ed intra Sito
• Il processo di intersite topology generator (ISTG) è stato migliorato permettendo la gestione di foreste articolate su un gran numero di Siti.
  • Il Domain Controller che detiene il “ruolo” di ISTG organizza due funzioni:
  • Seleziona automaticamente uno o più Bridgehead Server tra i Domain Controller
  • Esegue il processo di KCC per determinare la topologia di replica e le modalità di connessione che i bridghead server usano per le comunicazioni
• In questo livello funzionale è stata introdotta la possibilità di convertire l’oggetto inetOrgPerson nell’oggetto User e viceversa
• I nuovi tipi di gruppo creati supportano, da questa versione la role-based authorization
• È ora possibile disattivare e ridefinire attributi e classi nello schema di AD, diventa possibile il riutilizzo di questi attributi: ldapDisplayName, schemaIdGuid, OID, e mapiID.
• Il “motore” di replica dati DFS include, da questa versione il supporto alla access-based enumeration e presenta una scalabilità migliorata

Livello Funzionale 2003 (Interim)

È anche possibile in contesti particolarmente datati (probabilmente non è più una condizione ricorrente) che venga visualizzato il livello funzionale di Dominio e Foresta Windows 2003 (Interim). Questa è una condizione intermedia di stato, disponibile esclusivamente in 2003 Server, che è (era) utilizzata negli scenari di migrazione da NT Server. Questo livello funzionale permette ancora la coesistenza di BDC di versione NT4 ed è una situazione di transizione in scenari particolarmente complessi dove la migrazione a versioni successive del dominio NT richiedeva tempi lunghi per la presenza di un numero elevato di DC.

Le funzionalità di questa modalità sono limitate pur introducendo due caratteristiche migliorative.

• La replica ottimizzata dei gruppi di sicurezza e il supporto per più di 5000 membri per gruppo.
• Ottimizzazione dell’algoritmo del processo KCC.

Livello Funzionale 2008

Dominio

• Fine Graned Password Policy; possibilità di definire regole e criteri relativi alla password secondo l’appartenenza a Security Group differenti.
• Last Interactive Logon; Tramite una Group Policy apposita è possibile far comparire all’utente, all’atto del Login, una informazione puntuale sullo stato dell’ultimo login interattivo sia fallito che completato.
• Abilitazione del protocollo Kerberos all’uso dell’encryption AES 128 ed AES 256
• Supporto della replica del file system distribuito (DFS) per il volume di sistema (SYSVOL)

Foresta

• Nessuna nuova funzione rispetto alla versione 2003

Livello Funzionale 2008R2

Dominio

• Introduzione dei Managed Service Account e Virtual Account

Foresta

• Disponibilità del Cestino di Active Directory

Livello Funzionale 2012

Dominio

• Flexible Authentication Secure Tunneling (FAST), interessa le fasi di preautenticazione relative al protocollo Kerberos, richiede che il client sia almeno di versione 8
  
• Introduzione dei Claims come entità di autenticazione
  

Livello Funzionale 2012 R2

Dominio

• Introduzione del gruppo “Protected Users” gli utenti che fanno parte di questo gruppo, quando accedono a Sistemi di versione 2012R2/8.1 (o superiori) beneficiano di una protezione ulteriore:
  
  • Le credenziali non vengono salvate in cache localmente
    
  • Usare l’autenticazione NTLM
    
  • Usare algoritmi di cifratura obsoleti (RC4/ DES) nella preautenticazione Kerberos
    
  • Nel caso di abilitazione od utilizzo della Digest Authentication i dati di autenticazione non vengono salvati in Cache
    
  • Non è più possibile l’accesso Offline
    

Livello Funzionale 2016

Dominio

• I Domain controller supportano la RFC 8070 relativa alla Preautenticazione Kerberos (PKInit Freshness Extension) nel contesto di autenticazione tramite chiave pubblica (il client di accesso deve essere almeno di versione W10 1607)
  
• I Domain controller gestiscono ora la rotazione dell’hash della password per gli utenti configurati con l’accesso tramite Smart Card
  
• I Domain controller supportano ora la Policy “Allow NTLM network authentication when the user is restricted to selected devices.” Che permette la gestione granulare delle autenticazioni NTLM

Foresta

• Disponibilità della funzione Privileged Access Managment (PAM). Tramite Microsoft Identity Manager e PAM vengono irrobustiti gli accessi amministrativi

Livello Funzionale 2019

Dominio

• Non sono state introdotte nuove funzionalità rispetto alla versione precedente

Foresta

• Non sono state introdotte nuove funzionalità rispetto alla versione precedente

Nello schema sopra sono riportate le varie funzionalità che di volta in volta, a partire dalla versione 2000 fino all’ultima 2019 sono state aggiunte alla Directory, in questo contesto è importante notare come le funzionalità sono sempre state aggiunte mentre quelle presenti non sono mai state deprecate

Considerazioni in merito alle relazioni tra Active Directory ed LDAP

Che cosa è LDAP? (Lightweight Directory Access Protocol)

Ldap nasce come implementazione più leggera (Lightweight) del suo predecessore DAP, In modo generico usiamo il termine LDAP per indicare una directory di oggetti che utilizziamo per la gestione delle infrastrutture informatiche, in realtà LDAP è un protocollo di accesso ad una directory, ossia definisce tutte le specifiche per l’accesso, autenticazione e la gestione di una Directory di oggetti. La prima RFC che ha definito questo protocollo è la RFC 1487, del 1993, da quella data ad oggi il protocollo ha subito considerevoli implementazioni ed aggiornamenti.

La prima versione di Ldap è stata aggiornata alla versione2 (LdapV2) le cui specifiche sono definite nella RFC 1777, tuttavia questa versione è rimasta in bozza, successivamente con la RFC 3377 il protocollo è stato definito in modo più completo arrivando alla versione attuale anche conosciuta come LdapV3.

In questo contesto Active directory è dichiarata nominalmente conforme alle RFC 1777, e 3377 anche se con una nota di implementazione che riportiamo integralmente:

3.1.1.3.1 LDAP Conformance

• 08/24/2020
  

The purpose of this section is to document how the implementation of Active Directory DCs interprets the LDAP v3 RFCs, including differences from those RFCs. Except as noted in the following subsections, Active Directory is compliant to [RFC3377].

Active Directory DCs nominally implement support for LDAP v2 [RFC1777]. However, except as noted in the next paragraph, Active Directory processes LDAP v2 requests and generates responses as if LDAP v3 had been requested by the client.

When processing an LDAP v2 request, Active Directory exhibits the following behavioral differences from processing an LDAP v3 request:

• Instead of using the UTF-8 character encoding for LDAPString [RFC2251], the system’s configured code page is used. The code page is configured locally on the DC by the DC’s administrator.
  
• Referrals and continuation references are generated using the format for LDAP v2 referrals as specified in section 3.1.1.3.4.
  

All LDAP error codes returned by Active Directory are taken from the resultCode enumeration of the LDAPResult structure defined in [RFC2251] section 4.1.10.

Nel contesto di analisi dei livelli funzionali visti in precedenza, Active Directory ha seguito le proprie evoluzioni ed implementazioni mantenendo ed aggiornando la rispondenza agli standard relativi al protocollo LDAP, possiamo quindi dedurre che l’innalzamento dei vari livelli funzionali di AD non modifica il comportamento del protocollo LDAP stesso. Questa analisi può essere necessaria, qualora Active Directory venga utilizzata come provider di autenticazione a livello applicativo in un contesto in cui è necessario innalzare il livello funzionale dell’infrastruttura per adeguamenti ed evoluzioni di sicurezza.

Ogni Domain Controller è quindi utilizzabile come Ldap server, tuttavia è necessario considerare che se le interazioni con Ldap sono relative al singolo dominio, è possibile utilizzare un qualsiasi Domain Controller del dominio stesso, se invece il contesto dell’uso di Ldap è relativo alla foresta è necessario utilizzare un Domain Controller con la funzione di Global Catalog abilitata.

Il protocollo Ldap prevede per le comunicazioni le porte TCP 389 e 636, la prima è utilizzata per le comunicazioni non cifrate mentre la seconda permette connessioni protette con il protocollo SSL/TLS, nel caso dell’utilizzo di un Global Catalog le due porte sono rispettivamente 3268 e 3269

Riepilogo dei livelli funzionali disponibili

Nello schema di Active Directory è presente un attributo numerico definito a livello di dominio e di foresta il cui valore ne indica il livello funzionale, la tabella seguente presenta un riepilogo in relazione ad entrambe

Tabella 2 attributo msDS-Behavior-Version e relativi contesti

La gestione del livello funzionale del dominio e della foresta può essere eseguita tramite alcuni strumenti e comandi, alcuni più intuitivi, in quanto grafici, altri a linea di comando.

• Dsquery
  
• Powershell,
  
• Active Directory Administrative Center
  
• Active Directory Users And Computers
  
• Active Directory Domains and Trust
  

DSQUERY

È possibile rilevare i valori contenuti nell’attributo con il comando DSQUERY

Foresta

dsquery * “CN=Partitions,CN=Configuration,DC=ICTPOWER,DC=LOCAL” -scope base -attr msDS-Behavior-Version

Dominio

dsquery * “DC=ICTPOWER, DC=LOCAL” -scope base -attr msDS-Behavior-Version

Figura 1    rilevazione con DSQUERY del livello funzionale di foresta e dominio

PowerShell

La visualizzazione del livello funzionale di Active Directory tramite PowerShell Utilizza due Cmdlet Get-ADDomain e Get-ADForest, in sé i due comandi permettono di ottenere numerose informazioni, ma nel nostro caso utilizzeremo esclusivamente quelle relative al livello funzionale

Get-ADDomain | fl Name,DomainMode

Figura 2    rilevazione del livello funzionale di Dominio

Get-ADForest | fl Name,ForestMode

Figura 3 rilevazione del livello funzionale di Foresta

Active Directory Administrative Center

È lo strumento grafico più semplice e intuitivo, nel senso che in un unico punto permette la rilevazione e la gestione dei livelli funzionali di entrambe le componenti di Active Directory, è sufficiente selezionare il Dominio nel tab di sinistra e nell’area a destra relativa ai Task selezionare “Properties”

Figura 4 AD Administrative Center proprietà di dominio e foresta

Dove compare un riepilogo generale dell’infrastruttura come riportato qui sotto

Figura 5 riepilogo delle impostazioni dei livelli funzionali

Active Directory Users And Computers /Active Directory Domains and Trust

I due Snap-In di gestione sono utilizzati rispettivamente nel contesto del dominio e della foresta, è possibile rilevare il livello funzionale del dominio tramite ADUC selezionando il dominio e facendo click con il tasto destro del mouse, in questo modo attivando la scelta Raise Domain Functional Level è possibile identificare, ed eventualmente elevare, il livello funzionale del Dominio.

Figura 6 ADUC gestione del livello funzionale di dominio

Figura 7 ADUC gestione del livello funzionale di dominio

Per mezzo dello Snap-In Active Directory Domain and Trust è possibile gestire la visualizzazione e la modifica del livello funzionale di AD relativamente alla foresta, aprendo il Tool e posizionandosi direttamente sulla “radice” dello strumento con il tasto dx del mouse, analogamente a quanto fatto con ADUC accediamo alla funzione di Raise Forest Functional Level

Figura 8 AD Domain and Trust gestione del livello funzionale di Foresta

Figura 9 AD Domain and Trust gestione del livello funzionale di Foresta

Modifica dei livelli funzionali di Active Directory

Per mezzo dei tool visti sopra, è anche possibile elevare i livelli funzionali del dominio e della foresta alla versione voluta, compatibilmente con i vincoli di versione di sistemi operativi dei Domain Controller presenti nell’infrastruttura secondo la tabella 1.

PowerShell

• Set-ADForestMode (usato per la gestione a livello di foresta)
• Set-ADDomainMode (usato per la gestione a livello di dominio)

Sono i due Cmdlet che permettono come possiamo vedere qui di seguito la gestione del livello funzionale della Directory

Set-ADForestMode -Identity ictpower.local -ForestMode Windows2016Forest

Figura 10 elevazione del livello funzionale di foresta a 2016

Set-ADDomainMode -Identity ictpower.local -DomainMode Windows2016Domain

Figura 11 elevazione del livello funzionale di dominio a 2016

Active Directory Administrative Center

Anche con questo strumento, è possibile gestire i livelli funzionali di dominio e foresta

Figura 12 elevazione del livello funzionale di foresta

Figura 13 elevazione del livello funzionale di dominio

Active Directory Users And Computers /Active Directory Domains and Trust

Analogamente a quanto visto per la rilevazione del livello funzionale, come visto in precedenza, possiamo anche modificarne l’impostazione, l’accesso alla modifica è indicato nelle figure 6 e 8.

Figura 14 elevazione del livello funzionale di foresta

Figura 14 elevazione del livello funzionale di dominio

Verifica della modifica del livello funzionale tramite il Registro Eventi

L’effettivo innalzamento del livello funzionale, di dominio e foresta, può essere rilevato tramite il Registro Eventi nella sezione relativa ai Directory Services.

In particolare, l’evento ID 2040 è relativo alle modifiche del Livello Funzionale della foresta, mentre l’evento ID 2039 è relativo alle modifiche del Livello Funzionale del dominio. Dopo aver modificato le impostazioni è bene verificare anche dal registro eventi che non siamo presenti errori.

Figura 15 identificazione degli eventi 2039/2040

Per praticità ed eventualmente per una gestione automatizzata del controllo, è possibile utilizzare questo comando PowerShell per la rilevazione puntuale dei due eventi.

Get-EventLog -LogName ‘Directory Service’ | where {$_.eventID -eq 2039 -or $_.eventID -eq 2040} | Format-List

Figura 16 output del Cmd-Let PowerShell

Particolarità relativa alla regressione del Livello Funzionale

Finora abbiamo visto e descritto come gestire l’innalzamento dei vari livelli, ma non abbiamo precisato che, seppur con una qualche limitazione è possibile anche abbassare le funzionalità di AD.

Questa caratteristica è valida solamente dalla versione 2008 in poi, in pratica il passaggio da 2003-à2008 non è reversibile, lo diventano i livelli funzionali più alti, per cui avremo 2008ß–à2008R2ß–à2012ß–à2012R2ß–à2016 ma anche 2008ß–à2016 e le varie combinazioni.

Naturalmente deve essere rispettata la tabella 1 in termini di dipendenza dal sistema operativo, ed il ritorno a livelli funzionali più bassi può essere esclusivamente eseguito con PowerShell.

Relazione tra Schema di Active Directory e Livelli Funzionali

In altri articoli, ad esempio in quelli relativi alla migrazione, abbiamo anche fatto cenno alla versione dello schema di Active Directory, in qualche modo la versione dello schema di AD è “svincolata” dal livello funzionale della directory stessa. Ossia se una infrastruttura Active Directory è composta interamente da domain controller di versione 2016 ma il livello funzionale è 2008R2, vedremo come lo schema di Active Directory sarà comunque relativo alla versione più elevata di Domain Controller installata in foresta, mentre i livelli funzionali resteranno o potranno essere abbassati alla versione 2008R2.

Lo schema di Active Directory è la definizione formale di ogni classe di oggetti che può essere creata in una foresta, e di conseguenza di ogni attributo presente. Ad esempio la classe Utente ha una serie di attributi propri quali Nome, Cognome etc.

Lo schema viene “preparato” all’atto della promozione alla funzione di domain controller del server di versione di sistema operativo più elevata, nella tabella qui sotto riportate le varie versioni di schema di AD in relazione alla versione del sistema operativo.

Tabella 3 versioni dello schema di AD

Per determinare la versione dello schema corrente in una foresta è possibile utilizzare

• PowerShell
• Dsquery
• Registry

Powershell

Il Cmdlet per ottenere l’informazione relativa allo schema di AD è Get-ADObject

Get-ADObject “cn=schema,cn=configuration,dc=ICTPOWER,dc=LOCAL” -properties objectversion

Figura 17 rilevazione della versione dello schema di AD

Dsquery

Anche in questo contesto il comando già usato in precedenza per rilevare il Livello Funzionale di AD ci permette di ottenere l’informazione sullo schema

dsquery * cn=schema,cn=configuration,dc=ICTPOWER,dc=LOCAL -scope base -attr objectVersion”

Figura 18 rilevazione della versione dello schema di AD tramite Dsquery

Registry

Per mezzo del registro di sistema in: HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\<Schema Version> possiamo trovare l’informazione relativa allo schema version della Directory

Figura 19 rilevazione della versione dello schema di AD tramite registry

Considerazioni:

In questo articolo abbiamo riportato quelle che possono essere informazioni utili nel lavoro quotidiano e che possono aiutarci a manutenere ed organizzare al meglio una Directory, sempre di più questo strumento è il provider di autenticazione aziendale, ad esso è affidata anche la protezione delle credenziali che rappresentano sovente un tassello poco considerato in termini di protezione.

Riferimenti:

https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/active-directory-functional-levels
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc784826(v=ws.10)?redirectedfrom=MSDN
https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/view-set-ldap-policy-using-ntdsutil

Qui di seguito trovate invece alcune guide di migrazione che abbiamo realizzato:

https://www.ictpower.it/sistemi-operativi/migrare-active-directory-da-windows-server-2008-2008-r2-a-windows-server-2019.htm
https://www.ictpower.it/sistemi-operativi/upgrade-domain-controller-a-windows-server-2016-parte-1-di-4.htm
https://www.ictpower.it/sistemi-operativi/upgrade-domain-controller-a-windows-server-2016-parte-2-di-4.htm
https://www.ictpower.it/sistemi-operativi/upgrade-domain-controller-a-windows-server-2016-parte-3-di-4.htm
https://www.ictpower.it/sistemi-operativi/upgrade-domain-controller-a-windows-server-2016-parte-4-di-4.htm