bevezetés
A Windows Server 2008 rendszerben a Microsoft úgy döntött, hogy visszatér egy olyan funkciót, amelyet a Windows NT óta nem látottunk: ez csak írásvédett tartományvezérlő technológia. Ebben a cikkben a Csak olvasható tartományvezérlő technológiáról és annak előnyeiről fogok beszélni. Ezt a technológiát már egyszer említettem a cikkeimben, például egy cikkben, amely az adprep segédprogram használatáról szól a Windows 2008-ban.
Az informatikai technológia fejlesztésének ciklikus jellegére jó példa az új, csak olvasható tartományvezérlőnek (RODC) nevezett Windows Server 2008 szolgáltatás. Végül is ez a technológia először nagyon régen jelent meg, ám az elmúlt 10 évben gyakorlatilag nem használták fel.
A Windows NT volt a Microsoft első kiszolgálói operációs rendszere. A modern Windows Server operációs rendszerekhez hasonlóan a Windows NT teljes mértékben támogatja a domain technológiát. Az egyik különbség az volt, hogy minden tartományban csak egy tartományvezérlő volt írható. Ez a tartományvezérlő, amelyet elsődleges tartományvezérlőnek vagy PDC-nek hívtak, volt az egyetlen olyan tartományvezérlő, amelyben a rendszergazda módosíthatott. Az elsődleges tartományvezérlő ezután frissítéseket küldött a tartomány többi tartományvezérlőjére. Ezeket a tartományvezérlőket biztonsági tartományvezérlőknek (BDC) hívták, és a rájuk vonatkozó információ csak akkor került frissítésre, amikor a fő tartományvezérlőt frissítették, a domain ügyfelek számára pedig csak olvashatóak voltak..
És bár ez a domain modell teljes mértékben működőképes volt, jelentős hátrányai is voltak. Különösen a fő tartományvezérlővel kapcsolatos problémák béníthatják meg a teljes tartományt. Mint tudod, a Microsoft jelentős változtatásokat hajtott végre a tartománymodellben, amelyet az új szerver operációs rendszerükben, a Windows 2000 Serverben vezettek be. Két új technológia jelent meg a tartományvezérlők számára a Windows 2000 Server rendszerben, és mindkét innovációt ma is használják: ezek az Active Directory és a modell több fő vezérlővel (multi master modell)..
És bár a PDC szerepe továbbra is fennmaradt, a többvezérlő-konfigurációban szereplő többi tartományvezérlő írható volt. Ez azt jelenti, hogy az adminisztrátor bármilyen tartományvezérlőn változtatásokat hajthat végre, és ezeket a módosítások formájában a frissítéseket végül elosztják a hálózat összes többi tartományvezérlőjével..
Ezután a multi-master modell mentésre került mind a Windows Server 2003, mind a Windows Server 2008 rendszerben. A Windows Server 2008 rendszerben azonban lehetővé vált a Csak olvasható tartományvezérlők létrehozása. A RODC egy olyan tartományvezérlő, amelyben az információkat még a rendszergazdák sem változtathatják meg közvetlenül. E tartományvezérlők frissítésének egyetlen módja a módosítások alkalmazása a PDC-n, majd ezeket a módosításokat tovább kell terjeszteni (replikálni) a RODC-re. Semmire sem emlékeztet?
Mint láthatja, a RODC-k nem más, mint a Windows NT korszakának emlékei. Természetesen a Microsoft nem adná vissza a RODC technológiát, ha nem látna jelentős előnyöket alkalmazásukban..
Mielőtt elmagyaráznám, miért döntött úgy a Microsoft, hogy visszatér az RODC-hez, hadd magyarázzam el, hogy az RODC használata miért nem feltétele az Active Directory tartományokkal való munka 2008 2008-ban. Ha azt akarja, hogy az erdő minden tartományvezérlője írható legyen, akkor ezt megteheti.
Röviden szeretném megemlíteni, hogy bár az RODC-k nagyon hasonlítanak az NT biztonsági mentési tartományvezérlőihez (BDC), számos változáson mentek keresztül. Van néhány dolog, amely új az RODC technológiában, és szeretnék róluk beszélni.
Miért döntött úgy a Microsoft, hogy visszatér az RODC-t? Ennek oka a fiókhálózat (divíziók és fióktelepek) támogatása. A fióktelepeket hagyományosan meglehetősen nehéz fenntartani és fenntartani távoli elhelyezkedésük és a székhely és a fióktelep közötti kommunikációs jellemzők miatt..
Hagyományosan több különféle módszert alkalmaztak az ágazatok kezelésére, de mindegyiknek megvan a maga előnye és hátránya. A fiókhálózat megszervezésének egyik leggyakoribb módja a központi irodában lévő összes szerver telepítése, és a fióktelep felhasználói számára a globális hálózaton (WAN) keresztül történő hozzáférés biztosítása..
Természetesen ennek a módszernek a legszembetűnőbb hátránya, hogy ha a WAN-csatorna instabil vagy leesett, akkor az ágazatban lévő felhasználók nem képesek normálisan működni, mert teljesen le vannak választva a központi iroda összes forrásából. Még akkor is, ha a központi irodával való hálózati kapcsolat stabil, a WAN-kapcsolat teljesítménye gyakran gyenge lehet a csatorna terhelése vagy közvetlenül a kapcsolat sebessége miatt
Egy másik általános lehetőség távoli ágakkal való munkavégzés során egy olyan megközelítés, amely legalább egy tartományvezérlő telepítését foglalja magában az ágban. Ez a tartományvezérlő gyakran DNS-kiszolgálóként és globális katalógus-kiszolgálóként is működik. Így még akkor is, ha a WAN-kapcsolat megszakad, legalább az ágazatban lévő felhasználóknak lehetősége van belépni a hálózatba. A szervezet munkájának jellegétől függően más szerverek is telepíthetők a fióktelepbe.
Noha ez a megoldás rendszerint nagyon jól működik, és számos hátránya van. A fő hátrány a költség. A kiszolgálók fióktelepeinek tárolása megköveteli a vállalkozástól, hogy fektessen be a szerver hardverbe és a szoftver licenceibe. Jelentősen megnövekedett támogatási költségek. A szervezetnek meg kell határoznia, hogy a fióktelepnek szüksége van-e saját informatikai szakembereinek személyzetére, vagy működési zavarok esetén készen áll arra, hogy megvárja, amíg a központi iroda informatikai személyzete eléri a fióktelepet.
Egy másik árnyalat a saját kiszolgálók telepítésében az ágban a biztonsági kérdés. Tapasztalataim szerint gyakran fordulnak elő olyan esetek, amikor a központi adatközponton kívüli kiszolgálók felügyelet nélkül maradtak. A kiszolgálókat gyakran egyszerűen bezárják egy szekrénybe egy kulcsmal!
Mint korábban említettem, a WAN-kapcsolatok gyakran lassúak és megbízhatatlanok. Ez egy másik probléma a kiszolgálók elhelyezésével az ágban. A tartományvezérlő replikációs forgalma jelentősen betölti az ilyen kapcsolatot
Pontosan ez a helyzet, ha használhatja a RODC-t. Az RODC elhelyezése az ágban nem zárja ki teljes mértékben az Active Directory replikációs forgalmat, de jelentősen csökkenti a hídfej-kiszolgáló terhelését, mivel csak bejövő replikációs forgalmat kapnak.
A RODC-k szintén hozzájárulhatnak a biztonság javításához, mivel a fióktelep munkatársai nem tudják módosítani az Active Directory-adatbázist. Ezenkívül semmilyen információt nem továbbítanak az összes domain felhasználóról és számlájukról az RODC-re. Ez azt jelenti, hogy ha valaki ellopta az RODC szervert, akkor nem fogja tudni használni a felhasználói jelszavak törésének eredményeként kapott információkat..
A sorozat jövőbeli cikkeiben a csak írásvédett tartományvezérlők tervezésének és telepítésének folyamatát tárgyaljuk..
Linkek a sorozat összes cikkéhez:
Munka csak olvasható tartományvezérlőkkel (RODC) (1. rész)
Munka csak olvasható tartományvezérlővel (2. rész)
Munka csak olvasható tartományvezérlővel (3. rész)
