Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > Posts > Remíza v soutěži o SIDy řadičů domény
září 25
Remíza v soutěži o SIDy řadičů domény

Dneska se trošku pověnujme problému zvanému SID. Speciálně bych rád konečně vyřešil spor, který vedu s kámošem ohledně tzv. SIDů řadičů domény.

Co je SID

Zkratka SID znamená security ID. Je to číselná unikátní (pokud možno) identifikace nějakého bezpečnostního objektu ve Windows. Třeba uživatele, skupiny, počítače, nebo celé domény.

SIDy jsou ve formátu: S-...-...-...

Například SID mého uživatele (zjištěno příkazem whoami /all), pod kterým běží tenhle html editor je S-1-5-21-3152914998-936455129-3222468019-1001. SIDy mohou být i kratší, například skupina BUILTIN\Administrators je na všech počítačích s číslem S-1-5-32-544, nebo NT AUTHORITY\Authenticated Users je ještě kratší S-1-5-11 a Everyone je dokonce S-1-1-0.

Ovšem SIDy účtů a skupin, ať už lokálních, nebo doménových, které vytváříte ručně, budou vždy začínat S-1-5-21-. Dál následují tři dlouhá čísla, která jsou stejná pro celou "doménu" a pak už jen koncovka nazvaná RID - relative ID. Takže něco jako

S-1-5-21-domain-domain-domain-RID

RIDy na konci se generují postupně od 1001 a každý další účet dostává o jedničku vyšší RID. Takže je zajištěna unikátnost v rámci jedné domény - databáze. Doména má taky svůj SID, tedy vlastně SID stejný, jen bez koncovky.

Na doménových účtech se můžete podívat na jejich SIDy i SID domény v jejich vlastnostech, na záložce Attribute Editor, kde se to projevuje v atributu objectSID.

Co to je to slovo doména

Pořád tu operuji s takovým slovíčkem doména (domain). Co to ale je přesně? Doména znamená databáze uživatelských účtů. Takovou lokální databázi, tedy lokální doménu, má každý počítač, ať je to stanice, server, nebo řadič domény (domain controller). Lokální databázi účtů se říká SAM databáze (Security Accounts Manager).

Tahle lokální doména (databáze) je uložena v registrech v klíči HKEY_LOCAL_MACHINE\SAM. Když se instaluje počítač, nebo když provedete SYSPREP, nebo když se nainstaluje DC, tak se tahle databáze buď znovu vytvoří, nebo se v ní alespoň opraví její SID. Každopádně tahle databáze dostane nový, náhodně vygenerovaný SID bez RID koncovky.

Když v téhle databázi potom vytváříte uživatele a skupiny, každý takový nový objekt dostane prostě jen koncovku RID a celá přední část se použije z čísla té lokální databáze.

Pokud máte na počítači LDAP databázi nazvanou Active Directory - a tím myslím jinou databázi, než tu předchozí lokální v registrech - tak při jejím vzniku se opět vygeneruje nějaký SID. Pokud se potom v téhle databázi vytváří účty, opět se generují jen RID koncovky (to dělá FSMO zvané RID Manager) a je to prostě opět to stejné.

LDAP databáze zvaná obchodně Active Directory ukládá svoje databázová data na disku do databázového souboru, obvykle %WINDIR%\NTDS\NTDS.DIT. Poznámka - SID identifikaci má jen její jedna část nazvaná domain partition.

Na stejném počítači můžete mít dále nainstalováno libovolné množství dalších LDAP databází. Takovou LDAP doménovou službu nabízí třeba AD LDS (Lightweight Directory Services, dříve se to nazývalo ADAM - AD Application Mode). I tyto domény mají svůj, obvykle náhodně, vygenerovaný doménový SID a svým objektům jsou schopny generovat RIDové koncovky.

Replikace LDAP domén

LDAP databáze se mohou replikovat. To znamená, že stejná databáze může být umístěna a přístupna na více než jednom serveru. Když do jedné uděláte změnu, tak se to zkopíruje na ostatní servery. Na každém z těchto serverů je tedy stejná databáze, v níž je uložen stejný doménový SID. Pokud jeden z těch serverů vytváří nový bezpečnostní objekt, prostě mu dá jen nový RID. Nějak se musí zajistit unikátnost takto vzniknuvších RIDů, ale to je jiná pohádka.

SIDy řadičů domény - tedy databází, které jsou na těchto řadičích

Řadiče domény - domain controller - DC - jsou servery, který obsahují LDAP databázi nazvanou Active Directory. Každý z nich tedy obsahuje minimálně dvě domény. Lokální registrovou databázi účtů a tu LDAP databázi.

Každý řadič domény má jiný SID té své lokální databáze účtů, zatímco všechny mají stejnou LDAP databázi, takže na každém z nich má ta LDAP databáze stejný SID. Pro příklad tří řadičů domény:

