Er dvojka a novinky v Active Directory


Přehled novinek


Podobně jako předchozí verze Active Directory dodávaná spolu s Windows 2008 nebo 2003 přinesly některá malinká vylepšení, jsou v novějším vydání také. Když říkám malinká, myslím tím svým objemem kódu nebo počtem funkcí. Jsou to také věci, které ne každý hned využije. Pro některá prostředí je však jejich funkce naprosto zásadní. Pro mě je každá z nich něco, co si na R2 cením nejvíce.


Příkladem starších „detailíků“ byla například replikace multivalue atributů ve Windows 2003. Můj zákazník z Rakouska má okolo 40 poboček, ve kterých pořád někdo vytváří uživatelské účty a mění členství ve skupinách. Až do verze 2003 to bylo strašlivě komplikované, protože jste museli obtelefonovat nejprve všechny pobočky, než jste mohli něco dělat.


Ve Windows 2008 přišly tzv. Granular Password Policies. Dříve jste museli mít zásady hesel stejné pro celou doménu. Nyní to už můžete nastavit různě pro různé skupiny a uživatele. Ne extra důležité, řeknete si, že? Co prostě nastavit pořádnou politiku a je to? Jiný zákazník ale má účty definované v informačním systému a do Active Directory je pouze importuje i s hesly. V okamžiku importu z IS ale hesla politiku nesplňují. Nemohli bychom tedy mít politiku nastavenou vůbec. S tímto stačí prostě naimportovat účty i se slabými hesly a později je teprve vložit do skupin, které politiku vynucují.


Nebo například tzv. constraint delegation a speciálně tzv. protocol transition jsou věci obsažené od Windows 2003, které ocení majitelé ISA Serveru 2006, kteří současně používají čipové karty. Každý můj zákazník používá čipové karty 🙂


Ve Windows 2008 R2 se jedná se následující schopnosti, o kterých se zmíníme v dalším textu.



  • Recycle Bin

  • Offline Domain Join

  • Best Practice Analyzer

Tak honem na to.


Recycle Bin


Nejspíš nejviditelnější změnou bude pro některé tzv. Recycle Bin. Něco velmi podobného jako je známy Koš na soubory ve Windows, nebo třeba obnova vymazaných položek v Microsoft Outlooku. Pokud si něco vymažete v Active Directory, můžete to ještě po určitou dobu obnovit bez ztráty nastavení. Hned si to vysvětlíme, jen začneme trošku s historií.


V přechozích verzích se mazání objektů chovalo následovně. Když jste objekt vymazali, šel ještě po nějakou dobu obnovit, ale jen z části. Ve Windows 2000 to bylo dva měsíce (60 dní). Ve Windows 2003 to poněkud rozšířili na 180 dní. Tato technologie se nazývá tombstone a je pořád přítomna.


Není to ve skutečnosti určeno k pozdější obnově objektů, ale primárně k zajištění bezchybné replikace mezi více řadiči domény (Domain Controller, DC). Představte si, že na jednom DC vymažete nějaký objekt. Informace o tom, že k vymazání došlo, se musí nějakým způsobem poslat na ostatní DC. Objekt se z větší části (většina atributů) odstraní, ale v databázi po něm zůstane právě taková mazací informace zvaná tombstone. Tahle se může po dobu až 180 dní replikovat na další řadiče, které svoje objekty také následně odmažou.


I dříve šel takový tombstone použít k jakési „obnově“ původního objektu. Tombstone totiž obsahuje některé důležité atributy, které se mohly hodit. Jedná se o následující atributy:



  • GUID (unikátní identifikaci objektu v databázi Active Directory)

  • SID (Security ID, unikátní bezpečnostní identifikace)

  • distinguishedName (originální jméno objektu v hierarchii organizačních jednotek a kontejnerů)

  • sAMAccountName (login)

  • userAccountControl (příznaky jako zda je účet zakázán, nebo jestli si musí pravidelně měnit heslo a jestli se může delegovat)

Žádné další atributy, ani křestní jméno, přijmení, emailové adresy ani telefony se neuchovávají.


