Replikační problém s Active Directory jsou docela běžnou součástí života mnoha adminů. Vždycky říkám, že s Active Directory je sranda bez ohledu na "velikost". Můžete mít dvě DC (domain controller) a dvacet uživatelů, můžete mít čtyři DC a 30 000 uživatelů, nebo 800 DC a 600 uživatelů, můžete mít jednu pobočku, nebo stovky. A vždycky se můžete bavit hodiny :-)
Dneska si užijeme informace o DCčkách, která byla dlouho vypnutá. Ale NEjmenuje se to tombstone lifetime. Stačí 30 dnů a juchů, je tu konec replikace!
Tři zásadní replikační problémy
Existují tři zásadní replikační problémy, které mohou vzniknout i v prostředí s dobře nastavenou replikační topologií a s vůbec dobře fungující infrastrukturou. O jednom se ví docela dobře, o druhém méně, ale o třetím vůbec. A to bych rád změnil. Takže jaké jsou ty problémy?
- Autentizační problémy po delší době odpojení - tohle je to, co se moc neví. Takže detaily dále.
- Lingering objects a tombstone lifetime - to je naopak asi to nejznámější. Pokud se dvě DC dělší dobu nereplikují a potom se o to pokusí, replikace se zablokuje. Výraz "delší dobu" znamená tombstone lifetime. To je hodnota definovaná v Configuration oddílu Active Directory. Ve výchozím stavu je to buď 60, nebo 180 dní, podle verze prvního DC, které jste kdy vůbec nainstalovali. Jedná se čistě o "technický" problém, který je možno bez problémů vyřešit a uvést vše zase do funkčního stavu bez ztráty kytičky. Tuto situaci poznáte podle událostí:
Event Log: Directory Service
Event ID: 2042
Event Source: ActiveDirectory_DomainServices (NTDS Replication)
Task Category: Replication
Event Level/Type: Error
Message: It has been too long since this machine last replicated with the named
source machine. The time between replications with this source has exceeded
the tombstone lifetime. Replication has been stopped with this source.
The reason that replication is not allowed to continue is that the two DCs
may contain lingering objects. The source machine may still have copies
of objects that have been deleted (and garbage collected) on this machine.
- USN rollback - je dnes už poměrně známější záležitost. Tohle vznikne, když obnovíte DCčko ze snapshotu. Nedělejte to, protože dojde k nedefinovatelné destrukci a nekonzistentnosti onoho drahoceného distribuovaného ekosystému, pro kterou neexistuje jednoznačná opravná cesta, kromě reinstalace forestu :-) Tuhle situaci je někdy (zdůrazňuji, že ne vždy) možno poznat díky události:
Event Log: Directory Service
Event Source: ActiveDirectory_DomainServices
Task Category: Replication
Event Level/Type: Error
Event ID: 2095
Message: During an Active Directory replication request, the local domain
controller (DC) identified a remote DC which has received replication
data from the local DC using already-acknowledged USN tracking numbers.
Because the remote DC believes it is has a more up-to-date Active
Directory database than the local DC, the remote DC will not apply future
changes to its copy of the Active Directory database or replicate them to its
direct and transitive replication partners that originate from this local DC.
User Actions: If this situation occurred because of an improper or unintended
restore, forcibly demote the DC.
Event ID: 2103
Message: The Active Directory Domain Services database has been restored
using an unsupported restoration procedure. Active Directory will
be unable to log on users while this condition persists. As a result,
the Net Logon service has paused.
Event ID: 1115, 1113
Message: Inbound/Outbound replication has been disabled by the user
Takže jestli nějakou z těchto událostí máte v logu, tak se pomodlete a vypravte se na DCPROMO /forceremoval :-) My ostatní se budeme dále věnovat těm DC, která byla delší dobu vypnutá. Nebo možná jen bez replikace se zbytkem - například jezdila někde na lodi, nebo byla v odpojené pobočce, nebo si někdo hrál s firewallem a nedopadlo to úplně dobře :-)
Jak dlouho může být DC vypnuté?
Člověk by řekl, že je to stejné jako tombstone lifetime. Ale ono není :-) Jisté problémy můžete mít už po delší době nečinnosti než 8 dnů, nebo i řekněmě "izolovanosti" za jízdy. Ale tohle se obvykle samo opraví poměrně rychle, nebo se to vůbec neprojeví, takže žádné zásahy dělat nejspíš nemusíte.
Horší to je po 30, nebo dokonce po 60 dnech. Po 30 dnech, kdy vaše jedno, nebo více DC, bylo vypnutých (případně separovaných bez replikace se zbytkem), se může stát, že se už replikovat znovu nebude. Po 60 dnech máte víceméně jistotu :-) Proč?
To je tím, že každý doménový počítač, a tím pádem tedy i každé DC, má svůj počítačový účet. Každý počítač zná pro svůj účet také heslo. Heslo má uloženo ve registrech a v Active Directory je uložena jeho hash. Každý DC má svůj vlastní účet, každý má tedy vlastní (jiné) heslo. Každý počítač i DC si svoje heslo sám mění, jakmile je starší než 30 dnů. Tenhle interval řídí politika:
Computer Settings/Windows Settings/Security Settings/Local Policies/Security Options
Domain Member: Maximum machine account password age : 30
Každý počítač si pamatuje svoje aktuální a jedno předchozí heslo pro případ, že by ho ještě někdo potřeboval použít. Představte si tedy, že znáte heslo nějakého počítače. Po 30 dnech je už jisté, že se alespoň jednou změnilo. Ono je ale také možné, že se změnilo už dvakrát. Po 60 dnech ale máte jistotu. Mluvíme tu samozřejmě o situaci, kdy ten počítač celou dobu běží. Počítače si heslo mění sami, tzn. musí v tom okamžiku běžet. Při nejhorším si heslo změní hned, jakmile se později nastartují.
Problém s replikací v tomto případě je, že DC musí použít kamarádovo heslo, pokud si od něho chce něco stáhnout - musí se ověřit pomocí Kerberosu a ten potřebuje počítačové heslo cílového stroje. Jestliže neznám heslo druhého DCčka, nic si nestáhnu. Pokud si ho to cizí DC změnilo jen jednou, můžu ještě pořád použít to předchozí heslo. Pokud si ho ale změnilo už dvakrát, máte smůlu a nepřipojíte se. Úvodní situaci demonstruje následující obrázek:
V obrázku byste měli vidět, že DC2 a DC3 mají v regisrech teprve svoje první heslo, 2-1 respektive 3-1. Jejich kamarád DC1 má tato "hesla" uložena ve své Active Directory databázi. Pokud se tedy DC1 snaží stáhnout si repliku z kamarádů DC2 a DC3, prostě použije to heslo, které má ve svém AD. Následuje ovšem vypnutí DC1 (nebo ho prostě odpojíte od sítě, nemusíte ho vypínat).
Po uplynutí jednoho měsíce si kamarádi DC2 a DC3 změní hesla. Mají tedy v registrech heslo 2-2, respektive 3-2, ale mají tam i předchozí verzi hesel 2-1 a 3-1. Kdybychom teď zapnuli DC1, jelo by to ještě v pohodě. Jenže ono zůstane vypnuté ještě dále až do okamžiku, kdy si DC2 i DC3 znovu změní heslo:
V předchozím obrázku si všimněte, že vypnuté DC1 má ve své databázi zapamatována hesla verze 1, tedy 2-1 a 3-1. Problém je, že o tomto heslu už ani DC2 ani DC3 nic nevědí, protože si je kluci mezitím už 2x změnili. A teď přijde opětovné probuzení DC1.
Sotva se DC1 probudí (nebo připojí do sítě), pokusí se replikovat s jedním z kamarádů. Musí se proti nim ověřit, ale k tomu použije heslo, které má uložené ve své vlastní databázi. Použije tedy buď heslo 2-1 vůči DC2, nebo 3-1 vůči DC3. Jenže DC2 ani DC3 už o tomhle přestárlém hesle nic nevědí a připojení odmítnou. A replikace nefunguje. Projeví se to na DC1 následující chybovou hláškou:
Event Log: System
Event Source: Security-Kerberos
Event Level/Type: Error
Event ID: 4
Message: The kerberos client received a KRB_AP_ERR_MODIFIED error
from the server. The target name used was host/myserver.domain.com.
This indicates that the password used to encrypt the kerberos
service ticket is different than that on the target server or
that the target server failed to decrypt the ticket provided
by the client.
Případně se replikace nezdaří s následující chybou:
REPADMIN /replsummary
Error 2148074274: The target principal name is incorrect
The Active Directory Domain Services could not notify the directoy service
at the following network address about changes to the directory partition.
The Active Directory Domain Services could not synchronize the following
directory partition with the directory service at the following network address.
If this error continues, the Knowledge Consistency Checker (KCC) will reconfigure
the replication links and bypass the directory service.
The Knowledge Consistency Checker (KCC) has detected that successive attempts to
replicate with the following directory service has consistently failed.
A je to :-) Replikace v opačném směru funguje. Tedy pouze v případě, že DC1 bylo celou dobu vypnuté. Pokud vypnuté nebylo, i DC1 si samo sobě měnilo svoje heslo. Také to provedlo dvakrát a také už je to heslo jiné, než jaké si pamatují jeho kamarádi DC2 a DC3 :-). V období 30-60 dnů se tahle situace stát nemusí, nebo se může stát, že se sama opraví. Může se opravit sama, protože nějaké jiné DC si možná ještě svoje heslo dvakrát nezměnilo. KCC běžící na DC1 se normálně samo pokouší najít někoho, s kým by si poreplikovat mohlo, takže až narazí na to "ještě zdravé" DC, nakonec se to celé zreplikuje a vrátí se to do původního stavu.
Jak to vyřešit?
Jediný problém, který vlastně máte, je fakt, že se DC1 snaží ověřovat pomocí hesel, která má uložená u sebe. Tak ho musíte přinutit, aby použilo hesla, která mají ti dva kamarádi DC2 a DC3 ve svých AD databázích. Toho dosáhnete jednoduše tak, že prostě u sebe na DC1 zakážete (disable) službu Kerberos Key Distribution Center (KDC). Musíte ji zakázat (nestačí jen zastavit) a restartovat DC1.
Když u vás nepoběží služba Kerberos Key Distribution Center (KDC), kvůli Kerberos ověření se budete muset připojit někam jinam. A tam jsou přece hesla v pohodě aktualizována. Dostanete tedy už správné TGS tikety (ticket granting service) a můžete si stáhnout repliku. Jakmile si repliku stáhnete, už budete mít i vy v Active Directory správné verze hesel a můžete tu službu znovu povolit, znovu restartovat a fičíme! Viz. obrázek:
No moment. Tohle platilo pro dlouhodobě vypnuté DC1. V případě, že bylo jen odpojené od sítě a přitom běželo, musíte ještě udělat jeden krok. V tomhle případě si totiž i DC1 samo sobě měnilo heslo. Toto jeho heslo kamarádi také neznají, stejně jako DC1 nezná hesla kamarádů. V tomhle případě by se tedy ani po vypnutí služby KDC na DC1 nic nězměnilo, protože DC1 by si ani tak nemohlo u kamarádů vydat TGS.
V případě, že vám tedy DC1 běželo, musíte ještě jeho heslo ručně vyresetovat. To se provede takto:
NETDOM RESETPWD /Server:DC2 /UserD:administraotr /PasswordD:
V parametru /Server se uvede jméno nějakého kamarádského DCčka (pro nás DC2, nebo DC3). Parametry /UserD a /PasswordD jsou údaje nějakého doménového administrátora (člena Domain Admins) - všimněte si písmene D v těchto parametrech, znamená to asi d-omain.
Takže rekapitulace
Když máte DC dlouho vypnuté, nebo sice zapntué a jen bez možnosti replikace s kamarády, možná už to replikovat nebude. Okej, stačí provést dva jednoduché kroky a je to zachráněno:
- vypnout a zakázat službu Kerberos Key Distribution Center (KDC)
- NETDOM RESETPWD
- restartovat a zkusit provést replikaci
- pokud replikace uspěje, znovu povolit službu KDC do režimu Automatic