Ondrej Sevecek's Blog

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:

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:

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:

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