By Molnár Péter on
2011. 06. 05. 5:09
Az alapfogalmak
Csak tömören és a Windows Server 2003-ra kihegyezve következzen egy kis összefoglaló, egy még erőteljesen nyomdaillatú, de remélhetőleg a jövőben sokak által alaposan megforgatott könyvből, melynek címe: "Rendszerfelügyelet rendszergazdáknak":
“A tartományok és erdők Windows Server 2003 Active Directoryban bevezetett működési szintjeinek segítségével engedélyezhetők bizonyos tartományi és erdőszintű Active Directory szolgáltatások. A hálózati környezettől függően másféle beállítások állnak rendelkezésre a tartományok és az erdők különböző működési szintjein. A működési szint egyrészt meghatározza a tartományban, illetve erdőben elérhető szolgáltatások körét, másrészt a működési szint emelésével régebbi tartományvezérlők már nem adhatók a tartományhoz. A tartományok működési szintjei a teljes tartományban, és csakis az adott tartományban elérhető szolgáltatásokat befolyásolják. A tartományok-hoz négy működési szint áll rendelkezésre: Windows 2000 – vegyes (mixed), Windows 2000 – natív, Windows Server 2003 – átmeneti (interim) és Windows Server 2003.
A működési szint előléptetését követően a korábbi operációs rendszereket futtató tartományvezérlőket nem lehet a tartományba beléptetni. Ha például a tartomány működési szintjét előléptetjük a Windows Server 2003 szintre, Windows 2000 Servert futtató kiszolgálókat tartományvezérlőként már nem lehet hozzáadni a tartományhoz. Természetesen továbbra is beléptethető a tartományba egy Windows 2000 Server, bármiféle feladatot is elláthat, csak tartományvezérlő nem lehet többé.
Az erdők működési szintjének beállításával az erdő összes tartományán engedélyezhetők szolgáltatások. Az erdőkhöz három működési szint áll rendelkezésre: Windows 2000, Windows Server 2003 – átmeneti (interim) és Windows Server 2003. Az erdő működési szintjének előléptetését követően, a korábbi operációs rendszereket futtató számítógépeket tartományvezérlőként nem lehet az erdőbe beléptetni. Ha például az erdő működési szintjét előléptetjük a Windows Server 2003 szintre, Windows 2000 Server rendszert futtató tartományvezérlőket már nem lehet hozzáadni az erdőhöz.
A működési szint emelése több előnnyel is jár, például így tehetjük lehetővé bizonyos erdő- vagy tartományszintű új szolgáltatások, megoldások használatát (univerzális csoportok, stb.), és az Windows Server 2003 R2 változat bizonyos szolgáltatásai is csak magasabb működési szinteken használhatók.”
Nos, annyi biztosan kiderülhet bárki számára ebből az idézetből, hogy a WS08 kapcsán is szét kell választanunk a témát két részre, a tartományok és az erdő szintjére. Ebben a cikkben egyelőre koncentráljunk a tartományok működési szintjével kapcsolatos okosságokra.
WS08 tartomány működési szintek
A legfontosabb: a WS08 a mixed üzemmód kivételével a többi felállásban képes lesz tartományvezérlőként dolgozni. Tehát a WS08 DC egy NT4 PDC-vel már semmiképp nem, viszont a Windows 2000/2003 DC-kkel biztosan egyet fog érteni.
Windows 2000 natív módú tartományok
Beépíthetünk tehát egy ilyen tartományba is WS08 DC-ket, de a problémamentes együttműködéshez szükség lesz még némi technikai információra, amely azonban még nem közkincs, de nyilván hamarosan az lesz. Az viszont biztos, hogy a WS08 AD újdonságok (lásd a végén) a tartomány ezen állapotában még nem használhatóak, hiszen ezen új technológiák alapfeltétele a tiszta WS08-as tartományi üzemmód. A W2K natív módú tartományok viszont a következő pluszokat adhatják az előző (a mixed) módhoz képest:
- Tartományvezérlő lehet: W2K, W2K3, WS08
- Az univerzális csoportok biztonsági és terjesztési csoportokként is használhatóak
- Csoportok általános egymásba ágyazhatósága
- Biztonsági és terjesztési csoportok közötti konverzió
- SID history
Windows Server 2003 módú tartományok
Ebben az üzemmódban a Windows 2000 DC-k már nem, a Windows Server 2003-ak viszont csont nélkül használhatóak együtt a WS08 DC-kkel. A korábban említett WS08 újdonság viszont szintén nem működnek majd ilyen körülmények között (van ami igen, de ez legyen egyelőre még titok). A W2K3 natív módú tartományok viszont a következő plusz lehetőségeket biztosítják az előző (a W2K natív) módhoz képest:
- Tartományvezérlő lehet: W2K3, WS08
- A Netdom.exe-vel átnevezhetjük a tartományvezérlőt
- A „Users” és a „Computers” tárolók (azaz nem OU-k) átirányítása
- Képes frissíteni a gépek illetve júzerek viszonylatában a LastLogonTime attribútumot (de nem replikálja), illetve replikálja a a tartományon belül a LastLogonTimeStamp-et - mégha ez utóbbinál a frissítés kissé nehézkes is, azaz nem túlságosan nagy pontosságú
- Az Authorization Manager a házirendjeit tárolhatja az AD-ban
- Rendelkezésre áll a Kerberos Secure Delegation az alkalmazások számára a Kerberos hitelesítés kikényszerítésére
Windows Server 2008 módú tartományok
Ha már itt tartunk majd, akkor már csak WS08 DC-ink lesznek (vagy elszúrtuk, de nagyon :D). Ez a szint azért fontos, mert gyakorlatilag az összes nagyobb és fontosabb címtárszolgáltatás újdonság ekkor elérhető csak el teljes mellszélességel. A WS08 módú tartományok például (a lista nem teljes!) a következő extrákat adják az előző (a W2K3) módhoz képest:
- Tartományvezérlő lehet: WS08
- DFS-R replikáció a SYSVOL megosztás számára, amely egy kifejezetten kellemes dolog, hiszen ekkor bevethető a DFS-R részeként az RDC algoritmus, amivel könnyedén magas tömörítési hatásfokot is elérhetünk, márcsak azért is, mert az RDC a különbségi replikációs módszert preferálja
- Kerberos AES 128/256 támogatás
- Last Interactive Logon Information, amely megmutatja a júzer legutolsó sikeres interaktív belépésének időpontját, az ehhez használt munkaállomást illetve a sikertelen belépések számát is (a hírek szerint elvileg az ismerős Acctinfo.dll integrálásáról van szó, bár nekem még eddig sehogysem sikerült előcsalogatni ezeket az infókat az ADUC-ban)
- Fine-grained password policies, azaz az alternatív jelszóházirend (eddig egy tartomány = max. egy jelszó házirend volt a szabály), akár OU-ként különböző jelszó házirend opciókkal. További, részletes infó itt.
Megtörténik mindjárt….
Most az erdők működési szintjének WS08-as szintre emelésével folytatjuk. Fárasztó lesz, különösen a vége, ezért kora reggel ne olvassuk el, mert visszaalszunk :D
Első lépésben visszanyúlunk az alapokhoz az előző alkalommal is emlegetett könyvből ("Rendszerfelügyelet rendszergazdáknak"), még a Windows Server 2003-ra koncentrálva:
"Az erdők működési szintjének beállításával az erdő összes tartományán engedélyezhetők szolgáltatások. Az erdőkhöz három működési szint áll rendelkezésre: Windows 2000, Windows Server 2003 – átmeneti (interim) és Windows Server 2003. Az erdő működési szintjének előléptetését követően, a korábbi operációs rendszereket futtató számítógépeket tartományvezérlőként nem lehet az erdőbe beléptetni. Ha például az erdő működési szintjét előléptetjük a Windows Server 2003 szintre, Windows 2000 Server rendszert futtató tartományvezérlőket már nem lehet hozzáadni az erdőhöz."
Szummaként elmondható, hogy óvatosabban kell bánnunk az erdő működési szintjének változtatásával, mint pl. a tartományéval, mert a hatóköre lényegesen nagyobb is lehet.
WS08 erdő működési szintek
A négyből (3 + a WS08) három erdő működési szint mellett használhatunk WS08 tartományvezérlő(ke)t. Nézzük át az idők kezdetétő, hogy mi minden pluszt lehetett korábban elérni egy-egy működési szint emeléssel.
Windows 2000 natív módú erdő
- Tartományvezérlő lehet: W2K, W2K3, WS08
- Az akkor még újnak számító, és előd nélküli címtárszolgáltatás összes alapértelmezett tulajdonságát használhattuk.
Windows 2003 natív módú erdő
- Tartományvezérlő lehet: W2K3, WS08
Néhány újdonság (nem az összes):
- Cross Forest Trust, azaz erdők közötti bizalmi kapcoslat kialakítása, magyarul két erdő összekötése, pl. két cég összeolvadása apropóján. Kétirányú, tranzitív az erdők összes tartománya között, de nem az az egyik erdőhöz ugyanígy kapcsolódó harmadik erdő felé.
- Tartomány átnevezés
- Link valued replication, azaz az „finomított” replikáció, amely sávszélesség takarékos, és lehetővé teszi hogy ne az adott elemet tartalmazó egész tömb replikálódjon, hanem csak a ténylegesen megváltozott elem
- Séma elemek inaktiválása, azaz olyan osztályok és attribútumok forgalomból kivonása, amelyek sérültek vagy már nem szükségesek. A törlés nem járható út továbbra sem, de legalább a takarítás megoldható, sőt nagy szükség esetén akár visszakaphatjuk a koszt is, ti. az inaktiválás visszavonása, a deaktiválás is működik.
- RODC, bizony a WS08 egyik nagy dobásaként számontartott teljesen új típusú tartományvezérlő működik az erdő Windows Server 2003-es szintjén is, igaz egy kisebb szépséghibával, lásd később.
Windows Server 2008 módú erdő
- Tartományvezérlő lehet: WS08
Újdonságok:
Megdöbbentő, de tartományi szint számtalan újdonságával nagyjából el is lőttük a puskaport, azaz erdőszinten nincs semmilyen extra újdonság. Egyetlen dolgot azért meg kell említeni, ami miatt valószínűleg érdemes is lesz megemelni az erdő működési szintjét, ha lehetséges. A dolog a RODC-val kapcsolatos, de messziről futunk neki. Néhány alkalmazásnál megszokott dolognak számít, hogy a címtárban tárol szenzitív adatokat (jelszavak, jogosultságok, titkosított kulcsok, stb.). Ezzel nincs is gond, sőt praktikusnak is tekinthetjük ezt a módszert, a tartományvezérlőkre amúgyis fokozottan oda kell figyelünk, és hát valóban ritkán tűnik el egy-egy DC a szerverszobából/teremből. Viszont ha bekerül majd a képbe egy-egy RODC - ismerve a tulajdonságait: csak olvasható, jelszavakat nem tárol, Server Core-ra is felmegy, stb. - a telephely egy sötét sarkába lerakva, akkor azért kicsit mégis aggódhatunk. Ugyanis egy címtárpéldány azért lesz azon a gépen is, szóval ha történetesen ellopják, azért kibányászható lesz belőle ez-az.
No, erre találta ki az MS okosan az ún. RODC Filtered Attribute Set (RODC FAS, korábban RO-PAS néven is futott) használatanák lehetőségét, amely azt jelenti, hogy a WS08 Schema Master DC-n pl. az ldfide-vel vagy az ADSIEdit-tel megnövelhetjük az adott attribútum tulajdonságai között a searchFlags értéket (pl. 0-ról 640-re = CONFIDENTIAL / RODC_FILTERED, lásd kép, bár ott még hexában van). Így aztán ha a tartományvezérlő beleakad ebbe az értékbe, akkor ezt az attribútumot nem fogja replikálni a RODC kérésére. Mármint a WS08 GC DC-k, merthogy egy WS03 GC DC továbbra is megengedő lesz (kipróbáltam ezt is, hiába hekkeljük meg az említett flag-et a WS03 Schema Master-en, nem érti) és csont nélkül hagyja magát megerőszakolni. Ha viszont az erdőnkben már nincs és nem is lehet effajta „régi” DC, akkor a problémát – kicsit közvetve ugyan de - letudtuk.
Az általam variált Employee-Number attribútumon szépen látszik a változás
Sőt, a WS08-ban már gyárilag megjelöltek ily módon egy pár attribútumot, elsősorban a Credential Roaming (azaz ha több gépen bejelentkezve akarunk azonos tanúsítványt és kulcskészletet használni) és a BitLocker miatt, konkrétan ezeket:
- ms-PKI-DPAPIMasterKeys
- ms-PKI-AccountCredentials
- ms-PKI-RoamingTimeStamp
- ms-FVE-KeyPackage
- ms-FVE-RecoveryGuid
- ms-FVE-RecoveryInformation
- ms-FVE-RecoveryPassword
- ms-FVE-VolumeGuid
- ms-TPM-OwnerInformation
Annyi még lényeges, hogy a jelszavak replikálásával ellentétben itt nincs választási lehetőség egyesével. Akárhány RODC-nk is van, a megjelölt attribútumok egyikre sem fognak replikálódni. Vagy mindre fognak, ha nem jelöljük meg.
Ha már itt tartunk, azért említsük meg, hogy a FAS mellett/helyett van még egy lehetőségünk, ez pedig a védeni kívánt attribútum searchFlags értékének feljavítása a „CONFIDENTIAL” szintre (ennek 128 a decimális értéke, ez az előző esetben ugye automatikusan benne van a 640-ben, látszik is a képen). Ezt a WS03 SP1 óta lehetséges művelni, van is hozzá egy rendesen fárasztó KB cikk is. Gyakorlatilag e változtatás az Authenticated Users csoport Read jogát veszi le (ergo egy akármilyen jöttment RODC-jét is), csakhogy - állítólag - az a gond lehet ezzel, hogy az említett alkalmazások esetleg nem veszik majd ezt jónéven. A privát fantáziálásom homályos elméleti eredményeként arra jutottam, hogy ez talán a WS03 DC <> RODC viszonyban is megoldás lehetne, de erről nem szól a fáma (kipróbálni meg nem tudtam), nincs is utalás erre a jelenleg rendelkezésre álló doksikban, de talán kicsit később majd ez is világosan kiderül.