Nicméně GUID, SID, distinguishedName a sAMAccountName jsou natolik důležité, že se vyplatilo obnovit raději tento jediný tombstone, než provádět autoritativní obnovu celé databáze z nějaké stařší zálohy. Postup na obnovu byl relativně komplikovaný. Zjednodušeně vypsáno takto:



  • spustili jste nástroj LDP.EXE (součást Support Tools, nutno stáhnout z webu Microsoftu)

  • našli jste smazaný objekt v kontejneru CN=Deleted Objects (ten ale není normálně vidět)

  • odstranili jste atribut isDeleted

  • objekt jste ručně přesunuli do jeho původního umístění

  • nastavili jste všechny zbívající atributy na jejich původní hodnoty, tedy pokud jste si je pamatovali

No hrůza. Tak s R2 se to udělá na pomocí dvou příkazů v PowerShellu. Sice na to není žádné grafické rozhraní, ale stejně je to pohoda. Jen napřed jak to funguje a nemá to nějaké podmínky?


Nejprve tedy podmínky. K tomu, aby vám to mohlo vůbec fungovat je nutno, aby vaše prostředí mělo řadiče domény pouze na verzi Windows 2008 R2 a novější. To se prokazuje tím, že úroveň funkčnosti domény i forestu je Windows Server 2008 R2. Proč? No protože není logicky možné replikovat „polosmazané“ objekty na starší řadiče domény, které tuto funkci nepodporují.


Potom už je to třeba jen zapnout pomocí PowerShell příkazu:


Enable-ADOptionalFeature


Pokud to máte zapnuto, můžeme si pohovořit o tom, jak to funguje.


Dříve byl každý objekt ve stavu buď „normální“ nebo „smazaný-tombstone“ (viz obrázek).


obrazek1


Nově se přidává jedna mezifáze, ve které je sice objekt označen jako smazaný, ale pořád obsahuje všechny atributy. Zabírá tedy v databázi stejné místo jako předtím, ale dá se po nějakou dobu obnovit. Bez ztráty obsahu a bez nutnosti autoritatvního obnovení celého řadiče domény. Tedy podle obrázku 2.


obrazek2


Obnova objektu za jeho životní fáze zvané deleted-object se provádí opět pomocí PowerShell příkazu:


Get-ADObject –IncludeDeletedObjects


Restore-ADObject


A je to. Tahle jednoduše dostanete zpět svoje smazané objekty. Případů, kdy si někdo omylem odmazal celou organizační jednotku s tisícem uživatelů znám několik. Zajímavé to je také v jiných případech. Například smazané Group Policy objekty, skupiny, jejichž členství si nepamatujete apod.


Offline Domain Join


Když připojujete počítač do domény, až do dneška jste museli mít online připojení na řadič domény. To obvykle není problém, protože stejně chcete počítač provozovat v doméně. Ale co když jsem dodavatel počítačů, instaluji obrazy operačních systémů dodané zákazníkem a chtěl bych počítač rovnou i do jejich domény připojit, aby se to nemuselo dělat až u zákazníka. Chceme prostě dodávat stroj komplet připravený a bez zásahu po dodávce.


Dříve to znamenalo mít připojení do cílové domény a to zřejmě není vždy možné, bezpečné, nebo ani pohodlné, pokud se jedná o úplně externího dodavatele. Proč jim zbytečně dávat přístup do firemní sítě a navíc uživatelský účet, který je členem skupiny Users, že?


Pokud máte alespoň jeden řadič domény verze Windows Server 2008 R2, můžete si offline připojovat klientské počítače s Windows 7 nebo i další servery s Windows 2008 R2. Jak to funguje?


Připojit počítač do domény od jak živa znamená dva zásadní kroky:



  1. v databázi Active Directory vytvořit účet počítače s prázdným heslem

  2. na stanici, kterou připojuji, se automaticky vygeneruje nové náhodné heslo, které si stanice sama zapíše do příslušného účtu v Active Directory

  3. a zapamatuje si toto heslo sama ve svých registrech v klíči HKLM\Security\Policy\$MACHINE.ACC

