Diagnosi di Active Directory: Recycle Bin, DSRM, replica e Kerberos

Il dominio D7 non chiede di configurare Active Directory: chiede di diagnosticarlo mentre e’ rotto. Le domande partono quasi sempre da un output reale — una riga di repadmin, un Event ID, un messaggio di errore a video — e chiedono quale sia la causa e quale il comando giusto. La differenza fra passare e non passare sta nel saper distinguere lo strumento che ripara dallo strumento che serve solo a guardare.

Active Directory Recycle Bin: guarda avanti, non indietro

Il Cestino conserva tutti gli attributi dell’oggetto cancellato, compresi quelli link-valued: un utente ripristinato riprende da solo le appartenenze ai gruppi e i diritti che aveva un istante prima della cancellazione, anche fra domini diversi.

Prerequisiti: livello funzionale di foresta e dominio almeno Windows Server 2008 R2, appartenenza a Domain Admins, e ADAC o il modulo PowerShell di Active Directory installati.

Enable-ADOptionalFeature -Identity 'CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=contoso,DC=com' -Scope ForestOrConfigurationSet -Target 'contoso.com'

Se il cmdlet fallisce, la documentazione suggerisce di spostare schema master e domain naming master sullo stesso DC del dominio radice e rilanciarlo da li’.

Due fatti che l’esame sfrutta senza pieta’:

1. L’abilitazione e’ irreversibile. Non esiste un Disable-ADOptionalFeature che torni indietro. (Nota a margine: oggi i livelli funzionali di dominio e foresta si possono abbassare — la vecchia regola «mai» non vale piu’ — ma questo non riapre la questione: il Cestino resta abilitato.)
2. Non recupera nulla di cancellato prima dell’abilitazione. Gli oggetti eliminati ieri, con il Cestino acceso oggi, non sono nel container Deleted Objects: per quelli serve un authoritative restore da backup, in DSRM.

Il ripristino si fa da ADAC nel container Deleted Objects con Restore (posizione originale) o Restore To (posizione diversa), oppure da PowerShell:

Get-ADObject -Filter 'Name -Like "*User*"' -IncludeDeletedObjects | Restore-ADObject
Get-ADObject -Filter 'Name -Like "*User*"' -IncludeDeletedObjects | Restore-ADObject -TargetPath "OU=Corp,DC=contoso,DC=com"

Il -TargetPath serve nel caso classico in cui anche l’OU che conteneva gli oggetti e’ sparita.

DSRM: quando il database va recuperato, non l’oggetto

Directory Services Restore Mode e’ un’opzione di avvio del domain controller in cui ntds.dit resta offline: si accede con l’account amministratore locale DSRM, la cui password si imposta alla promozione e si cambia con ntdsutil (set dsrm password). Si entra e si esce con bcdedit /set safeboot dsrepair e bcdedit /deletevalue safeboot, o dal menu di avvio avanzato.

L’authoritative restore alza il numero di versione degli oggetti ripristinati, cosi’ la replica li propaga invece di ri-cancellarli. E’ questa la differenza che l’esame chiede: non-authoritative ripara un DC, authoritative impone un contenuto a tutto il dominio.

SYSVOL: con DFSR i BurFlags non esistono

Su un dominio moderno SYSVOL e’ replicato da DFS Replication. I valori di registro BurFlags D2 e D4 appartenevano a FRS e non hanno alcun effetto su DFSR; nemmeno la console DFS Management o dfsradmin servono, perche’ la replica di SYSVOL e’ volutamente protetta dalle interfacce di gestione. Si agisce su ADSI Edit, sul DN:

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=​<nome-server>​,OU=Domain Controllers,DC=​<dominio>

Il punto che fa cadere: se rendi autorevole un DC devi rendere non autorevoli tutti gli altri, altrimenti i DC che non hai toccato genereranno conflitti. Come DC autorevole si sceglie il PDC Emulator, perche’ il suo SYSVOL e’ normalmente il piu’ aggiornato. Alla fine si riporta DFSR ad Automatic ovunque.

Replica AD: l’errore 1722 non e’ un problema di Active Directory

repadmin /showrepl che riporta 1722 (0x6ba): The RPC server is unavailable dice una cosa sola: il client RPC sul DC di destinazione non e’ riuscito ad aprire la connessione TCP verso il DC di origine. La causa sta sotto: DNS, routing, firewall, IPsec, driver di rete. Le stesse voci compaiono in repadmin /replsum, /syncall, in dcdiag e negli eventi NTDS KCC 1311, 1865, 1925 e NTDS Replication 1960.

Sequenza diagnostica utile:

• dcdiag /test:dns /v /e /f:dns.log — la risoluzione nomi e’ la causa piu’ frequente;
• portqry -n <server-di-origine> -e 135 e portqry -n <server-di-origine> -r 1024-5000 — l’endpoint mapper sulla 135 dice al client su quale porta dinamica ascolta il servizio; se il range dinamico e’ filtrato, la 135 risponde e la replica fallisce lo stesso;
• verifica della chiave HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\ClientProtocols (devono esserci ncacn_http, ncacn_ip_tcp, ncacn_np, ncacn_ip_udp);
• eventi LSASRV 40960/40961, tipici della frammentazione UDP, e disallineamenti di SMB signing fra DC.

