Protecting AD – Tombstone objects
In articolul precedent am vazut cum putem recupera anumite date care au fost sterse accidental din Active Directory, folosind informatiile dintr-un snapshot. Insa ce facem daca trebuie sa recuperam un obiect intreg (user account). Il putem recreea bineinteles, insa dupa cum stim nu o sa fie acelasi obiect deoarece va avea alt SID (Security Identifier).
Manualul spune ca in acest caz ar trebui sa apelam la un backup – insa un restore din backup inseamna ca trebuie sa restartam un domain controller (de 2 ori) plus ca dureaza ceva toata operatiunea.
Hai sa vedem acum la ce se refera termenul din titlu – Tombstoned objects. Pai tine de un anumit mecanism pe baza caruia functioneaza procesul de replicare si stergere a obiectelor in AD. In clipa in care stergem un obiect, sa spunem un user, obiectul nu este sters, ci atributul isDeleted este setat pe True iar obiectul este mutat intr-un container special numit Deleted Objects. In afara de asta, anumite atribute ale obiectului sunt sterse (fara posibilitatea de a fi recuperate). In aceasta clipa obiectul este invizibil pentru administrator, insa nu si pentru mecanismul de replicare, care il va replica si pe restul domain controller-elor pentru a se asigura ca este sters si pe celelalte servere.
Timpul in care obiectul ramane in aceasta stare poate varia – 60 de zile in forest-urile promovate de la Windows 2000 sau 180 de zile pentru cele care au inceput cu Windows 2003 SP1 (bineinteles ca poate fi modificat). Fiecare DC din domeniu scaneaza aceste inregistrari la un interval de 12 ore si le sterge pe cele care sunt mai vechi decat intervalul specificat.
Nota: Informatiile din articol se refera la modul de functionare al forest-urilor Active Directory care ruleaza in modul Windows 2000 pana la Windows 2008. Incepand cu R2 lucrurile se schimba (exista Recycle Bin).
Acum ca am inteles la ce se refera termenul de tombstoned objects, hai sa vedem si cum putem reanima aceste obiecte. In multe cazuri e mai simplu sa le reanimam decat sa le readucem din backup.
O varianta ar fi cu LDP (il gasiti in support tools) – sincer mi se pare cam peste mana; gasiti pe net cum se face.
Alta varianta ar fi sa o faceti programatic din C++, C#, VB – setand atributul isDeleted pe false si mutand obiectul in containerul de unde a fost sters (ne folosim de atributul lastKnownParent). Pe vremea cand nu existau tool-uri GUI pentru asa ceva tin minte ca imi facusem propriul utilitar care imi cauta aceste obiecte si imi dadea posibilitatea sa le recuperez.
Dar acum exista tool-uri suficiente pentru a uita cele doua variante descrise mai sus. Un exemplu foarte bun este ADRestore.Net care mi-a functionat si pe W2K3 si pe W2K8 (inclusiv versiunea x64).
Un alt tool cunoscut dar numai command line ar fi cel de la Sysinternals pe care il gasiti aici.
Si mai sunt multe, inclusiv PowerPack-urile de la PowerGUI insa atentie ca au ceva dependinte in spate (cmdlet-uri third party) si am avut si supriza sa nu imi ruleze pe W2K8 x64; pe 2003 nu am avut nici o problema.
Sa revenim putin si sa ne aducem aminte ce am spus la inceputul articolului: anumite atribute ale obiectului sunt sterse (fara posibilitatea de a fi recuperate). Dupa “recuperare” o sa avem acelasi obiect (acelsi SID) insa multe din informatiile asociate cu acest obiect s-au evaporat. Le puteam adauga manual folosind informatii dintr-un snapshot (vezi AD Explorer).
In majoritatea cazurilor folosim aceasta metoda pentru a recupera obiecte de tip user account. In cazul unui user sters si recuperat prin aceasta metoda, problema apare atunci cand observam ca userul nu mai face parte din nici un grup. Asta pentru ca dupa cum am spus mai sus – unele atribute sunt sterse fara posibilitatea de a fi recuperate. La fel, ne folosim de AD Explorer pentru a vedea group membership-ul user-ului ca sa il adaugam in grupurile din care a facut parte inainte.
PS: Backup is still Backup. Don’t forget about it.