Včera v noci jsem vyřešil pěknou zajímavost a protože si při té příležitosti můžu rýpnout do soudruhů AD specialistů z Německa, tak to rovnou udělám :-)
Takže specialisti se rozhodli, že provedou konsolidaci jednotlivých národních domén do jednoho forestu. Takže vytvořili forest s jednou root doménou a 31 národními subdoménami. Správci v jednotlivých zemích jsou členem Domain Admins ve své doméně. Každá země dostala nějaká svoje DCčka, která připravovali němci.
Dyzajn celkem v pohodě, jen bych k tomu rád poznamenal, že bezpečnost to nevyřešilo. Forest je security boundary. To znamená, že v principu každý člen skupiny Domain Admins z libovolné subdomény je také adminem libovolné jiné subdomény i forest root domény. Proč? No protože uvnitř forestu neexistuje SID filtering. Každý správce domény se tedy může v pohodě stát správcem libovolné jiné domény daného forestu.
Takže jestli bylo cílem ty domény bezpečnostně oddělit, tak to se jim nepovedlo. Pokud to cílem nebylo, nemám problém.
Teď ovšem ke skutečným chybám
Borci dali do každé země nějaká DC, ale zapomněli jim zapnout GC (global catalogue). Přitom round-trip-time (RTT) do centrály na nějaký GC je 15-30ms, což je vcelku dost na to, aby to dokázalo přibrzdit vyhledávání. Jenže pokud navíc nemáte GC ve své sajtě, tak používáte libovolné jiné GC z libovolné, jakkoliv vzdálené sajty. Dalo by se to upravit pomocí Try next closest site, ale to tam zapnuté nemají.
Když máte třeba u sebe SharePoint, přidáváte uživatele přes takový ten user picker (picker.aspx), tak vyhledávání bude trvat pár desítek sekund, někdy jen několik sekund - čistě podle toho, jestli se server zrovna nabootoval levou nohou.
Ano, někdy není rozumné zapínat GC úplně všude, protože by to mohlo hodně zvětšit objem NTDS.DIT databáze. No v jejich případě má AD i s GC cca 650 MB, takže kde je problém?
Druhý problém byl překlad jmen. Uděli si nějaké forest trusty (forestový vztah důvěry). Takže tím přinutili každou subdoménu, aby věřila nějakému dalšímu forestu. To je ok. Akorát zapomněli, že ty subdomény taky musí být schopny přeložit DNS SRV záznamy z toho cizího forestu.
Efekt na SharePoint byl celkem zajímavý. Když jste chtěli piknout nějakého človíčka, tak to trvalo 9 sekund. Tak lidem je celkem jedno, prostě si počkají, ale když máte naimportovat pár milionů dokumentů, tak bude trvat pěěěěkně dlouuuuho :-)
SharePoint totiž prohledává všechny GC, se kterými má jeho vlastní doména trust. Naše subdoména neuměla tu cizí doménu přeložit pomocí DNS. Čím tedy SharePoint logicky pokračoval? Použil NetBIOS broadcast a prostě si počkal 9 sekund, než to vypršelo bez odpovědi.
Poučky
Když dělám trust, zařídím, aby to každá doména z celého forestu byla schopna přes DNS přeložit.
Všude vypínám NetBIOS, protože to je největší zlo světa :-)