Quando il client non trova nessun DC

nltest /dsgetdc:contoso.com /force che risponde «The specified domain either does not exist or could not be contacted» (errore 1355) e’ un problema di DC Locator, non di trust. Su un DC appena promosso in un sito nuovo la causa tipica e’ la mancata registrazione dei record SRV in DNS.

Si verifica con nslookup sul record host del server e sul record guid._msdcs.rootdomain.com; si controlla la raggiungibilita’ con PortQryUI sul set Domains and Trusts, dove la UDP/389 e’ la porta richiesta per la scoperta dei servizi AD. Per rimediare: ipconfig /registerdns rimette a posto il record host, mentre per i record di servizio del domain controller si arresta e riavvia il servizio Netlogon. Se serve scendere di livello, nltest /dbflag:0x2000ffff accende il log di debug in %windir%\Debug\netlogon.log.

Kerberos: l’Event ID 4 non e’ sempre l’orologio

Evento 4 con sorgente Kerberos significa che il client non ha potuto decifrare il service ticket. Le cause plausibili sono due, e l’esame gioca proprio su questo:

Se w32tm conferma che client, server e DC sono sincronizzati, KRB_AP_ERR_MODIFIED non e’ il tempo: cerca l’SPN doppio. Prima di rifare le prove, svuota la cache dei ticket con klist purge e klist -li 0x3e7 purge (contesto SYSTEM) e rileggi con klist tickets. Nota di contorno che ricorre: se client e servizio stanno sullo stesso computer, Kerberos e’ disabilitato per impostazione predefinita.

Secure channel e account computer

«The trust relationship between this workstation and the primary domain failed», NETLOGON 3210 nel log System, accesso possibile solo con credenziali locali o cached, e nltest /sc_query:contoso.com che restituisce Status = 5 0x5 ERROR_ACCESS_DENIED: e’ la password dell’account computer fuori sincrono.

La raccolta dati confronta due valori: Cupdtime (l’ultimo aggiornamento del segreto LSA $MACHINE.ACC sul dispositivo) e pwdLastSet sull’oggetto computer in AD. Da qui i due scenari:

• AD ha la password piu’ recente del dispositivo — il dispositivo e’ rimasto indietro;
• il dispositivo ha la password piu’ recente di AD — la causa e’ in Active Directory: replica non convergente, DC ripristinato da backup, o authoritative restore dell’oggetto computer. Si risolve prima il problema lato AD; solo dopo si rimette a posto il canale con nltest /sc_reset:contoso.com oppure Test-ComputerSecureChannel -Repair -Credential *, e si riavvia.

Vale anche la verifica banale che le chiavi ComputerName e hostname nel registro contengano il nome corto e non l’FQDN. Il rejoin al dominio funziona, ma nasconde la causa: se il problema si ripresenta, non hai risolto niente.

Per la macchina di un domain controller la procedura e’ diversa: si arresta il servizio Kerberos Key Distribution Center portandolo a Manual, si svuota la cache dei ticket, si esegue netdom resetpwd /s:<altro-dc> /ud:<dominio>\<utente> /pd:* localmente sul DC da riparare, si riavvia e si riporta il KDC ad Automatic.

Trappole tipiche d’esame

• Il Cestino non e’ una macchina del tempo. Abilitarlo lunedi’ non recupera gli account cancellati venerdi’: quelli si recuperano solo con un authoritative restore da backup in DSRM. E l’abilitazione non si annulla.
• BurFlags D2/D4 su SYSVOL replicato da DFSR non fa nulla. Si usano msDFSR-Enabled e msDFSR-Options=1 in ADSI Edit piu’ dfsrdiag pollad — e se rendi autorevole un DC devi rendere non autorevoli tutti gli altri, altrimenti raccogli conflitti invece della sincronizzazione.
• 1722 e’ un errore di trasporto, non del database. Non si ripara con ntdsutil ne’ con un authoritative restore: si guardano DNS, firewall, porta 135 e il range dinamico. Un 1722 che dura giorni e’ un rischio di lingering object, non un fastidio.
• KRB_AP_ERR_MODIFIED con gli orologi in sincrono significa SPN duplicato. La risposta «sincronizza il tempo» e’ la risposta di KRB_AP_ERR_SKEW, ed e’ proprio il distrattore che ti mettono davanti.
• Il secure channel non si ripara sempre dal client. Se il dispositivo ha la password piu’ recente di AD, Test-ComputerSecureChannel -Repair prima di aver sistemato la replica e’ una toppa che salta di nuovo.
• Su un domain controller non si usa Test-ComputerSecureChannel, si usa netdom resetpwd con il KDC fermo. E nltest /dsgetdc che fallisce su un DC nuovo di sito e’ un problema di record SRV: riavvia Netlogon, non toccare il trust.