Implementare Active Directory Tier Model
Active Directory Tier MODEL nasce dieci anni fa con il modello ESAE – Enhanced Security Admin Environment – e si focalizza sulla protezione degli amministratori AD on-premises. Grazie all’avvento del cloud oggi fa parte di strategia decisamente più “allargata” chiamata Enterprise Access Model siccome siamo passati da un’infrastruttra locale ad una ambiente molto più esteso che comprende workload eterogenei, gestioni su Azure e spesso cloud provider di terze parti.
Rimane comunque fondamentale e tassativo mettere in sicurezza l’ambiente on-premises allo stesso modo con cui si cura l’ambito cloud.
La finalità di Active Directory Tier MODEL è quella di migliorare il contenimento delle minacce dove generalmente l’isolamento rete non è efficace o SUFFICIENTE. Alcuni attacchi puntano ad ottenere la Domain Dominance ed utilizzano tecniche di furto di credenziali come “Pass the Hash” o “Pass the ticket”: questi attacchi hanno spesso come origine i PC degli standard user.
Se su tali computer accediamo con account sensibili, lasciamo inevitabilmente delle impronte che comportano l’esposizione di credenziali, consentendo ad un hacker di fare movimenti laterali ed escalation con privilegi amministrativi ad Active Directory.
L’implementazione di Active Directory Tier MODEL in combinata con Local Administrator Password Solution (LAPS), contribuisce a mitigare il furto di credenziali che sono alla base degli attacchi all’identità.
Per quanto riguarda LAPS vi rimando a questo articolo di Nicola Ferrini Implementare Local Administrator Password Solution (LAPS) – ICT Power
Per quanto riguarda Active Directory Tier MODEL proseguite su questo articolo!
Per raggiungere il nostro obbiettivo dobbiamo “tagliare” in tre fette logiche la nostra Active Directory come riportato in figura.
Ecco un esempio di come andremo a collocare i nostri Utenti, Gruppi e Server all’interno di ogni Tier:
Tier 0 – Comprenderà oggetti che hanno diritti amministrativi sull’intero ambiente e che hanno la capacità di gestire l’identità e permessi enterprise-wide.
Gruppi e membri: Domain Admins, Enterprise Admins, Schema Admins, Backup Operators
Server e App: Domain Controllers, AAD Connect, PKI, Backup Server, Management Server, Antivirus Server, App che lanciano servizi sui DC, Amministratori di ambienti virtuali
Tier 1 – Comprenderà oggetti che hanno diritti amministrativi sulle risorse server ed utenti che gestiscono dati business-critical ed applicazioni
Gruppi e membri: Server Operators
Server e App: Application Servers, Data Stored Servers, Server Operators di ambienti virtuali
Tier 2 – Comprenderà oggetti che controllano e gestiscono il parco client
Gruppi e membri: HelpDesk Operators, Users e Device Support
Dispositivi: Workstations e Laptops
Ci tengo a precisare che implementare Active Directory Tier Model NON significa necessariamente ristrutturare la mia alberatura AD e conseguentemente OU, Oggetti, GPO, user e tutto quello che ne consegue. Se ho già organizzato un minimo “la mia AD” basterà solo creare le GPO/GPP Tiering e linkarle alla struttura OU in essere. Il grosso del lavoro Tiering sta nel cambiare modalità di accesso, vincolare e “coccolare” gli amministratori riguardo il cambiamento di “accesso porzionato” che inevitabilmente porterà.
Consiglio sempre di iniziare con Il Tier Model partendo dallo strato Dispositivi (Tier 2) per i seguenti motivi:
- Sono la parte più esposta da dove (nella stragrande maggioranza dei casi) entrano le minacce attraverso la navigazione internet e la posta elettronica. E’ il livello meno gestito (tanto sono client) ma quello più pericoloso.
- Partendo con le GPO sui client (sempre per piccoli steps) avremo l’opportunità di fare esperienza graduale con il Tier Model così da arrivare ad affrontare i livelli superiori con una migliore consapevolezza.
Stato ambiente pre AD Tier Model
Per il lavoro che faccio ho la fortuna di conoscere tante realtà e di vedere come i vari IT gestiscono Active Directory. Conosco diversi IT admin che hanno separato il loro account standard per attività amministrative (snieri e snieri.adm). Questo approccio in genere lo usano per tutti gli utenti che necessitano di privilegi in AD quindi deleghe ai service desk, sviluppatori ecc ecc. Altri IT admin promuovono “per praticità” il proprio account standard (snieri) a Domain Admin, si connettono al proprio pc, su tutti i pc per offrire assistenza e, cosa ancora più pericolosa, si collegano sui Domain Controller.
Figure 1 – Domain Admins members
In questo caso il gruppo di supporto HD è popolato da diversi standard users, ha diritti amministrativi sul dominio e di conseguenza possono connettersi su tutti i dispositivi aziendali.
Il nostro amministratore snieri.adm sul suo file server FS1 ha diversi utenti locali (bim, bum, bam che devono lanciare processi per applicativi), ha il gruppo Support HD fra i local Adminis ed altri due utenti Standard. Una volta loggato si connette tranquillamente alle share amministrative del proprio parco client \\w10.demo.lab\admin$ e con tale account opera “per comodità” su tutto l’ambiente saltando di macchina in macchina e, cosa ancora più rischiosa, di Tier in Tier (in questo caso da un dispositivo Tier1 ad un dispositivo Tier2).
Figure 2 – Stato server pre AD Tier Model
Situazione simile avviene sui device Windows:
Il nostro standard user snieri sulla sua workstation W10 ha diversi utenti locali (bim, bum, bam che devono lanciare processi per applicativi), ha il gruppo Support HD fra i local Admins ed altri due utenti Standard. Siccome è stato messo volutamente fra i Local Administrators sul server FS1 (vedi Figura 2) riesce ad accedere remotamente \\FS1.demo.lab\admin$. Anche in questo caso abbiamo una user standard che accede a share amministrative e, cosa ancora più rischiosa, salta di Tier in Tier (in questo caso da un dispositivo Tier2 ad un dispositivo Tier1).
Figure 3 – Stato client pre AD Tier Model
In un ambiente configurato in questo modo gli utenti amministrativi possono lanciare task, job, accedere liberamente su tutti i tre Tier siccome non esistono vincoli che limitino questi comportamenti.
Ok, basta chiacchiere… si fa sul serio: iniziamo a sporcarci le mani sanando la situazione.
Buon divertimento!
Preparazione struttura OU Tier, Users e Gruppi
Creiamo una struttura OU che posizioniamo in root. Gli diamo un nome generico che più preferite: può essere Admin. TieringModel, Tier. All’interno andremo a creare le tre OU Tier0, Tier1 e Tier2 che a loro volta conterranno tutto quello che ha a che fare con gli users e groups che verranno utilizzati ed applicati con le Group Policy al nostro ambiente.
L’esempio che vedete in figura è perfetto per iniziare.
Figure 4 – Active Directory Tier OU Tree
Lo script a seguire serve a creare account Tier relativi ai diritti che andremo ad assegnare.
In questo caso i Domain Admins dovranno avere tre account Tier distinti. Chi si occuperà del service Desk dovrà avere soltanto un account distinto per il Tier 2 mentre che si occuperà dei server avrà un account Tier 1. A seconda delle esigenze dei vostri utenti dovrete customizzare il file TierUsersList.csv che verrà richiamato da TierUsersAdd.ps1
TierUsersAdd.ps1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 |
<# .SYNOPSIS .DESCRIPTION .NOTES File Name: Created: Last modified: Author: [email protected] - [email protected] PowerShell: 4.0 or above Requires: -RunAsAdministrator OS: Version: Action: Disclaimer: This script is provided "As Is" with no warranties. .EXAMPLE .LINK #> ## ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- $Users = Import-Csv -Delimiter "," -Path "C:\Scripts\TierUsersList.csv" foreach ($User in $Users) { $Displayname = $User.displayname $Firstname = $User.firstname $Lastname = $User.lastname $SAM = $user.sam $UPN = $user.upn $Password = $user.Password $OU = $User.ou #$Description = $User.Description echo $Displayname New-ADUser -Name $Displayname -DisplayName $Displayname -GivenName $Firstname -Surname $Lastname -SamAccountName $SAM -UserPrincipalName $UPN -AccountPassword (ConvertTo-SecureString $Password -AsPlainText -Force) -Enabled $true -Path $OU -ChangePasswordAtLogon $true –PasswordNeverExpires $false } |
Figure 5 – Script creazione Tier users
TierUsersList.csv
displayname,firstname,lastname,sam,upn,password,ou
Stefano Nieri t2,Stefano,Nieri,snieri.t2,[email protected],Tier2login!,”OU=Accounts,OU=Tier 2,OU=Admin,DC=demo,DC=lab”
Pasquale Potito t2,Pasquale,Potito,ppotito.t2,[email protected],Tier2login!,”OU=Accounts,OU=Tier 2,OU=Admin,DC=demo,DC=lab”
Stefano Nieri t1,Stefano,Nieri,snieri.t1,[email protected],Tier1login!,”OU=Accounts,OU=Tier 1,OU=Admin,DC=demo,DC=lab”
Pasquale Potito t1,Pasquale,Potito,ppotito.t1,[email protected],Tier1login!,”OU=Accounts,OU=Tier 1,OU=Admin,DC=demo,DC=lab”
Stefano Nieri t0,Stefano,Nieri,snieri.t0,[email protected],Tier0login!,”OU=Accounts,OU=Tier 0,OU=Admin,DC=demo,DC=lab”
Pasquale Potito t0,Pasquale,Potito,ppotito.t0,[email protected],Tier0login!,”OU=Accounts,OU=Tier 0,OU=Admin,DC=demo,DC=lab”
Figure 6 – Lista utenti Tier in formato csv
Nella OU Groups creiamo i gruppi che vedete indicati in figura. Ogni user Tier dovrà esser inserito nel gruppo relativo.
Il gruppo TierStandBy sarà utile per bypassare temporaneamente il Tier Model a singoli utenti in caso di necessità e/o emergenza (successivamente approfondiremo meglio l’utilizzo)
Figure 7 – Elenco gruppi globali contenti i Tier Users
Figure 8 – Dettaglio utenti Tier Users
Creazione LocalAdmins_%Computername% e RemoteDesktopUsers_%Computername%
Lo script a seguire serve a creare automaticamente tutti i global group che eventualmente ospiteranno gli amministratori locali delle macchine soggetta a Tiering GPO.
Lo stesso automatismo vale per inserire i Remote Desktop Users.
Questo ci sarà utile per applicare a piacimento e senza nessun intervento sulle macchine, i diritti locali comodamente da AD. Nella stragrande maggioranza dei casi nessun std user è amministratore della propria macchina ma ci sono alcune tipologie di software (specie i legacy) che richiedono necessariamente che l’utente sia amministratore della macchina.
Lo script ManualSecurityGroupAdd.Workstation.ps1 riguarda lo strato Tier2 – quello workstations
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 |
<# .SYNOPSIS .DESCRIPTION .NOTES File Name: Created: Last modified: Author: [email protected] - [email protected] PowerShell: 4.0 or above Requires: -RunAsAdministrator OS: Version: Action: Disclaimer: This script is provided "As Is" with no warranties. .EXAMPLE .LINK #> ## ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- # Creazione gruppi LocalAdmins_$HostName $Exclusion1 = "*OU=MAC,OU=.NoWindows,OU=Workstations,OU=Demo,DC=demo,DC=lab" $Exclusion2 = "*OU=Linux,OU=.NoWindows,OU=Workstations,OU=Demo,DC=demo,DC=lab" Get-ADComputer -Filter {(Enabled -eq $true)} -SearchBase “OU=Workstations,OU=Demo,DC=demo,DC=lab” | Where-Object {($_.DistinguishedName -notlike $Exclusion1) -and ($_.DistinguishedName -notlike $Exclusion2)} | ForEach-Object { $HostName = $_.Name try { Get-ADGroup -Identity "LocalAdmins_$HostName" -InformationAction Ignore } catch { New-ADGroup -Name "LocalAdmins_$HostName" -samAccountName "LocalAdmins_$HostName" -Description "Local Administrators Access for $HostName" -Path "OU=Groups,OU=Tier 2,OU=Admin,DC=demo,DC=lab" -GroupCategory Security -GroupScope Global } } # Creazione gruppi RemoteDesktopUsers_$HostName Get-ADComputer -Filter {(Enabled -eq $true)} -SearchBase “OU=Workstations,OU=Demo,DC=demo,DC=lab” | Where-Object {($_.DistinguishedName -notlike $Exclusion1) -and ($_.DistinguishedName -notlike $Exclusion2)} | ForEach-Object { $HostName = $_.Name try { Get-ADGroup -Identity "RemoteDesktopUsers_$HostName" -InformationAction Ignore } catch { New-ADGroup -Name "RemoteDesktopUsers_$HostName" -samAccountName "RemoteDesktopUsers_$HostName" -Description "Remote Desktop Users Access for $HostName" -Path "OU=Groups,OU=Tier 2,OU=Admin,DC=demo,DC=lab" -GroupCategory Security -GroupScope Global } } |
Figure 9 – Script creazione LocalAdmins e RemoteDesktopUsers per Tier 2
Figure 10 – Risultato dello script creazione LocalAdmins e RemoteDesktopUsers
Lo script ManualSecurityGroupAdd.Server.ps1 riguarda lo strato Tier 1 – quello servers
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 |
<# .SYNOPSIS .DESCRIPTION .NOTES File Name: Created: Last modified: Author: [email protected] - [email protected] PowerShell: 4.0 or above Requires: -RunAsAdministrator OS: Version: Action: Disclaimer: This script is provided "As Is" with no warranties. .EXAMPLE .LINK #> ## ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- # Creazione gruppi LocalAdmins_$HostName $Exclusion1 = "*OU=ESXi,OU=Servers,OU=Demo,DC=demo,DC=lab" $Exclusion2 = "*OU=Linux,OU=Servers,OU=Demo,DC=demo,DC=lab" Get-ADComputer -Filter {(Enabled -eq $true)} -SearchBase “OU=Servers,OU=Demo,DC=demo,DC=lab” | Where-Object {($_.DistinguishedName -notlike $Exclusion1) -and ($_.DistinguishedName -notlike $Exclusion2)} | ForEach-Object { $HostName = $_.Name try { Get-ADGroup -Identity "LocalAdmins_$HostName" -InformationAction Ignore } catch { New-ADGroup -Name "LocalAdmins_$HostName" -samAccountName "LocalAdmins_$HostName" -Description "Local Administrators Access for $HostName" -Path "OU=Groups,OU=Tier 1,OU=Admin,DC=demo,DC=lab" -GroupCategory Security -GroupScope Global } } # Creazione gruppi RemoteDesktopUsers_$HostName Get-ADComputer -Filter {(Enabled -eq $true)} -SearchBase “OU=Servers,OU=Demo,DC=demo,DC=lab” | Where-Object {($_.DistinguishedName -notlike $Exclusion1) -and ($_.DistinguishedName -notlike $Exclusion2)} | ForEach-Object { $HostName = $_.Name try { Get-ADGroup -Identity "RemoteDesktopUsers_$HostName" -InformationAction Ignore } catch { New-ADGroup -Name "RemoteDesktopUsers_$HostName" -samAccountName "RemoteDesktopUsers_$HostName" -Description "Remote Desktop Users Access for $HostName" -Path "OU=Groups,OU=Tier 1,OU=Admin,DC=demo,DC=lab" -GroupCategory Security -GroupScope Global } } |
Figure 11 – Script creazione LocalAdmins e RemoteDesktopUsers per Tier 1
Figure 12 – Risultato dello script creazione LocalAdmins e RemoteDesktopUsers
Creazione GPO Tier2
Creiamo una GPO di nome Tier2 ed andiamo ad editare i seguenti settings.
Figure 13 – User Rights Assignment Not Defined
Per ogni policy setting evidenziato nella figura riportata creeremo un gruppo custom che verrà iniettato fra i gruppi locali di ogni client soggetto a questa GPO. Si tratta di un gruppo in cui collocheremo i Sensitive Groups a cui applicheremo le restrizioni Tier.
Editare tutti i cinque settaggi come in figura.
Figure 14 – User Rights Assignment Sensitive Groups
Fino ad ottenere il seguente risultato
Figure 15 – User Rights Assignment Sensitive Groups
Editato l’ambito GPO User Rights Assignment proseguiamo ad editare la parte di Group Policy Preferences (nella stessa policy Tier 2) ed aggiungiamo nel pannello “Local User and Groups” i seguenti oggetti
Figure 16 – Tiering GPP Local Administrator
n.b.: ognuno dei seguenti oggetti che troverete numerati nei prossimi steps saranno nuovo item da creare
Questo settaggio serve ad evitare che la local admin password scada. Nel caso sia disabilitato lo attiva.
Figure 17 – Tiering GPP Account never expires
2) New -> Local Group
Questa settaggio serve cancellare tutti gli utenti e gruppi inseriti fra i local administrators
Figure 18 – Tiering GPP Delete all member
Sul Tab Common, selezionare Item-Level targeting
Figure 19 – Tiering GPP Item-level targeting
Aggiungere New Item OU e selezionare il seguente path OU=Custom,OU=Laptops,OU=IT,OU=Workstations,OU=Demo,DC=demo,DC=lab
In questo modo selezionando la OU Custom potremo evitare che vengano rimossi tutti i Local Administrators alle macchine in quella OU
E’ utile specialmente per le macchine sviluppatori o linee di produzione quando alcuni applicativi necessitano obbligatoriamente di aver un local admin user per far funzionare sw legacy e/o sw bordo linea.
N.b.: assicurarsi che la dicitura sia “computer is not OU=…”. In caso contrario premere F8
Figure 20 – Tiering GPP Item-level targeting
Questo settaggio serve ad imporre nel gruppo Administrators locale gli amministratori che desideriamo
Figure 21 – Tiering GPP Administrators (built-in)
Questo settaggio serve ad imporre fra i local Administrators il gruppo precedentemente creato via powershell con lo script ManualSecurityGroupAdd.Workstation.ps1
Attraverso questa stringa %DomainName%\LocalAdmins_%Computername% andrà a cercare nel dominio il gruppo relativo all’oggetto account computer
Figure 22 – Tiering GPP %DomainName%\LocalAdmins_%Computername%
In ambienti molto grandi consiglio di ottimizzare la query LDAP attraverso questo Item-Level targeting
Figure 23 – Tiering GPP Item-level targeting LDAP query
Il seguente filtro è utile per targettizzare la query solo al path dove risiedono i gruppi LocalAdmins evitando per realtà molto grandi che venga fatta una query LDAP su tutta AD
Filter: (&(objectCategory=group)(objectClass=group)(CN=LocalAdmins_%ComputerName%))
Binding: LDAP://OU=Groups,OU=Tier 2,OU=Admin,DC=demo,DC=lab
Figure 24 – Tiering GPP Item-level targeting LDAP query
Questo settaggio serve ad imporre fra i Remote Desktop Users il gruppo precedentemente creato via powershell con lo script ManualSecurityGroupAdd.Workstation.ps1
Attraverso questa stringa %DomainName%\RemoteDesktopUsers_%Computername% andrà a cercare nel dominio il gruppo relativo all’oggetto account computer
Figure 25 – Tiering GPP %DomainName%\RemoteDesktopUsers_%Computername%
Pure in questo caso consiglio Item-Level targeting che sarà identico a quello del punto 4
Figure 26 – Tiering GPP Item-level targeting LDAP query
Filter: (&(objectCategory=group)(objectClass=group)(CN=LocalAdmins_%ComputerName%))
Binding: LDAP://OU=Groups,OU=Tier 2,OU=Admin,DC=demo,DC=lab
Figure 27 – Tiering GPP Item-level targeting LDAP query
Questo settaggio crea e rimuove i membri del gruppo Custom Accounts Group che è il gruppo su cui abbiamo applicato tutti i Deny sotto User Right Assignment
Figure 28 – Tiering GPP Custom Accounts Group
Questo settaggio è “il fulcro” del Tiering Model. Inserisce i sensitive account tier nel gruppo Custom Accounts Group e con questo settaggio applicheremo i Deny User Right Assignment.
Questo è l’elenco gruppi da inserire nella GPO Tier2
Enterprise Admins, Domain Admins, Schema Admins, Tier0AccountsAll, Tier1AccountsAll, Tier2AccountsAll
Consiglio vivamente di inserire anche il Gruppo Tier2AccountsAll siccome sulle macchine Tier1 e Tier2 per effettuare attività con diritti amministrativi va utilizzato solo l’amministratore locale gestito da LAPS.
Implementare Local Administrator Password Solution (LAPS) – ICT Power
Figure 29 – Tiering GPP Custom Accounts Group
Pure in questo caso creiamo un Item-Level targeting che andrà ad escludere il Tiering in caso di emergenza. Basterà collocare il computer “in difficoltà” nel gruppo TierStandBy, attendere che il dispositivo riceva le GPO ed automaticamente tutti i vincoli Tier su di esso non avranno più alcun effetto
Figure 30 – Tiering GPP Item-level targeting
Figure 31 – Tiering GPP TierStandBy
Terminati tutti gli steps dovremo avere una lista setting GPP simile a questa.
Figure 32 – Tiering GPP All settings
Salvare la GPO Tier2. Ora siamo pronti ad applicare la GPO e vederne i risultati
Come detto precedentemente non devo spostare nessun oggetto della mia struttura AD; mi limito a linkare un oggetto. Consiglio ovviamente di applicare la GPO Tier2 ad un ristretto gruppo di client per valutarne i benefici ed effetti per poi estendere successivamente a tutto il parco client Workstations. Da Group Policy Management console, selezioniamo la OU Workstations, tasto destro e selezioniamo “Link an Existing GPO…” e scegliamo la GPO Tier2. Questo il risultato della GPO applicata:
Figure 33 – Tiering GPO Tier2
Stato ambiente post AD Tier Model
Ora che il nostro client W10 ha recepito la GPO Tier2 (un Gpupdate /force o un restart accelerano le cose) andiamo a vedere il risultato.
Per prima cosa il mio affezionato snieri.adm ha il blocco dell’interactive logon. Lo stesso vale per tutti i gruppi che abbiamo inserito nei Custom Account Group (figura 29)
Figure 34 – Stato client post AD Tier Model – sign-in Non Allowed
Una volta entrati con il nostro standard user snieri vediamo che tutto è cambiato rispetto l’inizio. Le due immagini successive sono relative al pre e al post Tier GPO.
Figure 35 – Stato client pre AD Tier Model
Local Group Administrators: tutti gli utenti locali sono stati rimossi dal gruppo e al loro posto vediamo solo quello imposto da GPP. Possiamo decidere attraverso la membership group su Active Directory chi è Local Administrator della macchina
Local Group Custom Account Group: è stato creato e al suo interno vediamo i gruppi imposti da GPP.
Local Group Remote Desktop Users: è stato popolato. Possiamo decidere attraverso la membership group su Active Directory chi può fare RDP sulla macchina (funzionalità molto utile per l’assegnazione diritto RDP sui Servers).
Figure 35 – Stato client post AD Tier Model – Membership
Se provo a lanciare un Task o un cmd con diritti elevati da un utente appartenente ai Custom Account Group (figura 29) ottengo un Deny.
Figure 36 – Stato client post AD Tier Model – RunAs
Se provo a connettermi alla share amministrativa di un computer soggetto a Tiering \\w10.demo.lab\admin$ ottengo il seguente risultato.
Figure 37 – Stato client post AD Tier Model – Logon Failure
Creazione GPO Tier1 e Tier0
Potete tranquillamente copiare la GPO Tier2 e crearne due nuove con nome Tier1 e Tier0 siccome il grosso del lavoro è già stato fatto con precedentemente.
Andranno cambiati conseguentemente i path degli Item-Level targeting che dovranno esser collegati alle OU Server. Potremo incrementate le restrizioni delle User Rigth Assignement (figura 15) siccome applichiamo i setting sui server e poi Domain Controllers con la Tier0.
Conclusioni
Come abbiamo visto, l’implementazione di Active Directory Tier Model non è difficile lato tecnico. Sono “solo” Group Policy e Group Policy Preference. La parte complessa del Tiering è fare una buona analisi in merito ai servizi, processi, workload e software che tale implementazione andrà ad impattare. Un altro compito difficile è inculcare nelle teste degli IT admin un cambio di approccio radicale. Dovranno passare da “il mondo felice” in cui con una credenziale se ne vanno in giro per tutta Active Directory ad “un mondo articolato” per cui su ogni Tier necessitano di apposite credenziali che NON dovranno aver la stessa password, dovranno aver scadenza, alfanumeriche, complesse ecc ecc… mai una gioia!
A tal proposito consiglio un buon password manager.
Link utili: