Mimochodem, všechno se dozvíte osobně na kurzu GOC171 - Active Directory Troubleshooting, který přednáším v GOPASu!
Byla tady otázka ohledně problémů s obnovou RID manager FSMO. O RID manageru jsem tu už psal tady a tady a tady a vlastně i tady. Ale nevysvětloval jsem tenhle problém, tak tu to je. To stejné bude nastávat, pokud byste nesprávně provedli operaci seize této role, nebo pokud obnovíte virtualizační snapshot (tedy pokud se to náhodou nepovede dobře pomocí GenerationId).
Obecně by se dali FSMO role rozdělit na dvě skupiny, podle toho, jestli jsou "stavové", nebo "nestavové". Pod pojmeme stavový myslím, že má nějaká data, která si sám výlučně spravuje. Tím myslím to, ře třeba schema master FSMO má stav, protože má data ve schema partition, kam může zapisovat jen on.
Stavové FSMO jsou:
- schema master - ten má svoji schema partition (CN=Schema,CN=Configuration), do které jen on může dělat změny. Když tam ty změny udělá, výsledek se už normálně doreplikuje do ostatních řadičů domény (DC), ale tu změnu (originating update) může udělat jen schema FSMO.
- domain naming master - tenhle má svůj kontejner CN=Partitions,CN=Configuration, do kterého si opět jen on může výlučně zapisovat. Změny se opět v pohodě poreplikují.
- RID master - tady je to trošinku složitější, protože tenhle kamarád má svůj vlastní objekt CN=RID Manager$,CN=System, do kterého si zapisuje volný rozsah RIDů, které ještě žádnému DC nedal (atribut rIDAvailablePool). To je jeho vlastní objekt. Jenže s tím souvisí ještě objekty CN=RID Set, které najdete pod každým objektem DC. Tady si každé DC samo zapisuje, z jakého RID rozsahu zrovna přiděluje RIDy - atributy rIDAllocationPool, rIDPreviousAllocationPool a rIDNextRID. Detaily dále.
Nestavové FSMO a zvláštnosti jsou:
- PDC master - tohle jenom procesuje změny hesla a zamykání účtů a změny hesel na trustech, je to taky časová autorita (možná to tak nemáte nastaveno) a provádí AdminSDHolder apod. Ani jedno z toho nepotřeuje nikde nic ukládat. Prostě se jenom na základě nějakých ponoukání spouští a něco provádí. Takže si nic nepamatuje.
- Infrastructure master - tenhle taky jenom periodicky něco provádí nad celým svým databázovým kontextem a taky si tedy nemusí nic pamatovat. Navíc, pokud máte na všech DC zapnuty GC (global catalogue), nebo pokud máte zapnut Recycle Bin, tak tuhle roli stejně už ani nemáte.
- Intersite topology generator (ISTG) - no sice to není úplně přesně řečené FSMO, ale taky je to role, kterou má jen jedno DC. V tomto případě jedno DC v každé AD sajtě. Zase nemá žádnou konfiguraci. Tedy má ji ve formě inter-site connection objektů, ale pokud to bude jakkoliv divně, tak si to stejně ISTG sám přegeneruje podle aktuální potřeby.
Obnova a operace seize může mít vliv jen v případě stavových FSMO. Nestavové lze obnovovat a přehazovat v podstatě bez ztráty kytičky. To nejhorší co se může stát, že ta role bude současně na dvou (a více) kamarádech. Prostě ty jejich akce nebudou dočasně chodit tak hladce, jak by bylo žádoucí.
Obnova řadiče jakéhokoliv řadiče domény (DC)
Představte si, že děláte prostě obnovu databáze o nějakou dobu zpět. Takže po obnově v ní něco nebude. Ukažme si to nejprve na příkladu třeba naming FSMO.
Obnova domain naming FSMO master
Domain naming FSMO obhospodařuje kontejner CN=Partitions,CN=Configuration. Kdykoliv chcete přidat další doménu, nebo application partition, tak musí tuto změnu provést nejprve domain naming master a z něho se ta změna taky nejprve musí pořádne poreplikovat, než to bude celkově fungovat.
Další doménu přidáváte jak často? Aplikační oddíly jsou potřeba pro DNS. Takže pokud přidáváte do nové domény na DC první DNS server, zase to musí udělat naming FSMO. A dělá to navíc nějaký člen Enterprise Admins. Takže to je vlastně jen málo častá, téměř vždycky ručně řízená operace - což pro nás znamená, že jsme schopni to hned potom zazálohovat, mimochodem.
Dobře. Co se může stát, pokud se vám domain naming master zhroutí chvilinku po provedení té přidávací akce? Jsou přesně jen dvě možnosti, ne? AD modifikace i replikace jsou transakční:
- změny, které jste na naming FSMO právě provedli, se prozatím nikam nezkopírovaly (nezreplikovaly). Takže jste o tuto celou operaci komplet přišli. Řešení je na snadě - buď obnovíte starou zálohu vašeho naming FSMO a prostě to provedete znovu (tohle máte vždy pod kontrolou, je to ruční akce, ty instalace domén). Nebo se na něho úplně vykašlete a seizenete ho natvrdo někam jinam. A provedete to znovu.
- změny, které jste na naming FSMO právě provedli, se už potvory stihly poreplikovat alespoň na nějakého dalšího kamaráda DC. Pohoda ne? Obvnovíte starou databázi, nebo to někam prostě jenom seizenete, ne? Bacha!
Co musíte udělat, pokud se to stihlo poreplikovat (tedy vždycky)
Bacha, pokud se to stihlo někam repliknout, nemůžete jenom tak obnovit zastaralou databázi na naming FSMO. Nemůžete ani jen tak někam seizenout naming FSMO. Stará databáze ze zálohy neví, že ta doména už existuje a mohlo by se stát, že hned po obnově proběhne znovu ta stejná operace a vznikne neřešitelná kolize.
Stejná situace je pokud byste jen tak někam seizeovali naming FSMO. Pokud ten nový master nemá ještě komplet repliku od všech! kamarádů, tak nemáte jistotu, že ví o všech existujících oddílech. A mohl by zase náhodou schválit nové přidání, i když by bylo kolizní.
Takže co musíte udělat když tam zrovna žádného daného FSMO nemáte? Před obnovou, nebo před operací seize všech masterů musíte poreplikovat celý obor - tzn. forest, případně doménu, pokud se jedná o RID managera. Výsledek před-replikace zjistíte jednoduše pomocí REPADMIN /REPLSUMMARY. Musíte tam prostě mít jen malinké časové rozdíly na všech DC.
Jenže pro RID master jen ta replikace nestačí
Tady je to horší. Máte například DC1, DC2, DC3 a DC4. Řekněme, že DC1 je RID master. Řekněme, že DC2 je vypnuté. Na DC3 se nějaký admin snaží vytvořit skupinu, nebo třeba uživatele, nebo připojit počítač do domény. Takže velmi častá operace, špatně kontrolovatelná a prováděná mnohdy totálně distribuovaně.
A DC3 nemá volný SID. Co se bude dít?
DC3 řekne DC1 RID o nový rozsah RIDů a dostane ho. RID master na DC1 si to zapíše do svého objektu RID Manager$. Příjemce rozsahu, DC3, si uloží do svého objektu (tedy do jiného objektu) RID Set hodnotu tohoto svého nového rozsahu. A za třetí, DC3 vytvoří nový bezpečnostní objekt s novým SID z tohoto rozsahu.
Ani jednou jsem neřekl slovo replikace. Protože k tomuhle žádná replikace není zapotřebí. Prostě jedna věc se stane na DC1, zatímco DC3 pracuje na jiných dvou objektech.
A teď vám spadne RID manager, tedy DC1. A vy ho chcete obnovit nebo seizenout.
I kdybyste replikovali jak zběsilí, tak jediné co poreplikujete je objekt RID Set z DC3, ve kterém je ten nejnovější rozsah, to ano. Taky zreplikujete ten nový bezpečnostní objekt s jeho novým SID. Jenže tohle RID managera vůbec nezajímá. RID manager se zajímá pouze a výhradně a exkluzivně o svůj objekt RID Manager$.
Problém je, že když ho vrátíte zpět, nebo provedete seize kamkoliv jinam, nemáte zaručeno, že tam bude aktuální RID Manager$ objekt. A to je ono.
Správné řešení obnovy a operace seize všech FSMO kromě RID manager
Prostě nejprve poreplikujte celý forest a potom to teprve obnovte, nebo proveďte seize.
Správné řešení obnovy a operace seize pro RID manager
Ano, samozřejmě proveď nejprve replikaci všeho, ideálně v celém forestu, a zkontrolujte to pomocí repadmin /replsummary.
A potom se zařiďte, aby nemohly vznikat žádné nové bezpečnostní objekty!!! Takže všem zakažte, aby cokoliv dělali, nebo si nechte běžet jenom jedno DC z dané domény a odpojte ho od sítě.
A podívejte se do všech objektů (opakuju pro všechna DC) RID Set a najděte tam ten největší rozsah (rIDAllocationPool). A potom opravte hodnotu v RID Manager$ (rIDAvailablePool, to je jiný atribut) tak, aby tam bylo cokoliv většího, než jste zjistili, ze všech těch DC objektů a jejich RID Setů.
MS lišácky doporučuje, abyste tam dali hodnotu o 100 000 vyšší. To je blbost. Tohle nic, ale vůbec nic nezaručuje. V krajním případě se těch 100 000 dá přečerpat pomocí sedmi DC, kterým zrovna náhodou došly RIDy.
Musíte udělat audit a dát tam hodnotu vyšší, než cokoliv v provozu.