Ondrej Sevecek's Blog

Možná jste si už všimli, že v ADčku si můžou i obyčejní uživatelé zjistit poměrně dost informací o ostatních uživatelích, skupinách a vlastně skoro o všem. Je dobré o tom vědět. Je to poměrně zásadní bezpečnostní vlastní výchozího nastavení, kterou je potřeba občas omezit, protože to prostě nechcete. Podívejme se jak to vlastně přesně je.

Bleskovka o zabezpečení a oprávněních v AD

Přístup do AD se řídí oprváněním na jednotlivých objektech (například user, group, computer atd.), organizačních jednotkách (organizationalUnit) a kontejnerech (container) a doméně (domain).

Oprávnění se:

1. dědí z nadřazeného "kontejnerového objektu" (řekněme tedy něco jako složky na NTFS)
2. každý nově vytvořený objekt získává nezděděná (explicitní) oprávnění v okamžiku svého vytvoření. Seznam těchto oprávnění se vezme ve schématu (AD schema), kde je přesně definováno pro každý typ objektu. Je to definováno v atributu defaultSecurity každého attributeClass ve schématu. To je docela rozdíl od NTFS, kde se pouze dědí. AD ještě přidává tento default security descriptor.
3. objekty, které jsou členem speciálních skupin jako je Administrators, Server Operators, Backup Operators apod. se jejich zabezpečení každou hodinu navíc resetuje. Provádí to funkce AdminSDHolder, kterou provozuje PDC. Pokud je nějaký účet členem některé z těchto skupin, PDCčko mu vypne dědičnost a smaže veškeré ručně nastavené (explicitní) položky. A místo toho mu nastaví přesně ten seznam, který najde na objektu CN=AdminSDHolder,CN=System,DC=... Takže ho to úplně vyřadí z dědičné hierarchie a zruší mu vlastně i výchozí security descriptor. Mimochodem se to projeví atributem AdminCount = 1.
.
4. existují speciální tzv. confidential atributy. Jsou to například hesla, privátní klíče uživatelů, DPAPI master klíče, nebo BitLocker záchraná hesla a bloby. K tomu, abyste si mohli přečíst hodnotu těchto atributů, musíte je být schopni zapisovat :-) To znamená, že i když byste někomu dali explicitně schopnost číst Read All Properties, stejně by se do těchto atributů nepodíval.
5. oproti souborovému systému, pokud nemáte oprávnění ke čtení nějakého objektu, nevidíte ho ani v seznamu objektů v nadřazené "složce".

Oprávnění ke čtení

Na úrovni domény je nastaveno toto dědičné (inheritable) čtení:

Samozřejmě si tedy každý ověřený uživatel může přečíst informace o doméně samotné a její obsah v nejhornější úrovni, ale to se dalo čekat.

Z předchozího je ale vidět, že Windows 2000 Compatible Access je pekelná skupina. Jestliže do ní někoho dáte, bude schopen číst o ostatních uživatelích i skupinách úplně všechno. Tedy o těch, na ktere se to zdědí. A světe div se, ona obsahuje ve výchozím stavu rovnou skupinu Authenticated Users. A do hajzlu :-) Takže je samozřejmě best-practice tuto skupinu úplně vyčistit. Tam nemá nikdo co dělat. Existuje to kvůli NT 4.0, které si musí být schopni číst co chtějí.

Musíme se tedy mrknout ještě na AdminSDHolder objekt, abycho objekt, abychom zjistili, co si kdo přečte o adminech. V tomto okamžiku mě už zajímá i neděditelné oprávnění. Prostě přesně to, co je na tom objektu nastaveno

Takže je vidět, že na admin objekty si může každý. Jsou to přecejenom servisní uživatelé a není moc důvod blokovat na nich čtení. Prostě každý si o nich přečte všechno.

Podívejme se dále na výchozí oprávnění na organizačních jednotkách (organizational unit):

