Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > Posts > Kde asi soudruzi z NDR udělali chybu?
červenec 30
Kde asi soudruzi z NDR udělali chybu?

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 :-)

Comments

Re: Kde asi soudruzi z NDR udělali chybu?

... dostal jsem mailem otázku, jakto, že každý člen Domain Admins z libovolné domény je "automaticky" také členem Domain Admins v libovolné jiné doméně stejného forestu.

No ono to není opravdu až tak "automaticky". Myslel jsem to "bezpečnostně automaticky". Tedy pokud ten spodní Domain Admin prostě bude chtít, nic mu nemůže zabránit, aby se stal členem jakékoliv skupiny z libovolné domény stejného forestu.

Důvod? Uvnitř forestu jsou vzájemné vztahy důvěry (mutual trusts), ale není možné na ně aplikovat SID filtering. To lze zapnout jen pro trusty s jinými foresty.

Takže není možné zapnout SID filtering. Libovolný člen Domain Admins si může pro libovolný svůj účet pozměnit jeho sIDHistory atribut. Může si do něho dát úplně cokoliv. Tak proč by si do něho nedal SID nějaké silné skupiny z jiné domény?

A je to.
ondass on 1.8.2012 17:23

Myslis?

Myslim si, ze to nebude take jednoduche, pretoze jediny sposob ako naplnit SID history je pouzit na to API DsAddSidHistory, ktora ma hard-coded kontrolu na to, aby uzivatel, ktory chce zapisat SID history atribut musi byt aj v source aj v destination domenach v skupinach Domain Administrators alebo Administrators. Viac tu http://msdn.microsoft.com/en-us/library/windows/desktop/ms677982(v=vs.85).aspx.

Ci pozname este nejaky iny sposob?
Ondrej Zilinec on 1.8.2012 23:42

Nadej

Tak jedine ma napadla offline editacia databazy v Restore Mode a editovanie. Potom odreplikovanie zmien...po chvilke guglenia som nasiel aj tooly. V piatok ich vyskusam http://www.tbiro.com/projects/SHEdit/index.htm.
Ondrej Zilinec on 1.8.2012 23:51

Re: Kde asi soudruzi z NDR udělali chybu?

jojo, to je přesně tak, právě protože DsAddSidHistory je takhle zdokumentovaná a já sem ještě pořád neměl čas to pořádně prozkoumat, tak sem na to prozatím nezjistil nějaký jednoduchý postup. Je otázka, jestli tu (mimochodem údajnou) kontrolu dělá jen ta API funkce, nebo to dělá serverová část.

Dřív na to existovala přímo utilitka, ale od jisté doby nefunguje.

Ta offline editace databáze je další možnost.

Ale jak říkám, prostě sem na to neměl prozatím čas a není to jednoduše udělatelné "na pár kliků".

Napadají mě další cesty, jak toho dosáhnout, jako například další doména se stejným SIDem. Nebo si vezmu KRBTGT heslo, které mám na svých DCčkách, a vyrobím si Kerberos TGS tiket s libovolným obsahem.

Ale to je vždycky na moc velké testování, které jsem prozatím neměl čas provádět.

Ale o to vůbec nejde. Principiálně, pokud mám v ruce databázi a budu mít skutečně nástroj, jak ji zmodifikovat a korektně ty změny poreplikovat, tak toho dosáhnu. Nejde o to, jestli takový nástroj teď existuje, nebo jestli jsem to schopen naklikat v řádu několika minut. Ale prostě to principiálně jde.
ondass on 2.8.2012 8:19

Tesime

Tak sa tesime ked sa s tvojou buducou utilitkou s nami podelis :-)
Ondrej Zilinec on 2.8.2012 8:30

Re: Kde asi soudruzi z NDR udělali chybu?

a čo tak delegácia práv Migrate SID History na akýkoľvek doménový účet?
runco on 29.8.2012 21:49

Add Comment

Title


Pole Title nemusíte vyplňovat, doplní se to samo na stejnou hodnotu jako je nadpis článku.

Author *


Pole Author nesmí být stejné jako pole Title! Mám to tu jako ochranu proti spamu. Roboti to nevyplní dobře :-)

Body *


Type number two as digit *


Semhle vyplňte číslici dvě. Předchozí antispemové pole nefunguje úplně dokonale, zdá se, že jsou i spamery, které pochopily, že je občas potřeba vyplnit autora :-)

Email


Emailová adresa, pokud na ni chcete ode mě dostat odpověď. Nikdo jiný než já vaši emailovou adresu neuvidí.

Attachments