Active Directory

Je opravdu RODC (Read Only Domain Controller) jen pro čtení?

Jiří Hýzler — Sun, 01 Feb 2009 19:59:34 GMT

Než odpovím na otázku v titulku, možná někdo netuší co je to RODC, proto si dovolím nejprve popsat tento typ řadiče.

RODC je novým typem řadiče domény ve Windows Server 2008. Pamětníci Windows NT by mohli namítnout, že zase tak nový typ řadiče to není, protože už v NT byl tzv. BDC (Backup Domain Controller), který by podle názvu RODC odpovídal. Je pravda, že skutečně stejně jako kdysi BDC uchovává nový řadič kopii adresářové databáze pouze pro čtení, ale současně nabízí mnohem více funkcionality.

Hlavními vlastnostmi RODC jsou:

Active Directory (AD) databáze pouze pro čtení.
- Aplikace, které potřebují pouze číst z AD, mohou využívat RODC. Jakmile ale potřebují provést změnu v databázi, musí se obrátit na „zapisovatelný“ DC, tzv. RWDC (Read Write Domain Controller), ze kterého se změna replikuje zpět na RODC.
- Application Compatibility with RODCs: http://technet.microsoft.com/en-us/library/cc754165.aspx
Jednosměrná replikace.
- Směrem z RODC se nic nereplikuje (i kdyby na něm byla změna přímo provedena – např. něco byste smazali v SYSVOLu). Jednosměrná replikace pouze na RODC snižuje komplexnost replikační struktury a snižuje riziko replikace změn z poboček, kde bývá nejčastěji RODC nasazen a kde většinou bývá menší míra zabezpečení serverů.
Filtrované atributy (Filtered Attribute Set – FAS)
- Administrátor může specifikovat atributy (kromě system-critical atributů), které se nebudou replikovat na žádný RODC v lese. To může zamezit vyzrazení některých informací v případě kompromitování RODC.
- Steps to Add an Attribute to the RODC Filtered Attribute Set: http://technet.microsoft.com/en-us/library/cc772331.aspx
Omezení kešování hesel
- Jeden z největších benefitů. Po instalaci RODC neuchovává žádná uživatelská ani počítačová hesla pro přihlášení (kromě vlastního počítačového účtu RODC a krbtgt). Když obdrží požadavek na autentizaci, tak ho automaticky přeposílá na RWDC. Administrátor může nastavit skupinu uživatelských účtů a účtů počítačů, jejichž hesla budou kešovány na RODC (typicky pouze pro zaměstnance pobočky a jejich počítače). Pak tyto účty jsou autentizovány přímo RODC bez použití RWDC. Důvodem omezení replikace hesel na RODC je bezpečnost. V případě kompromitování RODC nemá útočník způsob jak získat hesla např. administrativních účtů v doméně, protože tyto účty se nekešují na RODC, tj. nejsou fyzicky na tomto serveru (pro tyto účty se autentizace provádí na RWDC, který je typicky umístěn jen v centrále). Kompromitované účty zaměstnanců pobočky je navíc možné rychle a hromadně resetovat smazáním účtu počítače RODC na RWDC.
- Více o kešování hesel a fungování autentizace na RODC se dočtete zde: http://technet.microsoft.com/en-us/library/cc754218.aspx
Admin role separation
- Většinou na pobočce DC nezastává pouze funkci repliky AD, ale jsou na něm nainstalovány i další služby. V předchozích verzích bylo obtížné delegovat administraci na pobočkovém řadiči domény, protože buď jste museli delegovaného uživatele zařadit do doménových administrátorů (a tím mohl provádět i změny do AD) nebo jste ho mohli zařadit do skupiny Server Operators a tím sice nemohl provádět změny do AD a při tom měl administrativní oprávnění k operačnímu systému serveru, ale zároveň tím získal možnost administrovat všechny OS řadičů domény v celé doméně. Nyní máte možnost svěřit delegovanému uživateli jen administrativní oprávnění k OS jen na jeden konkrétní řadič domény (např. pro možnost restartovat nějakou aplikaci, aplikování aktualizací, instalaci ovladačů apod.)
Podpora DNS služby
- I DNS server umí fungovat na RODC a i on je pouze pro čtení. Pro konfiguraci DNS není potřeba nic zvláštního nastavovat (postupuje se stejně jako u RWDC), jen všechny požadavky na zápis do DNS databáze budou automaticky přeposílány na RWDC.
Dvou-fázová instalace RODC
- Administrátor může předem na RWDC vytvořit účet pro nový RODC (computer i server object) a delegovat uživatele, který může následně provést instalaci konkrétního RODC. Uživatel pak např. v pobočce už jen spustí instalaci, která může být i navíc automatizována pomocí odpovědního souboru.