Lokální SAM databáze DC1 S-1-5-21-radic1-radic1-radic1
Lokální SAM databáze DC2 S-1-5-21-radic2-radic2-radic2
Lokální SAM databáze DC3 S-1-5-21-radic3-radic3-radic3
LDAP databáze Active Directory na DC1, DC2 i DC3 S-1-5-21-domenaAD-domenaAD-domenaAD

Doménovým účtům každý rozumí. Na co je tam ale ta lokální SAM databáze? Určitě jste slyšeli o DSRM (Directory Services Restore Mode) administrátorovi. DSRM nastane, pokud vypnete LDAP službu Active Directory Domain Services (NTDS), nebo nastartujete pomocí F8 do Directory Services Restore Mode. V takovém stavu je LDAP vypnut a řadič domény má už jen svou lokální SAM doménu.

Jediný účet, který takto můžete použít je potom tzv. DSRM Administrator. Prostě normální uživatel Administrator, který je vytvořený uvnitř oné lokální regisrové SAM domény. Na DSRM administrator účet se můžete přihlásit ale i za běhu Active Directory. Stačí do registrů přidat následující hodnotu a normálně se příhlásit explictině například DC2\Administrator.

HKLM\System\CurrentControlSet\Control\Lsa
DsrmAdminLogonBehavior = 2

Z toho plyne, že každé DC provozuje současně alespoň dvě různé bezpečnostní databáze (domény), jejichž účty se dají současně použít. Klidně si zkuste z příkazové řádky podívat pomocí WHOAMI /ALL na svůj aktuální SID doménového administrátora, někam si to uložte a zkuste se přihlásit na DSRM admina na různých řadičích a zdokumentujte si to:

Lokální DSRM admin DC1 S-1-5-21-radic1-radic1-radic1-500
Lokální DSRM admin DC2 S-1-5-21-radic2-radic2-radic2-500
Lokální DSRM admin DC3 S-1-5-21-radic3-radic3-radic3-500
Doménový administrátor LDAP databáze Active Directory na DC1, DC2 i DC3 S-1-5-21-domenaAD-domenaAD-domenaAD-500

Takže čemu se vlastně říká SID řadiče domény? No není to ještě všechno, co jsem k tomu chtěl říct

SIDy účtů řadičů domény

Každý počítač, a tedy i sám každý řadič domény, má v Active Directory LDAP databázi svůj počítačový účet. Je to normální účet, takže to má taky svůj vlastní SID. Tedy SID složený ze SIDu této LDAP databáze plus nějaký RID. RIDy se přidělují v pořadí podle vytváření objektů, takže to mohou být prostě nějaká čísla, podle okamžiku, kdy byl účet daného počítače, nebo DC vytvořen.

Tabulka se tedy rozrostla o SIDy účtů jednotlivých řadičů, například:

Lokální DSRM admin DC1 S-1-5-21-radic1-radic1-radic1-500
Lokální DSRM admin DC2 S-1-5-21-radic2-radic2-radic2-500
Lokální DSRM admin DC3 S-1-5-21-radic3-radic3-radic3-500
Doménový administrátor LDAP databáze Active Directory na DC1, DC2 i DC3 S-1-5-21-domenaAD-domenaAD-domenaAD-500
Účet počítače DC1 v Active Directory S-1-5-21-domenaAD-domenaAD-domenaAD-1000
Účet počítače DC2 v Active Directory S-1-5-21-domenaAD-domenaAD-domenaAD-2578
Účet počítače DC3 v Active Directory S-1-5-21-domenaAD-domenaAD-domenaAD-9392

Na co jsou tyhle SIDy? Služby, které běží pod účtem SYSTEM, Network Service nebo pod servisními účty NT SERVICE a IIS AppPool prostě používají tento účet pro přístup do sítě, pokud se musí ověřit. Můžete tedy na nějakém sdíleném adresáři třeba nastavit přístup jen pro účet DC1 a dostanou se tam jen služby z počítače DC1.

Když třeba jedno DC stahuje repliku Actvie Directory LDAP databáze z jiného řadiče domény, do protokolu událostí, Security, se zaloguje Logon událost obsahující SID právě toho účtu řadiče, který repliku stahuje. Prostě síťová identifikace.

Takže řadiče domény jsou z pohledu sítě jednoduše odlišitelné, protože samy k přístupu do sítě používají každý jiný SID.

PsSid

Známý vševěd a dnes už i spisovatel beletrie Mark Rusinovič napsal kdysi dávno program nazvaný PsSid. Který takzvaně zjišťuje "SID počítače" vzdáleně. Pokud ho vyzkoušíte proti obyčejné stanici, nebo serveru, vrátí to předpokládám pro každý jinou hodnotu. Nevím jakou přesně, jestli je to hodnota jeho lokální SAM databáze, nebo SID jeho počítačového účtu z Active Directory. A je mi to jedno.

