Su AZ-802 utenti e gruppi non si chiedono piu’ come procedura, ma come vincoli: perche’ una conversione di scope e’ grigia nella console, perche’ un gruppo che riceve la posta non compare nella ACL di una cartella, quale gruppo mettere in mezzo quando gli utenti stanno in un’altra foresta. Stessa materia di AZ-800, profondita’ diversa. Qui ci sono le regole che l’esame usa come discriminante, piu’ la parte nuova: i service account, dove Windows Server 2025 ha aggiunto un tipo che prima non esisteva.
Utenti: il lavoro a volume, non il singolo account
Un utente si crea con New-ADUser, e i parametri che contano sono quelli che separano la risposta giusta da quella plausibile: -AccountPassword (vuole un SecureString, quindi ConvertTo-SecureString -AsPlainText -Force), -Enabled $true (senza, l’account nasce disabilitato), -UserPrincipalName, -Path per l’OU. Per la manutenzione: Set-ADUser, Set-ADAccountPassword, Unlock-ADAccount, Move-ADObject, e Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 per gli account dormienti (-AccountExpired per quelli scaduti).
Due dettagli che l’esame ama: gli account protetti da AdminSDHolder si riallineano ogni ora, quindi una ACL messa a mano su di loro sparisce; e il gruppo Protected Users vieta NTLM, delega e cache delle credenziali — ottimo per gli admin, letale per un account di servizio.
Tipo e scope sono due proprieta’ diverse
Un gruppo AD ha un tipo (security o distribution) e uno scope (Domain Local, Global, Universal). Sono indipendenti, e confonderli e’ la trappola piu’ redditizia dell’esame.
| A cosa serve | Compare in una ACL? | |
|---|---|---|
| Security group | Assegnare permessi e user right; puo’ anche ricevere posta | Si’ |
| Distribution group | Solo lista di distribuzione email | No |
Un gruppo di distribuzione a cui hai mandato una mail con successo funziona benissimo come lista e resta comunque invisibile al selettore dei permessi di una share: va convertito in security group (Set-ADGroup -GroupCategory Security), non ricreato.
Lo scope, invece, decide chi puo’ stare dentro e dove il gruppo puo’ ricevere permessi.
| Scope | Puo’ contenere | Concede permessi | Puo’ essere membro di |
|---|---|---|---|
| Global | Account e global group dello stesso dominio | Foresta e domini/foreste fidati | Universal, global dello stesso dominio, domain local |
| Universal | Account, global e universal di qualsiasi dominio della stessa foresta | Foresta e foreste fidate | Universal, domain local, gruppi local sui server |
| Domain Local | Account e global di qualsiasi dominio fidato, anche di altre foreste, universal della foresta, domain local dello stesso dominio | Solo nel proprio dominio | Domain local dello stesso dominio, gruppi local sui server |
I gruppi del contenitore Builtin hanno scope Builtin Local: tipo e scope non si cambiano, punto.
Conversioni di scope: decide l’annidamento, non il functional level
Quando la voce «Universal» e’ grigia nelle proprieta’ di un gruppo, l’istinto e’ dare la colpa al livello funzionale. Quasi sempre e’ sbagliato: qualsiasi foresta moderna e’ oltre la soglia richiesta. Il blocco viene dalle regole di annidamento:
- Global → Universal: consentito solo se il gruppo non e’ membro di un altro global group.
- Universal → Global: consentito solo se il gruppo non contiene altri universal group.
- Universal → Domain Local: consentito solo se non e’ membro di altri universal group.
- Domain Local → Universal: consentito solo se non contiene altri domain local group.
Non esiste il passaggio diretto Global ↔ Domain Local: si passa da Universal, e ogni tappa deve rispettare la sua regola. Se una conversione e’ negata, la diagnosi e’ Get-ADPrincipalGroupMembership (di chi e’ membro) e Get-ADGroupMember (chi contiene), non il livello funzionale.
Su quest’ultimo, aggiorna la memoria: oggi i livelli funzionali di dominio e foresta si possono anche abbassare (Set-ADDomainMode, Set-ADForestMode), con i vincoli del caso. La vecchia regola «si sale e non si scende» non e’ piu’ vera.
Multi-dominio e multi-foresta: dove mettere cosa
Lo schema di riferimento e’ AGDLP: gli Account vanno in un Global group nel loro dominio, il global group entra in un Domain Local group nel dominio della risorsa, e il permesso (P) si assegna al domain local. In una foresta multi-dominio diventa AGUDLP, con un Universal in mezzo per raccogliere global group di domini diversi.
Fra due foreste la variante obbligata e’ una sola: gli universal non accettano principal di un’altra foresta, quindi il gruppo che sta nella ACL dev’essere domain local (o un gruppo local del server membro) nel dominio della risorsa, e dentro ci va il global group dell’altra foresta. Non serve — e non si puo’ — copiare gli utenti. Il presupposto e’ il forest trust, che netdom trust non sa creare fra due foreste AD DS: serve la console Active Directory Domains and Trusts.
C’e’ un costo da conoscere: i gruppi universal sono replicati nel global catalog insieme alla loro membership, quindi ogni modifica ai membri genera replica verso tutti i GC della foresta; global e domain local pubblicano nel GC il gruppo ma non l’elenco dei membri. Per questo gli universal si usano per insiemi stabili. Sui siti senza GC, l’universal group membership caching evita che il logon fallisca quando il GC non e’ raggiungibile.
Scegliere il service account giusto
| Tipo | Su quante macchine | Chi gestisce la password |
|---|---|---|
| Account utente di dominio | Qualsiasi | L’amministratore, a mano |
Virtual account (NT SERVICE\...) |
Una, solo locale | Windows; verso la rete usa il computer account |
| sMSA | Una sola | Il computer |
| gMSA | Molte (farm, NLB) | Il domain controller la calcola, gli host autorizzati la prelevano |
| dMSA (Windows Server 2025) | Una, legata all’identita’ della macchina | Il DC, con chiavi interamente casuali |
gMSA
Prerequisiti: una KDS root key nel dominio (Add-KdsRootKey), e host che supportino i tipi di crittografia Kerberos richiesti.
New-ADServiceAccount -Name gMSA-Web -DNSHostName gMSA-Web.contoso.com `
-PrincipalsAllowedToRetrieveManagedPassword "WebFarmHosts"
Install-ADServiceAccount -Identity gMSA-Web # su ogni host
Test-ADServiceAccount -Identity gMSA-WebIl dettaglio che l’esame chiede: l’intervallo di cambio password si imposta solo alla creazione, con -ManagedPasswordIntervalInDays (default 30 giorni, attributo msDS-ManagedPasswordInterval). Non e’ modificabile dopo: per cambiarlo si crea un nuovo gMSA e si ripuntano i servizi. Set-ADServiceAccount modifica le altre proprieta’, non quella. Altri due fatti: il nome di un gMSA dev’essere unico a livello di foresta, non di dominio; e Reset-ADServiceAccountPassword vale per gli sMSA, non per i gMSA.
dMSA (solo Windows Server 2025)
Il dMSA lega l’autenticazione all’identita’ del dispositivo: il segreto e’ derivato dalla credenziale del computer account, resta sul DC e non e’ prelevabile altrove — e’ la risposta al kerberoasting. Serve comunque la KDS root key. Si crea con New-ADServiceAccount -CreateDelegatedServiceAccount $true, e la migrazione da un account utente tradizionale e’ in due tempi:
Start-ADServiceAccountMigration -Identity "dMSA-App" -SupersededAccount "CN=svc-app,..."
Complete-ADServiceAccountMigration -Identity "dMSA-App" -SupersededAccount "CN=svc-app,..."Fra i due comandi il dMSA impara le macchine su cui gira il servizio. Al Complete, SPN e deleghe vengono copiati sul dMSA e l’account originale viene disabilitato (non cancellato: serve per tornare indietro; per annullare ci sono Undo-ADServiceAccountMigration e Reset-ADServiceAccountMigration). Vincoli: non si migra da un sMSA o da un gMSA a un dMSA, tutte le macchine coinvolte devono supportare il dMSA prima del Complete, e la unconstrained delegation smette di funzionare a migrazione conclusa.
Trappole tipiche d’esame
- «Il gruppo riceve la posta ma non si trova nella ACL» non e’ un problema di scope: e’ un distribution group. Si converte a security (
Set-ADGroup -GroupCategory Security); ricrearlo e’ la risposta lunga e sbagliata. - Conversione di scope negata: la causa quasi sempre e’ l’annidamento (un global membro di un altro global non diventa universal), non il livello funzionale. E ricorda che oggi i livelli funzionali di dominio e foresta si possono anche abbassare.
- Utenti di un’altra foresta: il gruppo che finisce nella ACL dev’essere domain local nel dominio della risorsa. Un universal non accetta membri di un’altra foresta, un global non accetta membri di un altro dominio.
- Universal ≠ gratis: la sua membership sta nel global catalog e si replica in tutta la foresta. E’ la risposta corretta alla domanda «quale effetto ha aggiungere utenti a questo gruppo?».
- Intervallo password di un gMSA: non e’ un parametro di
Set-ADServiceAccount. Si fissa alla creazione e per cambiarlo serve un nuovo gMSA. - gMSA e failover cluster: il servizio Cluster in se’ non supporta i gMSA, ma i servizi che girano sopra il cluster (servizi Windows, app pool IIS, scheduled task) si’. Le due affermazioni sembrano in contraddizione e non lo sono.