Gruppi: scope e nesting

I security group in AD DS hanno tre scope che determinano da dove arrivano i membri e dove si possono usare le permission. Un domain local group accetta membri da qualsiasi dominio della forest ma serve ad assegnare permission solo su risorse del proprio dominio. Un global group contiene solo membri del proprio dominio, però è utilizzabile ovunque nella forest. Uno universal group accetta membri da tutta la forest e ha la membership replicata nel global catalog: va usato con parsimonia perché ogni modifica genera traffico di replica.

Il pattern raccomandato è AGDLP: gli Account entrano in un Global group, il Global entra in un Domain Local group, e al Domain Local si assegna la Permission. In scenari multi-dominio si estende ad AGUDLP, inserendo uno Universal group tra Global e Domain Local per aggregare account di domini diversi. Il group nesting (gruppo dentro gruppo) riduce la manutenzione, ma va tenuto poco profondo per non perdere tracciabilità dei permessi effettivi.

Delega del controllo sulle OU

La delegation of control permette di assegnare compiti amministrativi granulari (reset password, creazione utenti, gestione della membership di un gruppo) senza aggiungere nessuno a Domain Admins. Tecnicamente il Delegation of Control Wizard scrive ACE sulla ACL della OU, seguendo il principio del least privilege. La delega si eredita lungo la gerarchia delle OU, quindi conviene progettare la struttura OU in funzione dei confini amministrativi. Per rivedere o revocare una delega si usa la scheda Security della OU (con Advanced Features attivo): il wizard aggiunge ACE, non le toglie.

Group Policy: precedenza e scoping

I GPO si applicano nell’ordine LSDOU: Local, Site, Domain, OU (comprese le OU annidate). L’ultimo che scrive vince, quindi in caso di conflitto un GPO su una OU figlia sovrascrive quelli di domain e site. All’interno dello stesso contenitore conta il link order: numero più basso = precedenza più alta. Due leve alterano questa gerarchia: Enforced rende un GPO non sovrascrivibile e immune al blocco, mentre Block Inheritance su una OU ferma l’ereditarietà dai livelli superiori (ma non i GPO Enforced).

Lo scoping decide a chi si applica un GPO già linkato. Il security filtering limita l’applicazione a gruppi o utenti specifici: servono i permessi Read e Apply Group Policy e, dopo MS16-072, l’account computer deve avere almeno Read. Il WMI filter aggiunge una condizione valutata sul target (es. versione di OS, o presenza di batteria per i portatili): se la query è falsa il GPO viene saltato. Il loopback processing serve invece ad applicare le impostazioni utente in base alla posizione del computer.

Fine-grained password policy (PSO)

L’account policy di dominio (password, lockout, Kerberos) vive nel Default Domain Policy e vale per tutti gli utenti del dominio: esiste una sola account policy a livello di dominio. Per fare eccezioni si usano le fine-grained password policy, implementate come PSO (Password Settings Object) nel Password Settings Container. Un PSO si collega a utenti o a global security group — mai a una OU.

Quando più PSO ricadono sullo stesso utente vince quello con msDS-PasswordSettingsPrecedence più basso; un PSO assegnato direttamente all’utente batte sempre quelli ereditati via gruppo. Il valore effettivo è il resultant PSO (msDS-ResultantPSO). Si gestiscono da Active Directory Administrative Center o via PowerShell.

Trappole tipiche d’esame

  • Account policy su una OU per cambiare la password degli utenti di dominio → soluzione: non funziona; le impostazioni di password/lockout in un GPO su OU valgono solo per gli account locali dei computer, non per gli utenti del dominio. Usa Default Domain Policy o una PSO.
  • Password più restrittiva solo per gli amministratori → soluzione: crea una PSO collegata a un global group, non un GPO su OU; le FGPP non si linkano alle OU.
  • Due PSO sullo stesso utente → soluzione: vince il precedence più basso, e l’assegnazione diretta all’utente prevale su quella via gruppo.
  • Un GPO figlio deve comunque cedere a una regola di sicurezza aziendale → soluzione: marca il GPO padre come Enforced; supera sia il link order sia il Block Inheritance.
  • GPO che non si applica dopo aver ristretto il security filtering → soluzione: verifica che l’account computer abbia Read (regressione MS16-072), altrimenti il GPO viene ignorato.
  • Permessi su una risorsa di dominio a utenti di più domini → soluzione: segui AGUDLP con uno universal group, invece di assegnare permission direttamente ai global group.