Tahle operace vždy vyžadovala, aby si stanice heslo vygenerovala sama náhodně a online změnila na DC. Proč to ale neudělat offline? Stačí prostě říct stanici parametry účtu z Active Directory a ta si může vygenerovat nové heslo až při příštím připojení online na řadič domény.


Tahle operace opět nejde udělat pomocí žádného grafického rozhraní. Musíte na to použít nástroj DJOIN. Na řadiči domény a stanici spustíte následující příkazy:



  1. na řadiči domény spustit
    DJOIN –provision –machine <jmeno-pocitace> –savefile BLOB.TXT

    příkaz vytvoří účet počítače v Active Directory a vyprodukuje soubor BLOB.TXT obsahující všechny údaje o účtu

  2. na stanici přenést soubor BLOB.TXT a spustit později
    DJOIN –requestOBJ –loadfile BLOB.TXT

No a stanice si při příštím startu prostě nahraje soubor BLOB.TXT do registrů a začne si myslet, že je členem domény. Jediné co ještě musí udělat, je změnit si heslo z původně prázdného na nějaké náhodné, stejně jako dříve. To může ale udělat až později, jakmile bude mít připojení na DC. Doménoví uživatelé se stejně nemohou přihlašovat dříve, než bude stanice online, takže ani takto se nic neděje.


Best Practice Analyzer


No konečně! Na tohle jsem čekal. Konečně máte k dispozici tzv. Best Practice Analyzer i pro Active Directory podobně jako byl už dříve k dispozici pro Exchange Server, Small Business Server, ISA Server i další produkty.


Proč konečně? To snad nevím, jak si Active Directory sám nastavit? No já to vím 🙂 ale jsou s tím dva problémy. Za prvé ne každý to ví. Za druhé i profíci si nemohou vždy pamatovat při kontrole všechno, na mnoho věcí zapomenete, pokud práci na Active Directory, DNS a certifikační autoritě neděláte denně. Možná překvapivě, ale je to hodně různých nastavení a v okamžiku, kdy máte více řadičů domény, více různých sítí a poboček, věci se začnou šíleně komplikovat. Existují různá bezpečnostní nastavení, kterými si neopatrně můžete způsobit velké díry do systému. Jedním takovým je například právě tzv. protocol transition, novinka z Windows 2003.


V každém postupu, který toto využívá (přihlašování čipovými kartami, certifikáty, otisky prstů, ISA server, Exchange, SQL Server apod.) se prostě uvádí „zapnout“. Může to způsobit velikou díru o které většinou nevíte.


Jste si také například jisti, že vám korektně funguje synchronizace času? Že vám vůbec běží FSMO Masteři (jako jsou PDC, Infrastructure Master apod.)? Že zálohujete? Že skutečně replikujete, a že vám někde nevisí nějaké replikační konflikty?


Best Practice Analyzer vás před tím ochrání a prostě se podívá, co máte špatně, nebo jen nevhodně a doporučí nějaké vylepšení. Obsahuje hlavně také odkazy na vysvětlující stránky, kde se dozvíte, co každé takové varování znamená.


Nekontroluje jenom Active Directory samotnou, ale hlavně jeden ze základních problémů, který kdy s Active Directory máte. Tím je DNS server, jeho nastavení, dynamické registrace, správné SRV záznamy a podobně.


Špičkové je také, že další kontrolovanou službou je certifikační autorita. Zásahy do certifikační autority se obvykle ve firmách dělají jednou za uherský rok, pokud vůbec někdo kontroluje její stav. BPA se pohodlně podívá, jestli nevydáváte zbytečně nějaké šablony certifikátů, jak to máte s tzv. autoenrollmentem a jestli máte správně dostupné a platné CRL.


Není to nástroj jen pro neznalce. I profíkovi může velmi dobře pomoci.



- Ondřej Ševeček
MCM:Directory Services
MVP:Enterprise Security
blog: www.sevecek.com

Comments (0)

Skip to main content