W pierwszej części mogliście zobaczyć w jaki sposób odtworzyć kontroler domeny z backupu (jak stworzyć backup tutaj). Teraz pokażę w jaki sposób przygotować sam kontroler do poprawnego działania.
W pierwszej kolejności należy się zalogować na odzyskany kontroler domeny za pomocą konta Administrator (lub jeśli zmienialiście nazwę to konto posiadające końcówkę SIDa 500)
Aby mieć pewność, że konto na które się zalogowaliśmy jest faktycznie tym SIDem 500, uruchomcie Powershella lub wiersz poleceń i wpiszcie następujące polecenie: whoami /all
Od razu z tego samego polecenia należy zweryfikować, czy wskazane konto należy do grup:
- Domain Admins – jeśli środowisko jest wielodomenowe to także Enterprise Admins
- Schema Admins – według obecnych rekomendacji bezpieczeństwa, grupa powinna być pusta podczas normalnego działania Active Directory. Jeśli konto nie jest członkiem Schema Admins – należy to konto dodać.
Kolejnym krokiem jest weryfikacja i ustawienie adresu IP, takiego jak miał poprzedni kontroler domeny
Po konfiguracji adresu IP należy zweryfikować, czy nazwa domeny jest poprawnie wyświetlana w karcie sieciowej
W przypadku, gdy nazwa domeny nie wyświetla się, zweryfikuj kilka ustawień:
- Zweryfikuj, czy poprawnie jest ustawiony DNS w karcie sieciowej – sprawdź, czy nie ma wpisu wskazującego na localhost (127.0.0.1)
- Wyłącz i ponownie włącz kartę sieciową w systemie
- Poprawnie skonfiguruj bramę sieciową
- Odłącz i podłącz ponownie kartę sieciową z poziomu wirtualizatora, możesz też dodać nową kartę sieciową
Następnie zmień hasło konta Administrator (SID500). Gdy odtwarzanie kontrolera następuje w sytuacji kompromitacji Active Directory. Należy to zrobić bezwzględnie, aby atakujący ponownie nie przejął infrastruktury domenowej.
Kolejnym krokiem jest weryfikacja, czy kontroler udostępnia udziały NETLOGON i SYSVOL.
Teraz uruchom konsole Active Directory Users and Computers (DSA.MSC) i sprawdź, czy struktura jest listowana prawidłowo.
Następnie z menu View należy zaznaczyć poniższe opcje
Jest to niezbędne podczas kolejnego etapu, edycja SYSVOL Subscription, czyli ustanowienie zasobów SYSVOL i NETLOGON w trybie autorytarnym, aby nie zostały w sposób przypadkowy nadpisane. W tym celu należy przejść do lokalizacji Domain Controllers -> Nazwa kontrolera, który właśnie odzyskujemy, u mnie to DC1 -> DFSR-LocalSettings -> Domain System Volume ->właściwości atrybutu SYSVOL Subscription.
We właściwościach SYSVOL Subscription należy zweryfikować, czy atrybut msDFSR-Enabled jest ustawiony na wartość TRUE, oraz zmienić wartość atrybutu msDFSR-Options na 1.
Po tej czynności należy uruchomić ponownie usługę DFSR (DFS Replication). Teraz należy przejść do podglądu zdarzeń (Event Viewer) do gałęzi Applications and Sevices Logs -> DFS Replication i tam odszukać zdarzenie o ID 4602. Oznacza to, że nasz kontroler domeny jest nadrzędnym w replikacji DFSowej.
Kolejnym krokiem jest weryfikacja ról FSMO. Wróćmy zatem to Powershella lub wiersza poleceń i wpiszmy polecenie netdom query fsmo
Wróćmy zatem do konsoli DSA.MSC i przejdźmy do usuwania kontrolerów domeny. W moim labie jest bardzo prosty scenariusz, występują tylko dwa kontrolery domeny, w dodatku role FSMO są wszystkie przechowywane na jednym z nich – tym, którego testuje odtwarzanie. W bardziej rozbudowanych środowiskach usuwanie kontrolerów rozpoczynamy od tych, które nie przechowują ról FSMO. Te z rolami zostawiamy na koniec, w momencie usunięcia rola zostanie przeniesiona na inną maszynę. Można też przenieść role za pomocą Powershell-a przed usunięciem kontrolerów.
Move-ADDirectoryServerOperationMasterRole -Identity “Target_DC_Name” –OperationMasterRole 0,1,2,3,4 -force Gdzie cyfry oznaczają po kolei (można nazwę roli stosować zamiennie z cyfrą):
- 0 – PDCEmulator
- 1 – RIDMaster
- 2 – InfrastructureMaster
- 3 – SchemaMaster
- 4 – DomainNamingMaster
Podczas usuwania kontrolera koniecznie musicie zaznaczyć opcję Delete this Domain Controller anyway…
Kolejny krok to „przekręcenie licznika” RIDManagera. Gdy w sieci było wiele kontrolerów domeny, te mogły przechowywać pulę RIDów o wyższy numerze niż ten odzyskany, a co za tym idzie mogą istnieć obiekty z wyższym RIDem, niż te, które przechowuje obecny kontroler. Aby sytuacji zduplikowania SIDów należy zwiększyć licznik RIDów. Przechodzimy zatem do kontenera System w konsoli DSA.MSC i znajdujemy tam RID Manager$ i wchodzimy w jego właściwości.
W edytorze atrybutów odnajdujemy wartość rIDAvailablePool i zwiększamy tą wartość, np. o 100 000
Po zmianie puli, należy ją „przeładować”, do tego celu należy użyć poniższego skryptu.
$Domain = New-Object System.DirectoryServices.DirectoryEntry
$DomainSid = $Domain.objectSid
$RootDSE = New-Object System.DirectoryServices.DirectoryEntry("LDAP://RootDSE")
$RootDSE.UsePropertyCache = $false
$RootDSE.Put("invalidateRidPool", $DomainSid.Value)
$RootDSE.SetInfo() 
Aby zainicjować nową pulę należy jeszcze utworzyć obiekt, ja utworzyłem nowego użytkownika. Błąd założenia jest oczekiwany. Kolejna próba spowoduje już przeładowanie puli i założenie użytkownika z nowych RIDów
Można to zweryfikować za pomocą polecenia: dcdiag /test:RidManager /v
Kolejnym krokiem, obiecuje to już prawie koniec 🙂 jest 2-krotny reset konta komputera kontrolera domeny, za pomocą polecenia: Reset-ComputerMachinePassword
oraz 2-krotny reset konta krbtgt za pomocą polecenia net user krbtgt DowolneHaslo123 /domain. Tego hasła, które podacie i tak nie trzeba nigdzie zapisywać, kontroler wybierze własne. W tym przypadku mamy tylko jeden kontroler domeny, więc nie ma konieczności oczekiwania na replikację.
Następnie musimy zrestartować hasła na wszystkich relacjach zaufania z innymi domenami:
- W przypadku jednego lasu i jednej domeny – możesz ten krok pominąć 🙂
- Jeden las, wiele domen – reset haseł dla wszystkich subdomen poleceniem netdom
netdom trust krbtgt.pl /domain: child.krbtgt.pl /resetoneside /pT: NoweHasłoDlaRelacji /u0: Administrator /p0:*- Relacja z domenami zewnętrznymi – trzeba taką relację nawiązać ponownie
Przedostatni krok to wyłączenie Global Catalogu. Jest to niezbędne, gdyż obecność GC może powodować, że obiekty w nim mogą być nowsze, niż te przechowywane na kontrolerze domeny. Po utworzeniu nowych kontrolerów domeny już od tego odzyskanego, weryfikacji poprawności replikacji, Global Catalog można ponownie włączyć
Potwierdzenie usunięcia GC znajduje w podglądzie zdarzeń w gałęzi Applications and Services Logs -> Directory Service i zdarzenie o ID 1120
Ostatni punkt to rekonfiguracja synchronizacji czasu NTP. W tym celu należy w rejestrze przejść do klucza HKEY_LOCAL_MACHINE -> SYSTEM -> CurrentControlSet -> Services -> W32Time -> Parameters
Należy wskazać serwer NTP oraz typ synchronizacji. Jako, że to jest jedyny kontroler domeny to należy ustawić opcję NTP. Po zmianie należy ponownie uruchomić usługę W32Time.
Więcej informacji o konfiguracji NTP znajdziecie tutaj
To jest koniec procesu odzyskiwania domeny (oczywiście w przypadku środowiska z jedną domeną w lesie), w przypadku większej ilości należy te kroki powtórzyć dla każdej domeny z osobna. Po tak przeprowadzonej procedurze, można tworzyć już kolejne kontrolery i odbudowywać środowisko Active Directory. Ale pamiętajcie, żeby zbudować taką procedurę dedykowaną dla Waszego środowiska.