Takže i zde mohou všichni ověření uživatelé číst všechno o organizační jednotce a listovat jejím obsahem - tedy pokud mají čtení na konkrétní objekty ležící uvnitř této OU. Exchange Information je tak zvaný property set. Seznam jeho oprávnění je definován v Configuration partition ADčka. Podívat na komplet sezname se můžete například tady. Obsahuje to mailNickName, homeMDB a většinu dalších msExch atributů. Ale pro zajímavost to neobsahuje ani proxyAddresses, tedy seznam emailových adres neuvidíte.

No předposlední by nás mohli zajímat uživatelé (user):

Z toho jsou zajímaví Everyone, kteří mohou měnit heslo (change password). To není ve skutečnosti tak nebezpečné, jak to vypadá. Změna hesla vyžaduje znalost jeho původní hodnoty. Jenom Administrators mohou heslo resetovat (reset password) bez jeho původní znalosti.

Na seznam všech atributů v property setech General Information, Public Information, Personal Information a Web Information se podívejte sem. Je to hoooodně dlouhý seznam, tedy skoro všechno. To co tam hlavně není najdete v property setech Logon Information a User Logon Restrictions.

Takže si každý sice přečte váš login a vlastně většinu všech hodnot, které jsou vidět na záložkách ve vlastnostech účtu v AD. Ale už se nedozví kdy jste se naposledy přihlásili (lastLogon), ani cestu na váš logon script (scriptPath), nebo profil (profilePath), ani se nedozví, jestli je váš účet zakázán, nebo si nemusíte měnit heslo (userAccountControl). Ani vaše členství ve skupinách (memberOf, ani tokenGroups, a tokenGroupsGlobalAndUniversal).

Zajímavá je tu skupina Windows Authorization Access Group. To je novinka ve Windows 2003. Jakmile si rozšíříte schema na verzi Windows 2003, přidá se ta mrška do default security descriptoru na uživatelských objektech. Její členové si pak mohou číst vaše členství ve skupinách z atributu tokenGroups a tokenGroupsGlobalAndUniversal.

Tahle skupina Windows Authorization Access Group je určena pro různé přístupové služby, jako jsou VPN servery, nebo třeba SharePoint a SQL server, pokud si potřebují číst členství uživatelů ve skupinách. Pokud má mít nějaký objekt také povolenu Kerberos Constrained Delegation (jak jsem o ní psal už tady), nebo dokonce Protocol Transition.

Už to skoro vypadá, že se Authenticated Users nedozví vaše členství ve skupinách. No nedozví se to jednoduše z atributu tokenGroups, to ne. Ale pokud by to projel zkrz celý strom skupin, tak se to dozví. Default security descriptor na skupinách je totiž tento:

Co to tedy znamená ve zkratce?

Pokud máte výchozí obsah skupiny Pre-Windows 2000 Access Group, může každý uživatel číst úplně všechno (kromě confidential atributů). Pokud máte tuto skupinu prázdnou, nemůžete si přečíst jen velmi limitovanou množinu přihlašovacích a bezpečnostních atributů, jinak Authenticated Users mohou všechno. Včetně členství ve skupinách, byť dost komplikovaně.

Co když to chcete změnit?

Tak to se pěkně nadřete. Tahle změna není obvyklá, takže se budete potýkat s množstvím problémů, téměř v každé aplikaci. Možná ne za všech okolností, ale už jsem to řešil myslím u všech, s čím jsem se kdy setkal včetně takové blbiny jako je DHCP server. Samozřejmě se to dá vždycky vyřešit, ale nadřete se. Ale budete to mít bezpečné! A to já počítám!

Jen pozor - Pre-Windows 2000 Access Group můžete jednoduše vyprázdnit. Oprávnění pro Authenticated Users se odebírá špatně, protože je součástí default security descriptoru a je tudíž na všech objektech explicitně, nezděděné. Což je silnější dokonce více, než zděděné Deny Read.  Takže jestli chcete odebrat Authenticated Users, budete to muset udělat nějakým rekurzivním skriptem, jednotlivě na všech objektech, jako jsem psal například tady.

Tak nashle!