Pokud to ale zkusíte vůči řadiči domény, tak to vrací pro všechna DC SID stejný. Nejspíš se jedná o SID jejich domény, tedy to číslo LDAP domény bez RID koncovky.

Tohle je program, o kterým právě mluvil kamoš a tvrdí, že všechna DC mají stejný SID. Nevyhrál. 

Remíza

Jsem ochoten přistoupit na remízu. Ano, jejich LDAP databáze má jen jeden SID. Tak to bych si ani nikdy nedovolil polemizovat. Jinak ale jejich lokální SAM databáze mají SIDy různé. Jejich vlastní AD účty mají SIDy různé. Pojem "SID řadiče domény" neexistuje. Takže není vlastně o čem sázkovat.

Vznik SIDu Active Directory LDAP databáze

Mimochodem, je zajímavé, jak vzniká AD databáze na prvním řadiči domény. DCPROMO prostě vezme lokální SAM databázi a celou, včetně původního lokálního SAM SIDu a všech účtů a skupin, ji přesune do NTDS.DIT souboru.

Takže SID AD databáze je stejný, jako původní SID lokální SAM databáze prvního řadiče dané domény.

Až je to přeneseno, na prvním řadiči dané AD domény se vytvoří nová lokální SAM databáze pro DSRM admina. Tahle dostane nový náhodný SID.

Pokud přidáváte do existující domény nový řadič, chová se to jinak. Jeho databázi už přenést do existujícího NTDS.DIT souboru nelze, takže je úplně zničena. A pro DSRM admina vznikne úplně nová, prázdná lokální SAM databáze se zbrusu novým SIDem.

Další články

K tématům týkajícím se RID a SID tu mám také následující starší věci:

Zneplatnění stávajícího RID rozsahu na řadiči domény (DC)

Access token, Kerberos ticket a omezení na počty skupin

Všichni Izraelci mají SID

Případ SIDu zvaného This Organization

Jupí SQL Server konečně používá servisní účty

Zmatený Rusinovič, NewSID a Sysprep

Comments

Re: Remíza v soutěži o SIDy řadičů domény

ano, jak jste si mohli všimnout, v článku existují dva zajímavé RIDy.

RID -500 je rezervovaný pro builtin\Administrator účet. Účet si můžete kdykoliv přejmenovat, ale vžycky bude mít RID 500. Podle toho se pozná. To je ten účet, který se jako jediný nezamyká, pokud zkoušíte neúspěšně heslo.

Poznáte nějak svoje vůbec první DC v doméně? Ano. Protože jeho RID je 1000. Je to vlastně o jedničku nižší RID, než dostávají všechny ručně vytvářené účty. Takže i když byly už nějaké lokální skupiny a uživatelé na serveru před DCPROMO, tak stejně dostávaly 1001 a větší hodnoty.
ondass on 25.9.2013 20:34

Re: Remíza v soutěži o SIDy řadičů domény

Je to PsGetSID, ne PsSID.
Borek on 25.9.2013 21:01

SIDy

Jen drobný překlep - program se jmenuje psgetsid.
Co se týče těch SIDů na DCčkách - já to mám taky na obou stejně. Před časem jsem se kvůli tomu stresoval, neboť kolega, co má na starosti farmu a přidělování virt. serverů se neobtěžoval mi poskytnout dva normálně nainstalované řadiče a když jsem chtěl druhý DC, tak mi podstrčil image toho prvního... Nicméně jsem se dočetl, že DCčka "sdílejí" stejný machine SID (to je to co ukazuje psgetsid), ale rozlišování probíhá podle object SIDu, což je zase SID objektu v LDAPu (AD), což mají asi každý jinak (protože druhý DC byl normálně zařazen do AD přes DCPROMO). Takže jsem se uklidnil a v pohodě žiju s tím, že psgetsid ukazuje stejný SID na obou DCčkách.
RaT on 8.10.2013 14:40

Re: Remíza v soutěži o SIDy řadičů domény

pozor pozor!

tady bych byl velice opatrný. Jestli máte dva úplně stejné DC, to je otázka, jak vám bude fungovat i třeba AD replikace. Jestli jede, tak ok, ale on třeba Distributed Transaction Coordinator, což je Windows vnitřní služba, kterou používá i třeba DFSR, má s těmi stejnými "IDčky" (schválně neříkám SIDy, protože různých ID je mnoho různých) problémy.

Osobně bych doporučoval to raději přeinstalovat. Pokud samozřejmě nemáte problémy, tak nevadí, ale při prvním podivném chování bych podezříval ten klon.
ondass on 8.10.2013 15:03

stejne SIDy na DC

Díky za info. Zatím všechno funguje (ťuk,ťuk), ale jsem pořád nachystanej tu dvojku přeinstalovat :o))
RaT on 8.10.2013 21:23

Re: Remíza v soutěži o SIDy řadičů domény

Jo jo, IDčka WSUS a MSDTC se musí vyrobit znovu.
Borek on 10.10.2013 19:41

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