A helyi domain neve. Hogyan ne nevezzük el az Active Directory tartományokat
Olvassa el is
Ritka esetekben a Domain Services rendszergazdája szembesülhet azzal a feladattal, hogy átnevezze az aktuális tartományt. Az okok eltérőek lehetnek, de ez a helyzet teljesen lehetséges. Annak ellenére, hogy ez a feladat nem nevezhető triviálisnak, de időnként meg kell vele küzdeni, rendkívül fontos, hogy mindent jól csináljunk, mert ellenkező esetben az események kimenetele kritikusan veszélyes lehet, akár egy teljesen nem működő vállalati infrastruktúráig. Tehát ebben a cikkben később megismerheti a művelet végrehajtásának előfeltételeit, néhány korlátozást, valamint a domain átnevezésének módját. Mielőtt elkezdené, kérjük, hogy ne hajtsa végre ezeket a lépéseket éles környezetben, amíg sikeresen át nem nevezte teszttartományát laboratóriumi környezetben. Kezdjük.
Előfeltételek
Mielőtt elkezdené a domain átnevezését, feltétlenül vegye figyelembe a következő információkat:
- Active Directory erdő funkcionális szintje. Csak akkor hajthat végre tartomány átnevezési feladatokat, ha az erdő összes tartománya legalább Windows Server 2003 rendszert futtat (ebben az esetben nincsenek kiadási korlátozások). Ezenkívül a funkcionális szintet legalább a Windows Server 2003 szintjére kell emelni. Windows szinten Server 2000, akkor a következő művelet egyszerűen lehetetlenné válik;
- Domain helye. Az Active Directory erdőben különböző szintű tartományok lehetnek. Vagyis lehet egyetlen tartomány, vagy az erdő tartalmazhat gyermektartományokat. Abban az esetben, ha megváltoztatja a tartományvezérlő helyét az erdőn belül, létre kell hoznia egy bizalmi kapcsolatot;
- DNS zóna. Még a tartomány átnevezési művelet végrehajtása előtt létre kell hoznia egy új DNS-zónát;
- Adminisztratív hitelesítő adatok. Tartomány átnevezési művelet végrehajtásához olyan rendszergazdai fiókkal kell bejelentkezni, amely a Vállalati rendszergazdák csoport tagja;
- Elosztott fájlrendszer (DFS) szerverek. Ha a vállalati környezetében DFS van telepítve vagy barangolási profilok vannak konfigurálva, vegye figyelembe, hogy a DFS gyökérkiszolgálóknak legalább Windows Server 2000 Service Pack 3 vagy újabb operációs rendszert kell futtatniuk;
- Nem kompatibilis a Microsoft Exchange szerverekkel. A legbosszantóbb az, hogy ha az Active Directory erdőben Microsoft Exchange Server 2003 Service Pack 1 levelezőszerver van telepítve, akkor a tartomány átnevezése minden probléma nélkül megtörténik, de a felhasználói fióknak, amelyen a tartomány átnevezési folyamat végrehajtódik tagja legyen a Teljes Exchange-adminisztrátor csoportnak. Egyre modernebb levelezőszerverek(beleértve az Exchange Server 2016-ot is) nem kompatibilisek a tartomány átnevezési műveleteivel.
Vegye figyelembe azt is, hogy a tartomány átnevezése közben le kell fagyasztania az összes függőben lévő Active Directory erdőkonfigurációs műveletet. Más szavakkal, gondoskodnia kell arról, hogy az erdő konfigurációja ne változzon addig, amíg a tartomány átnevezési művelet teljesen be nem fejeződik ( részletes információk lásd alább ennek részleteit). Ezek a műveletek a következők: tartományok létrehozása vagy eltávolítása az Active Directory erdőn belül, alkalmazáscímtár-partíciók létrehozása vagy eltávolítása, tartományvezérlők hozzáadása vagy eltávolítása az erdőben, közvetlenül létrehozott megbízhatóság létrehozása vagy eltávolítása, valamint olyan attribútumok hozzáadása vagy eltávolítása, amelyek replikálódnak a globálisan. katalógus.
Minden esetre azt is tanácsolom, hogy készítsen teljes rendszerállapot-mentést az Active Directory-erdő minden tartományvezérlőjén. Ha ez a feladat elkészül, ez az óvintézkedés biztosan nem lesz felesleges.
Abban az esetben, ha az infrastruktúra megfelel a fenti követelményeknek és minden szükségesnek biztonsági mentések, folytathatja a domain átnevezési folyamatot.
Active Directory tartomány átnevezési folyamata
Kezdésként a domain eredeti nevének ellenőrzéséhez nyissa meg a rendszertulajdonságok ablakot. Amint az a megfelelő ábrán látható, a domain nevem "Biopharmaceutic.local":
Rizs. 1. Az eredeti Active Directory tartománynév ellenőrzése
Most létre kell hoznia egy új "biopharm.local" DNS-zónát, hogy a domain átnevezés sikeres befejezése után a tagszerverek és a kliensek gond nélkül csatlakozhassanak az újhoz. domain név. Ehhez nyissa meg DNS-kezelő» ( DNS-kezelő) és benne lenni " Forward Lookup Zone» ( Forward Lookup Zone) válassza ki az új zóna létrehozásának lehetőségét. Lényegében a zóna a szokásos módon jön létre: az Új zóna varázsló első oldalán olvassa el a bevezető információkat, és lépjen tovább a második oldalra. A zónatípus oldalon válassza ki az elsődleges zónát ( Elsődleges zóna), és győződjön meg arról, hogy a zóna Active Directoryba való mentésének lehetősége engedélyezve van. A zóna replikációs terület oldalán hagyja alapértelmezés szerint bejelölve az opciót - " A tartomány tartományvezérlőin futó összes DNS-kiszolgálóhoz: Biopharmaceutic.local» ( Az ebben a tartományban lévő tartományvezérlőkön futó összes DNS-kiszolgálóhoz: Biopharmaceutic.local). A zónanév oldalon meg kell adni az új domain nevet (biopharm.local), a dinamikus frissítési oldalon pedig hagyja meg a " Csak biztonságos dinamikus frissítések engedélyezése (Active Directoryhoz ajánlott)» ( Csak biztonságos dinamikus frissítések engedélyezése (Active Directoryhoz ajánlott)), amely alapértelmezés szerint ki van választva. Az alábbiakban egy új zóna létrehozásának több lépését láthatja:
Rizs. 2. Hozzon létre egy újat DNS zónák
A tartomány átnevezésének következő lépése az erdő jelenlegi állapotának leírása. Valójában ez az első tartomány átnevezési művelet, amely a parancssori segédprogramot használja Rendom. Ez a segédprogram egy Domainlist.xml nevű XML-fájlként szöveges leírást készít az erdő jelenlegi szerkezetéről. Ez a fájl tartalmazza az Active Directory-erdőben található összes tartományi címtárpartíció és alkalmazáscímtár-partíció listáját. Az egyes tartomány- és alkalmazáscímtár-partíciók bejegyzései korlátozottak XML címkék
Ilyen fájl létrehozásához nyissa meg a megfelelő fiókot parancs sorés hajtsa végre a parancsot " véletlenszerű /lista". A generált fájl a gyökérkönyvtárba kerül mentésre fiókot a felhasználód. Ezután meg kell nyitnia ezt a fájlt bármilyen szövegszerkesztővel.
Ebben a fájlban meg kell változtatnia a domain nevet a címkékkel határolt szakaszon belül
A következő ábrán láthatja a fenti parancs végrehajtásának folyamatát, a Domainlist.xml fájl helyét és a fájl első szakaszának módosításait. Az én esetemben a domain név ebben a konfigurációban négyszer módosul:
Rizs. 3. A Domainlist.xml fájl létrehozása és módosítása
Annak érdekében, hogy megbizonyosodjon arról, hogy elvégezte a szükséges módosításokat a megfelelő fájlban, futtassa a "" parancsot. random /showforest". Amint az alábbi ábrán látható, az összes bejegyzésem „Bopharm”-ra változott:
Rizs. 4. Tekintse meg a lehetséges változásokat
A következő parancs végrehajtásakor ( véletlenszerű /feltöltés), a Rendom segédprogram lefordítja a szerkesztett fájlban megadott új erdőszerkezetet a katalógusfrissítési utasítások sorozatává, amelyek helyileg és távolról is futnak az erdő minden tartományvezérlőjén. Általánosságban elmondható, hogy ez a lépés módosítja a Domain Naming Wizard konfigurációs könyvtár szakaszát az Active Directory tartomány átnevezése érdekében. Ezenkívül egy Dclist.xml fájl is létrejön, amely az erdőben lévő egyes tartományvezérlők előrehaladásának és állapotának nyomon követésére szolgál a tartomány átnevezési művelethez. Egyébként ezen a ponton a Rendom segédprogram leállítja az Active Directory-erdőt a konfiguráció módosításától. A parancs végrehajtásának folyamata az alábbiakban látható:
Rizs. 5. Futtassa a rendom /upload parancsot
A következő parancs fut a tartományvezérlők készenlétének ellenőrzésére a tartomány átnevezési művelet előtt. Ebben a lépésben le kell futtatnia az előkészítő ellenőrzési parancsot minden tartományvezérlő az erdőben. Ez annak biztosítására szolgál, hogy az erdőben lévő minden tartományvezérlőn lévő Active Directory-adatbázis megfelelő állapotban legyen, és készen álljon a tartomány átnevezését lehetővé tévő változtatásokra. Ezért futtassa a "parancsot" random /prepare", ahogy az a következő ábrán is megtörténik:
Rizs. 6. A tartomány előkészítése átnevezésre
A legfontosabb pillanat. A "parancs végrehajtása" véletlenszerű /végrehajtás". Amikor ez a parancs fut a tartományon, a tartomány átnevezésére vonatkozó utasítások végrehajtásra kerülnek. Lényegében ebben a pillanatban az erdőben lévő minden tartományvezérlővel külön lépnek kapcsolatba, ami arra készteti az összes tartományvezérlőt, hogy utasításokat hajtson végre a tartomány átnevezésére. A művelet befejezése után minden tartományvezérlő újraindul. Tekintse meg az alábbi ábrát a domain átnevezésének folyamatáról:
Rizs. 7. Domain átnevezési folyamat
De ez még nem minden. Annak ellenére, hogy a domainjét valójában már átnevezték, továbbra is Ön a feladata a csoportházirend-objektumok és hivatkozásaik kijavítása, miután a tartomány átnevezési művelet befejeződött. Egy parancssori segédprogram a csoportházirend-objektumok és -hivatkozások visszaállítására szolgál minden átnevezett tartományban. gpfixup.exe. Ezt az eljárást nem szabad figyelmen kívül hagyni, mert enélkül a domain átnevezési művelet befejezése után az új erdőben, csoportszabályzat Egyszerűen nem fogok megfelelően működni. Vegye figyelembe, hogy ezt a parancsot minden átnevezett tartományon egyszer le kell futtatni. Ezért futtassa le a parancsot egyszer gpfixup paraméterekkel /olddns:Biopharmaceutic.local(az átnevezett domain régi neve) és /newdns:Biopharm.local(az átnevezett tartomány új neve), majd a parancsot gpfixup paraméterekkel /oldnb:BiopharmaceuticÉs /newnb:Biopharm(a domain régi és új NETBIOS neve). Ez az eljárás az alábbiakban látható:
Rizs. 8. GPO-k javítása
Már csak két parancsot kell végrehajtani: a parancsot " véletlenszerű / tiszta", amely lehetővé teszi az összes régi tartománynevekre való hivatkozás eltávolítását az Active Directoryból, valamint a " véletlenszerű /end”, valójában feloldja az Active Directory-erdőt a konfiguráció módosításától. A parancsok végrehajtásának folyamatát az alábbi ábrán láthatja:
Rizs. 9. Végezze el az Active Directory tartomány átnevezését
Ahhoz, hogy a módosítások érvénybe lépjenek a tagszervereken és a végklienseken, kétszer újra kell indítani a számítógépeiket. A tartományvezérlőket azonban manuálisan kell átneveznie. Amint az a következő ábrán látható, a tartományvezérlőm neve továbbra is ugyanaz.
Ez az eljárás sokkal bonyolultabb, mint egy olyan tagkiszolgáló átnevezése, amely egy tartomány rendes tagja. Ehhez a feladathoz szükségünk van a segédprogramra " NETDOM", amelytől kezdve Windows 2008 része OS, és számára Windows 2003 telepíteni kell" Támogatási eszközök ".
Tartományvezérlő átnevezéséhez tegye a következőket:
1. Először is győződjön meg arról, hogy a tartomány funkcionális szintje nem alacsonyabb, mint Windows 2003és ellenőrizze az engedélyeket Domain Admins
" ("Domain Admins
").
2. Nyisson meg egy emelt szintű parancssort, és adjon hozzá egy további nevet annak a vezérlőnek, amelyet át akarunk nevezni (a példánkban SRV-DC1-RÉGI.TESZT.HELYI
átnevezni erre SRV-DC1.TESZT.HELYI
):
NETDOM számítógépnév SRV-DC1-OLD.TEST.LOCAL /add:SRV-DC1.TEST.LOCAL
3. A szerkesztő használata " ADSIEDIT.msc" Győződjön meg róla, hogy a név helyesen lett hozzáadva. A szerkesztőben keresse meg a tartományvezérlő objektumot, és ellenőrizze a tulajdonság értékét " msDS-AdditionalDnsHostName", aminek egyenlőnek kell lennie a " SRV-DC1.TESZT.HELYI
".
4. Most meg kell győződnie arról, hogy a frissített SPN attribútumokat teljesen replikálták az erdő más tartományvezérlőire. A segédprogram ebben segít nekünk " REPADMIN"vagy" REPLMON"Mert Windows 2003.
A folyamat felgyorsítása érdekében a replikáció kényszeríthető a " DSSITE.msc". Csak kattintson Jobb klikk kattintson a kapcsolatra, és válassza a " Replikáld most".
5. Most a tartományvezérlő új nevét tesszük elsődlegesnek:
NETDOM számítógépnév SRV-DC1-OLD.TEST.LOCAL /makeprimary:SRV-DC1.TEST.LOCAL
6. Túlterheljük a szervert.
7. Ismét ellenőrizzük, hogy a frissített SPN attribútumok és bejegyzések DNS sikerült teljes mértékben replikálni más tartományvezérlőkre és kiszolgálókra DNS az erdőben, és az ingatlan értéke" msDS-AdditionalDnsHostName" most egyenlő a régi szervernévvel.
Akut időhiány esetén ismét kényszerítheti a replikációt, és túlterhelheti a zónákat DNS más vezérlőkön, ha azok a szerverünk korábbi nevét jelenítik meg.
8. Most távolítsa el a régi vezérlőnevet, amely immár nem kötelező:
NETDOM számítógépnév SRV-DC1.TEST.LOCAL /remove:SRV-DC1-OLD.TEST.LOCAL
9. Kényszerítjük vagy megvárjuk a teljes replikációt, és a végén újratöltjük és ellenőrizzük az előre és visszafelé irányuló tartományzónákat DNS a régi nevű bejegyzésekhez. Ha találunk, töröljük vagy javítjuk, ha szükséges, új névvel. Érdemes ellenőrizni a " attribútum értékét is msDS-AdditionalDnsHostName", aminek üresnek kell lennie.
Az eljárás végén, amikor a fenti lépések befejeződtek, alaposan ellenőrizzük a naplókat Active Directory minden tartományvezérlőn a hibákért és a " DCDIAG„Gondoskodunk arról, hogy az erdő megfelelően működjön.
2015 az év, elterjedt az internet, minden önmagát tisztelő cégnek már régóta saját honlapja van. Nem kell messzire menni – még minden városi kórháznak is megvan a maga webes forrása. Ennek ellenére a rendszergazdák nem tanulták meg, hogyan kell normális neveket létrehozni a tartományaikhoz.
Egy második szintű domain (például bissquit.com) költsége valamivel több mint 500 rubel évente. Ez még az olyan egyszerű polgárok számára is nagyon kevés, mint ön és én, és ezek csupán fillérek a cégeknek, annál is inkább. Jóval azelőtt vásároltam meg a domainem, hogy megjelent volna a blog elindításának ötlete. Egyszerűen kényelmes. Vegyük még távoli kapcsolat by rdp - A domain nevét írom be egy unalmas ip-cím helyett.
Az interneten az „aktív címtártartomány bevált gyakorlatai” felkérésre válaszolva szinte minden webhely átfogó ajánlásokat írt az AD tartományok elnevezésére, és elmagyarázta, miért kell ezt így tenni. Nézzük meg közelebbről, milyen ajánlásokról beszélünk:
- AD-tartomány elnevezéséhez használja szervezete hivatalosan bejegyzett domainjének aldomainjét.
Jól tetted, csak egy tanács. Ez mind! Sokat lehet beszélni a részletekről és apró árnyalatokról, de az érvelés 80-90%-a egyetlen, fentebb hangoztatott tanácsra csapódik le. Minden probléma abból adódik, hogy az ember tudja, hogy ezt meg kell tenni, de nem érti, miért lehetetlen, vagy erősen ajánlott, hogy ne tegye másként. További részletek mostantól.
1. Miért nem használhat belső, kívülről feloldhatatlan neveket, mint például .local, .corp, .lan?
Tud. Minél többet. A legtöbben használják őket. Vannak példáim az ismerősök körében, akiknek több mint 2000 embere van a szervezetekben, és a .local domaint használják. Minden nehézség akkor kezdődik, ha hirtelen szüksége van egy valódi AD-tartományra. Ez akkor fordulhat elő, ha hibrid felhőalapú telepítéseket használ (az Exchange + Office365 kiváló példa). „Miért nem nevezzük át egyszerűen a domaint, mert azzal bizonyos verzió AD ez teljesen lehetséges?” - kérdezed. Igen, elvileg lehetséges, de szembe kell néznie a domainfüggő szolgáltatások migrációjának nehézségeivel. Köztük ugyanaz az Exchange és mások, de itt egy Exchange több mint elég.
2. „Rendben, valódi külső nevet veszünk – my-company.com, akkor az AD domaint is hívjuk” – szintén nem opció. Engedélyproblémák lesznek a my-company.com webhelyen található egyéb erőforrásokkal, például a vállalat webhelyével kapcsolatban. Ezenkívül a DNS-kiszolgálók nem lesznek mérvadóak ebben a tartományban, bár annak tekintik magukat. Ez is problémákat fog okozni.
Vannak más szempontok is a domain elnevezéssel kapcsolatban, köztük egy hasonló valós tartomány létrehozása, de más TLD-ben. De úgy gondolom, hogy ennek nincs sok értelme, mert a problémák egy része továbbra is fennáll, és egyszerűen nincs nyilvánvaló előnye a corp.my-company.com domain használatához képest (a név példaként szerepel ).
Azok számára, akik szeretnek mindent a maguk módján csinálni, a közelmúltban a tanúsítványokkal kapcsolatos problémák is megjelennek, így nincs értelme a belső nevek használatának.
A domain név kiválasztásának kérdése technikailag azon a sorban nyugszik, amelybe az AD domain létrehozásakor beírja a nevet, és semmi több. A rossz névválasztás következményei azonban sok problémát okoznak a jövőben, ezért nagyon fontos, hogy már a tervezési szakaszban mindent minőségileg tegyünk. Ismét jó olvasni tapasztalt rendszergazdák cikkeit
Tegnap stúdiónk levelet kapott Andrey állandó olvasónktól, a következő kérdéssel:
Szívesen olvasom a blogodat, sok hasznos dolgot tanultam a magam számára, szerettem volna megtudni a véleményedet az Active Directory domain névről, sokan írják, hogy *szervezet*.local-nak kell nevezni, valaki pedig, hogy hívják ugyanaz, mint a domain.
Vessünk egy rövid pillantást arra, hogy mi a legjobb név a domain elnevezéséhez egy szervezeten belül.
Ahogy a gyakorlat azt mutatja, a domain név kiválasztása még egy tapasztalt embert is megzavarhat rendszergazda. Amikor először indítja el a segédprogramot dcpromo a domain név automatikusan és véletlenszerűen jön létre, ha a domain név már ebben a szakaszban nem kerül összhangba a szükséges szabályokkal, akkor a jövőben nehezebb lesz a domain név megváltoztatása. Nézzük meg a lehetőségeket népszerűségük sorrendjében.
1. Domain nevű example.local
Slágerparádénk vezére egy számra végződő domain név helyi. Vannak például más változatok is ebben a témában teszt, firma, gyár, nn, loc, stb. Most már nem is emlékszel, honnan jött ez a szerelem; a Microsoft minden könyvében mindig a saját elnevezését használja az űrlapnak contoso.com ahol tisztán láthatjuk domain névadási formátum. Azonban közel 10 éve a domain .helyi vezető pozíciót foglalt el. A helyzet kezdett kiegyenlítődni a munkájuk során igénybe vett szolgáltatások megjelenésével SSL tanúsítványok. Ahol a "nem érdekel, és így lesz" domainek használata lehetetlenné válik. Nézze, tegyük fel, hogy cége belsőleg használja Exchange szerver, amelynek ssl-tanúsítványra van szüksége az ügyfélkapcsolatok titkosításához. Az Ön forgatókönyve szerint a feladat elvégzéséhez tanúsítványra van szüksége külső CA, amelyben meg kell adnia a használt kiszolgálók összes nevét külső csatlakozás. Úgy tűnik, hogy egy ilyen dolog, felírjuk az összes szerver nevét, és kérelmezzük a tanúsítványok kiadását, de van egy dolog. Egy ilyen domain nevével nem fogja tudni érvényesíteni, mivel a „nem érdekel, és így lesz” tartomány nem létezik, és halkan elutasítják, hogy megpróbálja elmagyarázni egy külső tanúsító hatóságnak, hogy egy nem létező tartomány FQDN-nevét kell beírnia a SAN-ba. :
Ez nem lehetséges, csak valódi domain nevekre adunk ki tanúsítványt.
De van még egy baj. Domain név használata nem a te tulajdonod egy domain névben katasztrofális következményekkel járhat. Képzeld el a helyzetet, ha a zóna helyi nyilvános lesz. Mint egy zóna com vagy hu. Nem hiszem, hogy érdemes folytatni.
2. A tartománynév megegyezik a külső tartománynévvel
Slágerparádénk második helye. Annak ellenére, hogy egy ilyen forgatókönyv kevésbé népszerű, mégis joga van az élethez. Amellett, hogy a közeljövőben még mindig kellemetlenségeket fog okozni a hálózat karbantartása során, semmi más nem fenyegeti. A fő probléma ebben a forgatókönyvben az, hogy két DNS-kiszolgálót kell karbantartania: belső és külső. Ilyen feltételek mellett a hálózaton belüli számítógépek a belső DNS-kiszolgálót fogják használni a névfeloldáshoz, a vállalat határán kívüli számítógépek pedig egy külsőt. Tegyük fel, hogy a domainjének büszke neve van example.com. BAN BEN DMZ zónád van weboldal nevű cégek example.com. A fent leírt forgatókönyv szerint a számítógépek találhatók belül szervezetek nem lehet hozzáférni, mert számukra az example.com az domain névés amikor beírod ezt a címet a böngészőbe, akkor a címre fognak menni tartományvezérlő. Mint fentebb megjegyeztem, a kényelmetlenségen kívül ez semmihez sem vezet. Mindig használhat olyan mankókat, amelyek átirányítják Önt egy külső webhelyre, de elfogadja, hogy ez nem szükséges kettős munka, vagy használjon olyan webhelynevet, amely www vagy azon kívül.
3. Egyszavas domain név
Talán a leghelytelenebb lehetőség a fentiek közül. Egyszintű domainek: Egycímkés domain egy olyan domain, amely csak a egy komponens. Nyilvánvalóan az NT idejében kezdték használni, amikor a Microsoft átvette a Novell sikeres tapasztalatait. Történt ugyanis, hogy kezdetben én voltam a FreeBSD és a NetWare szerverek nagy flottája adminisztrátora a 4.11-es verziótól kezdve, így azokban az ókorban a NetWare a Binderyt használta a munkájában, ami csak a nevek. egyszintű tartomány séma, amelyet később a Microsoft átvett.
legjobb gyakorlatok
Ideje összefoglalni. Milyen domain nevet használjunk? Csak egy harmadik szintű domain az Ön tulajdonában lévő domainben. Ne használd mások szebbnél szebb domain neveit :-). Az alábbiakban láthat egy példát egy ilyen domainre.
Mi az a tartományvezérlő
A tartományvezérlő központosított felügyeletet biztosít hálózati eszközök, azaz domainek. A vezérlő tárolja a hálózati felhasználók fiókjaiból és beállításaiból származó összes információt. Ezek a biztonsági beállítások helyi politikaés sokan mások. Ez egy olyan kiszolgáló, amely teljes ellenőrzést gyakorol egy adott hálózat vagy hálózati csoport felett. A tartományvezérlő egyfajta speciális szoftver, amely különféle Active Directory-szolgáltatásokat futtat. A vezérlők bizonyos operációs rendszereket futtatnak, mint pl Windows szerver 2003. Az Active Drive Setup Wizard lehetővé teszi tartományvezérlők létrehozását.
BAN BEN operációs rendszer A Windows NT a PDC-t használja elsődleges kiszolgálóként. A többi használt szervert tartalék vezérlőként használnak. A fő PDC vezérlők különféle feladatokat hajthatnak végre a felhasználói csoporttagsággal, jelszavak létrehozásával és módosításával, felhasználók hozzáadásával és sok mással kapcsolatban. Ezt követően az adatokat további BDC vezérlőkhöz továbbítják.
Használható tartományvezérlőként szoftver Samba 4, ha Unix operációs rendszer telepítve van. Ez a szoftver más operációs rendszereket is támogat, mint például a Windows 2003, 2008, 2003 R2 és 2008 R2. Az operációs rendszerek mindegyike, ha szükséges, bővíthető az egyedi követelmények és paraméterek függvényében.
Domainvezérlők alkalmazása
A tartományvezérlőket sok olyan szervezet használja, amelyek egymáshoz és a hálózathoz kapcsolódó számítógépeket üzemeltetnek. A vezérlők címtáradatokat tárolnak, és szabályozzák, hogy a felhasználók hogyan jelentkezzenek be, kijelentkezzenek, és hogyan lépjenek kapcsolatba egymással.
A tartományvezérlőt használó szervezeteknek el kell dönteniük, hogy hány tartományvezérlőt fognak használni, meg kell tervezniük az adatarchiválást, a fizikai biztonságot, a szerverfrissítéseket és egyéb szükséges feladatokat.
Ha egy cég vagy szervezet kicsi, és csak egy tartományi hálózatot használ, akkor elegendő két olyan vezérlő használata, amelyek nagy stabilitást, hibatűrést és magas szintű hálózati rendelkezésre állást biztosítanak. Olyan hálózatokban, amelyek fel vannak osztva bizonyos mennyiségű telephelyekre, mindegyikre egy-egy vezérlő van telepítve, amely lehetővé teszi a szükséges teljesítmény és megbízhatóság elérését. Az egyes webhelyeken vezérlők használatával a felhasználói bejelentkezés sokkal egyszerűbbé és gyorsabbá tehető.
A hálózati forgalom optimalizálható, ehhez be kell állítani a replikációs frissítések idejét, amikor a hálózat terhelése minimális. A replikáció beállítása nagymértékben leegyszerűsíti a munkáját, és hatékonyabbá teszi azt.
Maximális teljesítményt érhet el a vezérlő munkájában, ha a tartomány egy globális katalógus, amely lehetővé teszi az objektumok meghatározott súly szerinti lekérdezését. Fontos azonban megjegyezni, hogy a globális katalógus engedélyezése a replikációs forgalom jelentős növekedését eredményezi.
A gazdagép tartományvezérlőt a legjobb, ha nem engedélyezi, ha egynél több tartományvezérlőt használ. A tartományvezérlő használatakor nagyon fontos ügyelni a biztonságra, mert eléggé hozzáférhetővé válik azon támadók számára, akik a megtévesztéshez szükséges adatokat szeretnék birtokba venni.
További tartományvezérlők telepítésének szempontjai
A nagyobb működési megbízhatóság elérése érdekében a szükséges hálózati szolgáltatások, további tartományvezérlőket kell telepítenie. Ennek eredményeként lényegesen nagyobb stabilitás, megbízhatóság és üzembiztonság érhető el. A hálózati teljesítmény ebben az esetben sokkal nagyobb lesz, ami nagyon fontos paraméter a tartományvezérlőt használó szervezetek számára.
Ahhoz, hogy a tartományvezérlő megfelelően működjön, el kell végezni néhány előkészítő munkát. Első lépésként ellenőrizni kell a TCP/IP beállításokat, ezeket megfelelően be kell állítani a szerverhez. A legfontosabb dolog a DNS-nevek leképezéseinek ellenőrzése.
Mert biztonságos munkavégzés A tartományvezérlőnek az NTFS fájlrendszert kell használnia, amely biztonságosabb, mint a FAT 32 fájlrendszer. NTFS rendszer, amely a rendszer kötetét fogja tartalmazni. A DNS-kiszolgálóhoz való hozzáférés is szükséges a szerverről. DNS szolgáltatás telepítve erre vagy egy további kiszolgálóra, amelynek támogatnia kell az erőforrásrekordokat.
A tartományvezérlő megfelelő konfigurálásához használhatja a Konfigurációs varázslót, amely lehetővé teszi bizonyos szerepkörök végrehajtásának hozzáadását. Ehhez a vezérlőpulton keresztül az adminisztrációs részre kell lépnie. Meg kell adnia egy tartományvezérlőt kiszolgálói szerepként.
A tartományvezérlő manapság nélkülözhetetlen a különféle szervezetek, intézmények és cégek által használt hálózatokhoz és oldalakhoz az emberi tevékenység minden területén. Neki köszönhetően a munkavégzés és a biztonság magas termelékenysége biztosított, ami be számítógépes hálózatok különös jelentőséggel bír. A tartományvezérlő szerepe nagyon fontos, mert lehetővé teszi a számítógépes hálózatokra épített tartományi területek kezelését. Minden operációs rendszernek vannak bizonyos árnyalatai a tartományvezérlők működésével kapcsolatban, de az elv és a célja mindenhol ugyanaz, így a beállítások kezelése nem olyan nehéz, mint amilyennek az elején tűnhet. Nagyon fontos azonban, hogy a tartományvezérlőket szakértők konfigurálják, hogy végső soron nagy teljesítményt és biztonságot érjenek el működés közben.