RODC může replikovat pouze z Windows Server 2008 RWDC, proto je potřeba alespoň 1 mít nainstalován. Replikace z Windows Server 2003 DC nebo z RODC není možná.

RODC je téměř ideální nasazovat na pobočkách. Na pobočkách totiž je mnohem méně věnovaná pozornost bezpečnosti serverů a to jak fyzické, tak i logické. Většinou na pobočce nebývá stále přítomen administrátor, z prostorových důvodů servery (a tedy ani řadič domény) nebývají uzamčeny v serverovně, ale jsou umístěny přímo v kanceláři (v lepším případě jsou uzamčeny v racku, ale už jsem viděl je i povalovat se na společné chodbě, protože moc hučely). Není tedy divu, že k serverům a DC mají přístup na pobočkách obyčejní zaměstnanci a bohužel i v mnoha případech cizí osoby.

RODC není samospasitelným řešením bezpečnosti DC, ale v kombinaci s instalací na Windows Server 2008 Server Core a technologií BitLocker výrazně zvyšuje bezpečnost tohoto serveru.

Obr: Fyzická bezpečnost DC na pobočce.

A nyní se vrátím konečně k otázce z titulku tohoto článku, zda může RODC zapisovat do vlastní databáze.

RODC má skutečně databázi AD jen pro čtení až na jednu skupinu atributů. V běžné situaci, pokud se pošle na RODC zápisová operace, RODC přesměrovává požadavek na RWDC, který pak tuto změnu replikuje zpět na RODC. Konkrétně, jestliže aplikace se pokusí zapsat na RODC, RODC ji odpoví referencí, informující aplikaci, že by měla svůj požadavek na zápis nasměrovat na RWDC. Pokud aplikace nepodporuje reference, nejspíše nebude fungovat (proto byste je měli důsledně otestovat, než je nasadíte na RODC – viz odkaz výše „Application Compatibility with RODCs“.

Představte si ale situaci, kdy pobočkové RODC nebude mít konektivitu k žádnému RWDC a v té době se někdo pokusí hacknout uživatelský účet nějakým password attackem. Za normální situace, by se na RWDC automaticky inkrementoval atribut BadPwdCount a jakmile by útočník dosáhl počtu povolených pokusů definovaných v politice hesel (v GPO nebo v PSO), účet by byl uzamčen. Protože ale RODC by nemuselo mít konektivitu k RWDC, které by zvýšilo čítač BadPwdCount (to by byla zranitelnost RODC, protože účet uživatele by se nikdy neuzamkl), tak z tohoto důvodu RODC může zapisovat ve vlastní databázi atribut na počet chybných pokusů a přihlášení, tedy BadPwdCount a také atribut LastLogon, aby umožnil případné zamčení účtu.

Microsoft Active Directory Topology Diagrammer

Jiří Hýzler — Thu, 08 Nov 2007 14:05:39 GMT

Nedávno se objevil na stránkách Microsoft zajímavý nástroj pro střední a větší organizace a firmy - Microsoft Active Directory Topology Diagrammer. Tento nástroj automaticky vygeneruje Visio diagram vaší topologie Active Directory a Exchange 200x serverů. Diagramy mohou zahrnovat domény, sites, servery, administrativní a směrovací skupiny z Exchange organizace včetně konektorů.

Podmínkou je mít nainstalované Microsoft Visio 2003 nebo 2007, .NET Framework 2.0. a operační systém Windows 2000 a novější. Lze spustit i na stanici.

Nástroj si můžete stáhnout zde: http://www.microsoft.com/downloads/details.aspx?FamilyID=cb42fc06-50c7-47ed-a65c-862661742764&DisplayLang=en.

Jak poznat, které účty počítačů nemají změněné heslo v AD delší dobu?

Jiří Hýzler — Mon, 22 Oct 2007 13:08:48 GMT

Po přidání počítače W2k a novějšího do domény,je vytvořen účet počítače a je nastaveno heslo pro tento účet, které si automaticky počítač mění každých 30 dní (NT4.0 si měnily heslo u účtu počítače každých 7 dní). Jestliže heslo počítače není změněno během 60 dní od poslední změny hesla (např. počítač je offline), tak počítač není schopen se autentizovat do domény a musíte heslo resetovat (přes pravé tlačítko na účtě v AD).
Můžete jednoduše vyhledat účty počítačů, které si více jak 60 dní nezměnily heslo (jsou označeny jako "stale) použitím řádkového příkazu dsquery:

C:\dsquery computer -stalepwd 60

"CN=PC6,CN=computers,DC=firma,DC=cz"
"CN=WNOVAK,CN=computers,DC=firma,DC=cz"
"CN=NOTEBOOK3,CN=computers,DC=firma,DC=cz"
"CN=WM03,CN=computers,DC=firma,DC=cz"
"CN=TESTPC,CN=computers,DC=firma,DC=cz"

Tento výstup ukazuje, že 5 počítačů si nezměnilo heslo více jak 60 dní a můžete třeba zvážit, zda se nejedná o nějaké "historické" stroje a zda je ještě nutné je ponechávat v doméně.
jh

Popis nastavení v Group Policy

Jiří Hýzler — Fri, 07 Sep 2007 12:49:22 GMT

Určitě se vám stalo, že jste hledali nastavení v Group Policy a ne a ne ho najít. Proklikávat se několika úrovněmi nastavení není zrovna moc pohodlné a proto Microsoft už celkem dlouho nabízí Excelové soubory s popisy všech nastavení, která se nacházejí v Administrative Templates v Group Policy Objektu (GPO).

Stáhnout si je můžete zde pro W2k,XP a Server 2003: http://www.microsoft.com/downloads/details.aspx?FamilyID=7821c32f-da15-438d-8e48-45915cd2bc14&DisplayLang=en a zde pro Windows Vista: http://www.microsoft.com/downloads/details.aspx?FamilyID=41dc179b-3328-4350-ade1-c0d9289f09ef&DisplayLang=en

Dva nástroje pro řešení problémů s Group Policy

Jiří Hýzler — Tue, 14 Aug 2007 06:20:55 GMT

Rád bych upozornil na dva nástroje, které mohou pomoci administrátorům při řešení problémů s Group Policy: GPOTOOL.EXE a DCGPOFIX.EXE.

GPOTool.exe je nástroj, který je součástí Windows Server 2003 a Windows 2000 Server resource kitů a můžete pomocí něho:

ověřit konzistentnost obou částí GP objektů (GPO) mezi složkou Sysvol (Group Policy Template) a databází Active Directory (Group Policy Container)
ověřit replikaci GPO
vyhledat GPO
nastavit specifický řadič domény (DC) na kterém budete provádět testy
zobrazit podrobné informace o GPO
ověřit cross-domain GPO

Zde je příklad, jak může vypadat výstup pokud spustíte gpotool bez parametrů (více v GPOTool.exe /?):

DCGPOFIX.EXE je nástrojem poze pro servery Windows Server 2003 a může obnovit 2 zabudované GP objekty "Default Domain Policy" a "Default Domain Controlers Policy" do originálního stavu po instalaci kromě některých bezpečnostních nastavení, které není možné vrátit přesně do jejich původního stavu. Jakmile spustíte DCGPOFIX, ztratíte veškeré změny, které jste provedli v těchto objektech. Více informaci získáte přes DCGPOFIX.EXE /?.

Tento nástroj použijte spíše až jako poslední záchranu, lepším řešením je použít GPMC na zálohování a obnovu těchto politik.

Více o těchto a dalších nástrojích se dočtete např. zde:

http://technet2.microsoft.com/windowsserver/en/library/e926577a-5619-4912-b5d9-e73d4bdc94911033.mspx?mfr=true

Obnova smazaného objektu z Active Directory

Jiří Hýzler — Tue, 07 Aug 2007 06:21:49 GMT

Jakmile smažete objekt v Active Directory, tak tento objekt není okamžitě smazán z databáze. Je označen jako tombstoned a v databázi zůstane tak dlouho, jak je nastaven "Tombstone live time interval" (standardně 60 dní) - důvodem jsou především replikace. Může se stát, že objekt smažete omylem. V případě, že to byl uživatel, ztratíte tak nenávratně jeho SID a proto existuje způsob jak smazaný objekt "vzkřísit".

Kromě autoritativní obnovy ze zálohy existuje nástroj od Microsoft (dříve od Sysinternals, které MS koupil) ADRESTORE.EXE, který je zdarma ke stažení zde: http://www.microsoft.com/technet/sysinternals/Miscellaneous/AdRestore.mspx. Je to řádková utilitka, která po instalaci umožňuje obnovit objekt pomocí

adrestore -r

Parametr -r říká adrestore, že se má zeptat uživatele před obnovením objektů AD do jejich originálního umístění. Jakmile spustíte řádkový příkaz, můžete vidět např. následující:

Enumerating domain deleted objects:

cn: Karel Novak

DEL:26931e28-18f5-4f08-a486-760b199c9d4d

distinguishedName: CN=Karel

Novak\0ADEL:26931e28-18f5-4f08-a486-760b199c9d4d,CN=Deleted

Objects,DC=firma,DC=cz

lastKnownParent: CN=Users,DC=firma,DC=cz

Do you want to restore this object (y/n)? n ..

Found 99 items matching search criteria.

Volitelně můžete filtrovat objekty (např. nebudete chtít obnovovat všechny ale jen jeden konkrétní) tak, že napíšete:

adrestore -r Novak

K obnově se nabídnou jen objekty vyhovující jménu Novak: