Globális katalógus (global catalog): szerepe és működése az Active Directoryban

A globális katalógus az Active Directory egyik fontos eleme, amely gyors keresést és adat-hozzáférést tesz lehetővé a hálózaton belül. Segít megtalálni a felhasználókat és erőforrásokat, így hatékonyabbá teszi a rendszergazdák munkáját és a hálózat működését.
ITSZÓTÁR.hu
42 Min Read

Az Active Directory (AD) a Microsoft operációs rendszerek alapvető címtárszolgáltatása, amely központi helyen tárolja és kezeli a hálózati erőforrásokat, például a felhasználókat, számítógépeket, csoportokat és egyéb objektumokat. Egy összetett AD környezetben, ahol több tartomány is létezik egy erdőn (forest) belül, szükségessé válik egy olyan mechanizmus, amely lehetővé teszi a felhasználók és alkalmazások számára az adatok hatékony elérését, függetlenül attól, hogy melyik tartományban található az adott objektum. Itt lép be a képbe a globális katalógus (global catalog), amely az Active Directory egyik legkritikusabb és legkevésbé értett komponense.

A globális katalógus nem csupán egy egyszerű adatbázis; sokkal inkább egy stratégiai fontosságú információs központ, amely alapvető szerepet játszik a felhasználók bejelentkezésében, az objektumok keresésében és az általános Active Directory funkcionalitás fenntartásában. Nélkülözhetetlen a modern, elosztott hálózati infrastruktúrákban, ahol a felhasználóknak zökkenőmentesen kell hozzáférniük a különböző tartományokban található erőforrásokhoz. A GC nélkül az erdőn belüli tartományok közötti interakciók rendkívül bonyolulttá, lassúvá és gyakran lehetetlenné válnának, ami súlyosan rontaná a felhasználói élményt és a rendszergazdai feladatok hatékonyságát.

Az Active Directory erdő egy logikai egység, amely egy vagy több tartományt foglal magában, és ezek a tartományok osztoznak egy közös sémán (schema), konfigurációs partíción és globális katalóguson. Minden tartomány rendelkezik saját tartományvezérlőkkel (Domain Controller, DC), amelyek a tartományhoz tartozó objektumokról tárolnak teljes másolatot. Azonban egy felhasználó, aki egy adott tartományban szeretne keresni egy másik tartományban lévő erőforrást, nem tudja közvetlenül lekérdezni az összes tartományvezérlőt. Erre a problémára nyújt megoldást a globális katalógus.

Mi a globális katalógus: alapvető fogalmak és szerepköre

A globális katalógus (GC) egy speciális célú tartományvezérlő, vagy pontosabban, egy olyan szolgáltatás, amelyet egy tartományvezérlő futtat. Az Active Directory erdőben legalább egy tartományvezérlőnek globális katalógusként kell működnie. Fő célja, hogy egy kereshető indexet biztosítson az erdő összes objektumáról, függetlenül attól, hogy melyik tartományban találhatók. Ez egyfajta „telefonkönyvként” funkcionál az Active Directory számára, lehetővé téve a gyors és hatékony keresést az egész erdőben.

A GC nem tárolja az összes attribútumot az erdő összes objektumáról. Ehelyett egy részleges attribútumkészletet (Partial Attribute Set, PAS) tartalmaz minden tartományból származó objektumra vonatkozóan. Ez a PAS magában foglalja azokat az attribútumokat, amelyeket a leggyakrabban használnak a keresésekhez és a bejelentkezési folyamatokhoz. Ilyenek például a felhasználók nevei, e-mail címei, bejelentkezési nevei (User Principal Name, UPN), csoporttagságai és egyéb alapvető azonosítók. Az, hogy mely attribútumok kerülnek a PAS-ba, a séma szintjén van meghatározva, és módosítható is, bár ez ritka és körültekintést igényel.

A globális katalógusnak két elsődleges funkciója van:

  1. Erdő-szintű keresés: Lehetővé teszi a felhasználók és alkalmazások számára, hogy objektumokat keressenek az erdő bármely tartományában anélkül, hogy tudnák, melyik tartományban találhatók. Amikor egy keresési lekérdezés érkezik a GC-hez, az a PAS-ban tárolt információk alapján azonnal képes válaszolni, vagy ha a keresett attribútum nincs a PAS-ban, akkor átirányíthatja a kérést az adott objektumot tartalmazó tartományvezérlőhöz.
  2. Bejelentkezési folyamat támogatása: A globális katalógus létfontosságú a felhasználók bejelentkezéséhez, különösen akkor, ha a felhasználó egy másik tartományban lévő tartományvezérlőhöz próbál bejelentkezni, mint ahol a felhasználói fiókja található. A GC biztosítja az UPN alapú bejelentkezések működését, és ellenőrzi a felhasználók univerzális csoporttagságait, amelyek a bejelentkezési token részét képezik.

Fontos megérteni, hogy minden tartományvezérlő a saját tartományának teljes címtárát tárolja. Amikor egy tartományvezérlő globális katalógussá válik, akkor ezen felül replikálja a PAS-t az erdő összes többi tartományából. Ezáltal egy átfogó, de nem teljes képet kap az egész erdőről. A GC tehát egy gyorsítótárazott, erdő-szintű nézet az Active Directoryról, optimalizálva a keresési és bejelentkezési feladatokra.

A globális katalógus az Active Directory erdő központi idegrendszere, amely biztosítja a zökkenőmentes kommunikációt és az adatokhoz való hozzáférést a tartományok között.

A globális katalógus működése és felépítése

A globális katalógus működési elve a replikáción és a részleges attribútumkészleten (PAS) alapul. Ahhoz, hogy egy tartományvezérlő globális katalógussá váljon, be kell jelölni ezt a szerepkört az Active Directory Sites and Services konzolon keresztül. Ezt követően a DC elkezdi replikálni a PAS-t az erdő összes többi tartományából.

Részleges attribútumkészlet (Partial Attribute Set – PAS)

A PAS az Active Directory séma része. Minden attribútumnak van egy tulajdonsága, az úgynevezett isMemberOfPartialAttributeSet, amely meghatározza, hogy az adott attribútum bekerüljön-e a globális katalógusba. Alapértelmezés szerint számos gyakran használt attribútum már be van jelölve a PAS-ba. Ezek közé tartoznak például a displayName, sAMAccountName, userPrincipalName, mail, objectGUID, memberOf, és sok más.

Amikor egy tartományvezérlő GC-vé válik, a replikációs folyamat során összegyűjti ezeket a kijelölt attribútumokat az erdő összes tartományának replikált címtárpartícióiból. Ez a folyamat időigényes lehet, különösen nagy erdők és sok tartományvezérlő esetén. A PAS mérete jelentősen befolyásolja a GC tárhelyigényét és a replikációs forgalmat. Ezért fontos, hogy csak olyan attribútumokat tegyünk a PAS-ba, amelyekre valóban szükség van erdő-szintű keresésekhez vagy bejelentkezéshez.

Replikáció a globális katalógusok között

A globális katalógusok közötti replikáció az Active Directory replikációs topológiájának szerves része. A tartományvezérlők közötti replikáció alapvetően két típusú:

  1. Intrasite replikáció: Ugyanazon a telephelyen (site) belül a tartományvezérlők gyakran replikálják egymással az adatokat, tipikusan 15 másodpercenként, ha változás történt. Ez biztosítja a gyors konzisztenciát a helyi hálózaton.
  2. Intersite replikáció: Különböző telephelyek (site-ok) között a replikációt tipikusan site linkeken keresztül végzik, és gyakorisága konfigurálható (pl. 3 óránként). Ez a forgalom általában tömörített.

A GC-k a saját tartományuk teljes adatbázisát (NTDS.DIT) tárolják, plusz a PAS-t a többi tartományból. Ez azt jelenti, hogy egy GC-nek replikálnia kell a saját tartományának összes változását a többi GC-vel, és a többi tartomány változásait (csak a PAS attribútumokat) is be kell fogadnia. Ez a kétirányú replikáció biztosítja, hogy minden GC konzisztens és naprakész legyen az erdő egészére vonatkozóan.

A replikációs folyamat során a GC-k a USN (Update Sequence Number) rendszert használják a változások nyomon követésére. Minden változás egyedi USN-t kap, és a DC-k ezen USN-ek alapján tudják, mely változásokat kell még replikálniuk. Ha egy GC elmarad a replikációval, az adatok elavulttá válhatnak, ami bejelentkezési vagy keresési problémákhoz vezethet.

LDAP portok a GC számára

A kliensek az LDAP (Lightweight Directory Access Protocol) protokollon keresztül kommunikálnak az Active Directoryval. A globális katalógushoz való hozzáféréshez két speciális portot használnak:

  • 3268/TCP: Ez a standard LDAP port a globális katalógushoz. A kliensek ezen a porton keresztül küldenek lekérdezéseket a GC-nek, ha erdő-szintű keresést végeznek, vagy ha UPN-nel próbálnak bejelentkezni.
  • 3269/TCP: Ez az SSL/TLS titkosított LDAP port a globális katalógushoz. Hasonlóan a 3268-hoz, de biztonságos kommunikációs csatornát biztosít, ami különösen fontos érzékeny adatok lekérdezésénél vagy hitelesítési folyamatoknál.

Amikor egy kliens egy tartományvezérlőt keres, a DNS-t használja. A tartományvezérlők regisztrálják a szolgáltatási rekordjaikat (SRV rekordok) a DNS-ben, amelyek tartalmazzák a DC-k nevét, IP-címét és az általuk nyújtott szolgáltatásokat, beleértve a GC szolgáltatást is. Például egy _gc._tcp.DomainName SRV rekord mutat a globális katalógusra.

Egy tipikus forgatókönyv szerint, amikor egy felhasználó bejelentkezik egy számítógépre, a számítógép megpróbál egy tartományvezérlőt találni a saját site-jában. Ha talál egy GC-t, akkor azt fogja preferálni a bejelentkezéshez, különösen ha UPN-nel történik a bejelentkezés, vagy ha univerzális csoporttagságot kell ellenőrizni. Ha nincs GC a site-on, akkor a kliens megpróbál egy GC-t találni egy másik site-ban, ami hálózati késleltetést okozhat.

Jellemző Hagyományos tartományvezérlő (DC) Globális katalógus (GC)
Tartalom Saját tartomány teljes címtárpartíciója Saját tartomány teljes címtárpartíciója + részleges attribútumkészlet (PAS) az erdő összes tartományából
Portok 389 (LDAP), 636 (LDAPS), 88 (Kerberos), 53 (DNS) stb. 389 (LDAP), 636 (LDAPS), 88 (Kerberos), 53 (DNS), 3268 (GC LDAP), 3269 (GC LDAPS) stb.
Fő funkció Tartomány-specifikus autentikáció, autorizáció, replikáció Erdő-szintű keresés, UPN bejelentkezés, univerzális csoporttagság ellenőrzés
Szerepkör Minden tartományvezérlő Legalább egy DC az erdőben, de javasolt minden site-ban

A GC felépítése és működése alapvetően befolyásolja az Active Directory teljesítményét és megbízhatóságát. Egy rosszul tervezett vagy hiányos GC infrastruktúra súlyos problémákhoz vezethet a felhasználói bejelentkezésben és az erőforrások elérhetőségében.

A globális katalógus szerepe a bejelentkezési folyamatban

A felhasználói bejelentkezés az Active Directory egyik leggyakoribb és legkritikusabb művelete. A globális katalógus létfontosságú szerepet játszik ebben a folyamatban, különösen a modern, összetett Active Directory környezetekben. Két fő területen elengedhetetlen a GC jelenléte a sikeres bejelentkezéshez: az UPN alapú bejelentkezések és az univerzális csoporttagságok ellenőrzése.

UPN (User Principal Name) alapú bejelentkezések

Az UPN egy olyan felhasználói azonosító, amely a felhasználó bejelentkezési nevét és az UPN utótagot tartalmazza (pl. felhasznalo@domain.com). Az UPN utótag általában a DNS tartománynévvel egyezik, de lehet attól eltérő is, és egy erdőn belül több UPN utótag is létezhet. Az UPN-ek használata növeli a rugalmasságot, mivel a felhasználóknak nem kell tudniuk, hogy melyik Active Directory tartományban található a fiókjuk.

Amikor egy felhasználó UPN-nel próbál bejelentkezni, a kliensnek meg kell találnia azt a tartományvezérlőt, amely a felhasználó fiókját tartalmazza. Mivel az UPN utótag nem feltétlenül egyezik a DNS tartománynévvel, és a felhasználói fiók bármely tartományban lehet az erdőn belül, a kliens nem tudja közvetlenül a DNS alapján megkeresni a megfelelő tartományvezérlőt. Itt jön képbe a globális katalógus.

A kliens lekérdezi a legközelebbi globális katalógust a 3268-as (vagy 3269-es, ha titkosított) porton keresztül, és megkérdezi, hogy melyik tartomány tartalmazza a megadott UPN-hez tartozó felhasználói fiókot. Mivel a GC a PAS részeként tárolja az összes felhasználó UPN-jét az erdőből, gyorsan meg tudja válaszolni ezt a lekérdezést, és visszaküldi a felhasználói fiók tartományának nevét. Ezt követően a kliens már tudja, melyik tartományvezérlőhöz kell fordulnia a Kerberos hitelesítési folyamat befejezéséhez.

A globális katalógus nélkül az UPN alapú bejelentkezések nem működnének hatékonyan, ami jelentősen rontaná a felhasználói élményt és a hálózati rugalmasságot.

Univerzális csoporttagságok ellenőrzése

Az Active Directoryban háromféle csoporttípus létezik: tartományi helyi (Domain Local), globális (Global) és univerzális (Universal). Az univerzális csoportok különlegesek abban a tekintetben, hogy tagjai lehetnek az erdő bármely tartományából származó felhasználók és csoportok, és tagjai lehetnek más univerzális, globális és tartományi helyi csoportoknak is. Ezek a csoportok az erdő bármely tartományában használhatók erőforrás-hozzáférés biztosítására.

Amikor egy felhasználó bejelentkezik, a tartományvezérlő létrehoz egy hozzáférési tokent (access token) a felhasználó számára. Ez a token tartalmazza a felhasználó biztonsági azonosítóját (SID), valamint az összes olyan csoport SID-jét, amelynek a felhasználó tagja. Ahhoz, hogy a tartományvezérlő pontosan összeállítsa ezt a tokent, tudnia kell a felhasználó összes univerzális csoporttagságát is.

Mivel az univerzális csoporttagságok az erdő egészére vonatkoznak, és egy felhasználó bármely tartományban tagja lehet egy univerzális csoportnak, a tartományvezérlőnek szüksége van egy központi helyre, ahol ezek az információk elérhetők. Ezt a feladatot látja el a globális katalógus. A GC tárolja az összes univerzális csoport tagsági adatait a PAS részeként. Amikor egy felhasználó bejelentkezik, a hitelesítést végző tartományvezérlő lekérdezi a GC-t, hogy megkapja a felhasználó összes univerzális csoporttagságát, és beépítse azokat a hozzáférési tokenbe.

Ha egy tartományvezérlő nem tudja elérni egy globális katalógust a bejelentkezési folyamat során, akkor nem tudja ellenőrizni a felhasználó univerzális csoporttagságait. Ennek következtében a felhasználó csak a tartományi helyi és globális csoportokhoz tartozó jogokkal jelentkezhet be, és nem kapja meg az univerzális csoportokon keresztül biztosított jogosultságokat. Ez súlyos hozzáférési problémákhoz vezethet, mivel a felhasználók nem férnek hozzá azokhoz az erőforrásokhoz, amelyekhez elvileg jogosultak lennének.

Ez a jelenség az úgynevezett „universal group caching” probléma. Régebbi Windows Server verziókban (pl. Windows 2000) a GC elérhetetlensége teljes bejelentkezési hibát okozhatott. A későbbi verziókban (Windows Server 2003 és újabb) bevezették a „universal group caching” funkciót, ami azt jelenti, hogy a tartományvezérlő ideiglenesen gyorsítótárazza az univerzális csoporttagságokat, így ha a GC átmenetileg nem elérhető, a felhasználók még be tudnak jelentkezni, de a gyorsítótárazott információk elavultak lehetnek.

Összességében a globális katalógus kritikus a bejelentkezési folyamat zökkenőmentességéhez és a jogosultságok helyes érvényesítéséhez. Egy megfelelően működő és elérhető GC nélkül az Active Directory környezet súlyos funkcionalitási és biztonsági problémákkal küzdhet.

A globális katalógus szerepe a keresésben

A globális katalógus gyorsítja a keresést az egész erdőben.
A globális katalógus gyorsítja a keresést az Active Directoryban azáltal, hogy az összes tartomány adatait összegzi.

Az Active Directory erdőben a felhasználók és alkalmazások gyakran keresnek objektumokat, például felhasználói fiókokat, csoportokat, nyomtatókat vagy megosztott mappákat. Egy nagy, több tartományból álló erdőben a GC nélkül rendkívül nehézkes lenne ezeket a kereséseket hatékonyan elvégezni. A globális katalógus biztosítja a gyors, erdő-szintű keresési képességet.

Erdő-szintű keresés és az LDAP lekérdezések

Amikor egy alkalmazás vagy felhasználó keres egy objektumot az Active Directoryban, és nem tudja, melyik tartományban található az adott objektum, akkor a keresést a globális katalógushoz irányítja. Ez történhet explicit módon (például egy LDAP lekérdezés a 3268-as porton keresztül), vagy implicit módon, amikor egy alkalmazás, például az Outlook, megpróbál egy felhasználót feloldani a globális címlistából (Global Address List, GAL).

A GC a PAS-ban tárolt attribútumok alapján képes gyorsan válaszolni a lekérdezésekre. Például, ha valaki egy felhasználót keres az e-mail címe alapján (mail attribútum), és az mail attribútum része a PAS-nak, akkor a GC azonnal vissza tudja adni az eredményt, függetlenül attól, hogy a felhasználó melyik tartományban található. Ez sokkal gyorsabb, mintha az összes tartományvezérlőt végig kellene kérdezni.

Ha egy keresés olyan attribútumra vonatkozik, amely nem része a PAS-nak, akkor a GC nem tudja közvetlenül megválaszolni a lekérdezést. Ebben az esetben a GC a keresést átirányíthatja (referral) az adott objektumot tartalmazó tartományvezérlőhöz, amely a teljes címtárpartícióval rendelkezik, és így képes lesz válaszolni a lekérdezésre. Ez a folyamat azonban lassabb, mivel egy további hálózati körutat igényel.

Az LDAP lekérdezések a GC-n keresztül történő keresés alapját képezik. Az LDAP kliensek a 3268-as vagy 3269-es portot célozzák meg, amikor GC-specifikus keresést akarnak végezni. Az LDAP lekérdezések komplex szűrőket is tartalmazhatnak, amelyek lehetővé teszik a nagyon specifikus objektumok megtalálását az erdőben. Például, egy lekérdezés kereshet minden felhasználót, aki egy adott városban él, vagy minden számítógépet, amely egy bizonyos operációs rendszert futtat.

Az Outlook, az Exchange Server és más Microsoft alkalmazások széles körben használják a globális katalógust a címlista feloldásához és a felhasználók kereséséhez. Amikor egy felhasználó megnyitja az Outlookot, az alapértelmezett globális címlista (GAL) a GC-ből származó adatokat jeleníti meg. Ez biztosítja, hogy a felhasználók lássák az erdő összes felhasználóját és csoportját, függetlenül attól, hogy melyik tartományban vannak.

Mikor használjuk a GC-t és mikor nem?

A GC-t akkor használjuk, ha:

  • Erdő-szintű keresést végzünk, és nem tudjuk, melyik tartományban van az objektum.
  • UPN-nel próbálunk bejelentkezni.
  • Az univerzális csoporttagságokat kell ellenőrizni a bejelentkezés során.
  • Az Exchange Server vagy más alkalmazás globális címlistát kérdez le.
  • Az alkalmazás explicit módon lekérdezi a 3268/3269-es portot egy tartományvezérlőn.

Nem használjuk a GC-t, ha:

  • Egy specifikus tartományon belüli objektumot keresünk, és tudjuk, melyik tartományról van szó. Ebben az esetben a tartományvezérlő 389-es (vagy 636-os) portját célozzuk meg.
  • Olyan attribútumokat kérdezünk le, amelyek nem részei a PAS-nak, és nem is tervezzük hozzáadni őket. Bár a GC átirányíthatja a kérést, hatékonyabb lehet közvetlenül a tartományvezérlőt célozni.

A globális katalógus optimalizálja a keresési folyamatokat, de az is fontos, hogy a fejlesztők és rendszergazdák megértsék, mikor érdemes használni, és mikor nem. A felesleges GC lekérdezések terhelhetik a GC-t és a hálózatot, míg a szükséges GC lekérdezések hiánya funkcionalitási problémákhoz vezethet.

Globális katalógus tervezése és elhelyezése

A globális katalógusok megfelelő tervezése és elhelyezése kulcsfontosságú az Active Directory környezet optimális teljesítményéhez és megbízhatóságához. A rossz tervezés lassú bejelentkezésekhez, késedelmes keresésekhez és általános hálózati torlódáshoz vezethet. Néhány alapvető szempontot figyelembe kell venni a tervezés során.

Hány GC szükséges és hol legyenek elhelyezve?

Általános szabály, hogy minden Active Directory telephelyen (site) legalább egy globális katalógust kell elhelyezni. Ennek oka, hogy a GC létfontosságú a bejelentkezési folyamathoz (különösen UPN és univerzális csoportok esetén) és az erdő-szintű keresésekhez. Ha egy site-ban nincs GC, a klienseknek egy másik site-ban lévő GC-hez kell fordulniuk, ami:

  • Növeli a hálózati forgalmat a site-ok között.
  • Növeli a bejelentkezési késleltetést, mivel a kérésnek át kell utaznia a WAN-on.
  • Csökkenti a rendelkezésre állást, mert ha a WAN kapcsolat megszakad, a felhasználók nem tudnak bejelentkezni vagy hozzáférni a GC által biztosított szolgáltatásokhoz.

Nagyobb site-okon, ahol sok felhasználó vagy alkalmazás van, érdemes lehet több GC-t is elhelyezni a terheléselosztás (load balancing) és a hibatűrő képesség (fault tolerance) növelése érdekében. A GC-k számát a felhasználók száma, a keresési lekérdezések gyakorisága, a hálózati sávszélesség és a rendelkezésre álló hardver határozza meg. Javasolt, hogy minden tartományvezérlő, amely a FSMO (Flexible Single Master Operations) szerepkörök valamelyikét is birtokolja (különösen a Schema Master és a Domain Naming Master), legyen GC is, mivel ezek a szerepkörök az erdő szintjén működnek.

Telephelyek (sites) és alhálózatok szerepe

Az Active Directory telephelyek (sites) a hálózati topológia logikai reprezentációi. A site-okat úgy kell kialakítani, hogy azok a gyors, nagy sávszélességű hálózati kapcsolatokkal rendelkező alhálózatokat csoportosítsák. A GC-k elhelyezésénél kritikus, hogy minden site-ban legyen legalább egy, hogy a kliensek helyben találjanak GC-t, minimalizálva a WAN forgalmat és a késleltetést.

A kliensek az Active Directory site-jukat az IP-címük alapján határozzák meg. Amikor egy kliens tartományvezérlőt keres (pl. bejelentkezéskor), először a saját site-jában lévő DC-ket és GC-ket próbálja megkeresni a DNS SRV rekordok alapján. Ha nem talál helyi GC-t, akkor keres egyet más site-okban, ami lassulást okoz.

Hálózati forgalomra gyakorolt hatás

A GC-k jelentős hatással lehetnek a hálózati forgalomra, különösen a replikáció miatt. Minél több GC van az erdőben, annál több replikációs forgalom keletkezik a GC-k között, mivel mindegyiknek szinkronban kell lennie a PAS-sal az erdő összes többi tartományából. Ezenkívül, ha sok attribútumot adunk hozzá a PAS-hoz, az növeli a PAS méretét, ami szintén növeli a replikációs forgalmat és a GC-k tárhelyigényét.

A tervezés során figyelembe kell venni a site-ok közötti WAN linkek sávszélességét. Ahol a sávszélesség korlátozott, ott kevesebb GC-t érdemes elhelyezni, vagy optimalizálni kell a replikációs ütemezést. Azonban a túl kevés GC is problémát jelenthet, mivel a felhasználók kérései a WAN-on keresztül terhelik a hálózatot.

A replikációs topológia alapvető fontosságú. Az Active Directory automatikusan létrehozza a replikációs kapcsolatokat (Knowledge Consistency Checker, KCC), de manuálisan is beavatkozhatunk, ha szükséges (pl. site linkek, site link bridges konfigurálása). A hatékony replikáció biztosítja, hogy a GC-k adatai naprakészek maradjanak, ami elengedhetetlen a pontos bejelentkezéshez és keresésekhez.

A GC-k elhelyezésének optimalizálása egyensúlyozást jelent a hálózati sávszélesség, a rendelkezésre állás és a teljesítmény között.

Hardver követelmények

Mivel a GC-k a tartomány teljes címtárát és az erdő PAS-át is tárolják, a tárhelyigényük nagyobb lehet, mint egy csak tartományvezérlőként működő DC-nek. Nagy erdőkben a NTDS.DIT fájl mérete több tíz vagy akár több száz gigabájt is lehet. Ennek megfelelően a GC-t futtató szervereknek elegendő tárhellyel (gyors SSD-k javasoltak) és elegendő RAM-mal kell rendelkezniük a címtár gyorsítótárazásához. A CPU terhelés is megnőhet a keresési lekérdezések és a replikáció miatt.

A tervezés során célszerű figyelembe venni a jövőbeli növekedést is. Az Active Directory környezetek általában idővel nőnek, új felhasználók és objektumok kerülnek hozzáadásra, ami növeli a GC-k terhelését és tárhelyigényét. A megfelelő előzetes tervezés elkerülheti a későbbi teljesítményproblémákat és a költséges hardverfrissítéseket.

Teljesítmény és optimalizálás

A globális katalógus teljesítménye kritikus az Active Directory környezet egészének szempontjából. A lassú GC-k bejelentkezési késedelmeket, lassú alkalmazásműködést és általános felhasználói elégedetlenséget okozhatnak. Az optimalizálás magában foglalja a GC méretének kezelését, a replikációs folyamatok finomhangolását, a hardver megfelelő kiválasztását és a folyamatos monitorozást.

GC mérete és attribútumok kezelése

A globális katalógus méretét (az NTDS.DIT fájl méretét) elsősorban az objektumok száma és a Partial Attribute Set (PAS) mérete határozza meg. Minél több objektum van az erdőben, és minél több attribútum van kijelölve a PAS-hoz, annál nagyobb lesz a GC adatbázisa. Egy nagyobb GC adatbázis több tárhelyet igényel, és növeli a replikációs forgalmat.

Az attribútumok hozzáadása a PAS-hoz csak akkor javasolt, ha arra feltétlenül szükség van erdő-szintű keresésekhez vagy alkalmazásfunkciókhoz. Minden egyes hozzáadott attribútum növeli a GC-k replikációs terhelését és a tárhelyigényt minden GC-n az erdőben. Az attribútumok hozzáadása a PAS-hoz a séma módosításával történik, ami érzékeny művelet, és alapos tesztelést igényel.

A séma módosításához a Schema Master FSMO szerepkörrel rendelkező tartományvezérlőn kell elvégezni a műveletet. Az attribútum tulajdonságainál kell beállítani az isMemberOfPartialAttributeSet értéket TRUE-ra. Ezt követően a változás replikálódik az összes GC-re, amelyek elkezdenek replikálni az új attribútumot. Ez a folyamat időigényes lehet, és átmenetileg növelheti a hálózati forgalmat.

A GC méretének monitorozása (az NTDS.DIT fájl mérete) segíthet azonosítani a problémákat. Ha a fájl mérete váratlanul megnő, az jelezheti, hogy felesleges attribútumok kerültek a PAS-ba, vagy hogy az objektumok száma gyorsabban növekszik, mint ahogy azt tervezték.

Replikáció optimalizálása

A GC-k közötti replikáció hatékonysága alapvető a naprakész adatok biztosításához. Az Active Directory Sites and Services konzolon keresztül konfigurálhatók a site linkek és a replikációs ütemezések. Nagy sávszélességű hálózatokon a replikáció gyakorisága növelhető, míg korlátozott sávszélességű WAN linkeken csökkenteni lehet a replikációs intervallumot, vagy beállítható a replikációs ablak, hogy az a csúcsidőn kívül történjen.

A KCC (Knowledge Consistency Checker) automatikusan létrehozza a replikációs topológiát, de bizonyos esetekben manuális beavatkozásra lehet szükség (pl. ha speciális hálózati topológiát használnak, vagy ha a KCC nem tud optimális útvonalat találni). A replikációs hibák monitorozása (pl. az Event Viewerben a Directory Service események figyelése) kulcsfontosságú a problémák időben történő azonosításához és javításához.

Hardver követelmények és monitorozás

A GC-k, mint minden tartományvezérlő, megfelelő hardveres erőforrásokat igényelnek:

  • RAM: Az NTDS.DIT adatbázis lehetőleg teljes egészében elférjen a RAM-ban a gyors hozzáférés érdekében. Minél több RAM van, annál kevesebb lemezművelet szükséges, ami jelentősen javítja a teljesítményt.
  • CPU: Elegendő feldolgozási teljesítmény a lekérdezések kezeléséhez és a replikációhoz.
  • Lemez I/O: Gyors lemezek (SSD-k) kritikusak a jó teljesítményhez, különösen, ha az adatbázis túl nagy ahhoz, hogy teljes egészében a RAM-ban legyen. Az NTDS.DIT és a SYSVOL mappát célszerű külön fizikai lemezen tárolni.

A teljesítmény monitorozása (Performance Monitor, vagy más monitoring eszközökkel) elengedhetetlen a GC-k egészségi állapotának felméréséhez. Figyelni kell a következő mutatókat:

  • LDAP Client Sessions: Az aktív kliens kapcsolatok száma.
  • LDAP Searches/sec: A másodpercenkénti keresési lekérdezések száma.
  • DS Reads/sec, DS Writes/sec: A címtárba irányuló olvasási és írási műveletek száma.
  • Replication Traffic: A bejövő és kimenő replikációs forgalom.
  • Database Cache Hit Ratio: Minél magasabb ez az érték, annál hatékonyabb a RAM használata.
  • Disk I/O: A lemezműveletek száma és késleltetése.

A rendszeres monitorozás lehetővé teszi a problémák korai felismerését, mielőtt azok komolyabb fennakadásokat okoznának. Az összegyűjtött adatok alapján lehet finomhangolni a GC konfigurációját és a hardveres erőforrásokat.

Hibaelhárítás és gyakori problémák

A globális katalógus problémái az Active Directory környezet egyik leggyakoribb és legkomolyabb hibáit okozhatják. Fontos tudni, hogyan lehet azonosítani és elhárítani ezeket a problémákat.

GC elérhetetlenség

Ha egy kliens nem talál elérhető GC-t a saját site-jában, akkor megpróbál egyet találni egy másik site-ban. Ez bejelentkezési késedelmekhez, sikertelen UPN bejelentkezésekhez és az univerzális csoporttagságok hiányos érvényesítéséhez vezethet. Az elérhetetlenség okai a következők lehetnek:

  • Hálózati probléma: Tűzfal, router, switch konfigurációs hiba, vagy fizikai kapcsolat megszakadása. Ellenőrizze a 3268/3269-es portok elérhetőségét.
  • DNS probléma: A GC nem regisztrálta megfelelően az SRV rekordjait a DNS-ben, vagy a kliens nem tudja feloldani a DNS-t. Használja az nslookup vagy dcdiag /test:dns parancsot.
  • A GC szolgáltatás nem fut: A tartományvezérlőn az Active Directory Domain Services (AD DS) vagy a Net Logon szolgáltatás leállt. Ellenőrizze a szolgáltatások állapotát és az eseménynaplót.
  • A DC nem GC: Előfordulhat, hogy a tartományvezérlő valamilyen okból kifolyólag már nem globális katalógus (pl. manuálisan eltávolították a szerepkört). Ellenőrizze az Active Directory Sites and Services konzolon.

Replikációs hibák

A replikációs hibák azt eredményezhetik, hogy a GC adatai elavulttá válnak, ami inkonzisztenciákhoz vezethet az erdő-szintű információkban. Gyakori okok:

  • Hálózati csatlakozás: A replikációs partnerek közötti hálózati kapcsolat megszakadt vagy túl lassú.
  • Tűzfal: A replikációhoz szükséges portok (pl. 53, 88, 389, 445) blokkolva vannak.
  • DNS feloldási problémák: A DC-k nem tudják feloldani egymás nevét.
  • USN rollback: Egy tartományvezérlő visszaállítása olyan biztonsági mentésből, amely régebbi USN-t tartalmaz, mint amit a replikációs partnerek már láttak. Ez súlyos replikációs hibákhoz vezet, és a DC-t el kell különíteni a hálózattól.
  • NTDS.DIT korrupció: Az adatbázis sérült.

A repadmin /showrepl és dcdiag /test:replications parancsok kulcsfontosságúak a replikációs problémák diagnosztizálásában. Az eseménynaplóban a Directory Service kategóriában található események is részletes információkat nyújtanak.

Bejelentkezési problémák

Ha a felhasználók UPN-nel nem tudnak bejelentkezni, vagy ha bejelentkezés után hiányos jogosultságokkal rendelkeznek (pl. nem férnek hozzá univerzális csoportokhoz rendelt erőforrásokhoz), akkor a GC a gyanúsított.

  • GC elérhetetlenség: Ahogy fentebb említettük, ha nincs elérhető GC, a bejelentkezés lassú lesz, vagy meghiúsulhat.
  • Elavult GC adatok: Ha a GC replikációja nem működik megfelelően, az univerzális csoporttagságok elavultak lehetnek a GC-n, ami hibás hozzáférési tokent eredményez.
  • Időeltérés (Time Skew): A Kerberos hitelesítés érzékeny az időre. Ha a kliens és a DC közötti időeltérés túl nagy (alapértelmezés szerint 5 perc), a hitelesítés meghiúsul.

Keresési problémák

Ha a felhasználók vagy alkalmazások nem találnak objektumokat az Active Directoryban, vagy a keresések rendkívül lassúak, a GC lehet a probléma forrása.

  • GC elérhetetlenség: Nincs elérhető GC, vagy a kliensek nem tudják megtalálni.
  • Hiányzó attribútumok a PAS-ban: Ha egy alkalmazás olyan attribútumra keres, amely nincs a PAS-ban, a keresés lassabb lesz, mert átirányításra van szükség.
  • Túlterhelt GC: A GC-n túl sok lekérdezés fut, vagy a hardvere nem elegendő a terhelés kezeléséhez.

Eseménynapló bejegyzések

Az Active Directoryval kapcsolatos problémák diagnosztizálásának elsődleges eszköze az Eseménynapló (Event Viewer), különösen a Directory Service napló. Keresse a figyelmeztetéseket és hibákat a következő eseményazonosítókkal:

  • Replikációs hibák: 1126, 1311, 1411, 1864, 2087, 2088, 2089, 2108.
  • Globális katalógus specifikus események: 1127 (GC build finished), 1128 (GC build failed).
  • DNS és hálózati problémák: 1125, 1578, 4013.

A hibaelhárítás során mindig a következő lépéseket érdemes követni:

  1. Ellenőrizze a hálózati kapcsolatot: Ping, port scan (Test-NetConnection -Port 3268).
  2. Ellenőrizze a DNS feloldást: nslookup, dcdiag /test:dns.
  3. Ellenőrizze a szolgáltatások állapotát: Győződjön meg róla, hogy az AD DS és a Net Logon fut.
  4. Ellenőrizze a replikációt: repadmin /showrepl, dcdiag /test:replications.
  5. Ellenőrizze az eseménynaplót: Keresse a releváns hibákat és figyelmeztetéseket.
  6. Ellenőrizze a GC szerepkört: Győződjön meg róla, hogy a DC globális katalógusként van beállítva.

A proaktív monitorozás és a rendszeres karbantartás segíthet megelőzni a legtöbb GC-vel kapcsolatos problémát.

A globális katalógus és a modern Active Directory környezetek

A globális katalógus gyorsítja a keresést modern Active Directory hálózatokban.
A globális katalógus gyors keresést tesz lehetővé, összesítve az egész erdő összes objektumát.

Az Active Directory folyamatosan fejlődik, és a modern IT környezetek egyre inkább hibrid megoldások felé mozdulnak, ahol a helyi infrastruktúra (on-premises) és a felhőalapú szolgáltatások (cloud) együtt élnek. A globális katalógus szerepe ebben a hibrid környezetben is megmarad, sőt, új dimenziókat kap.

Hibrid környezetek és az Azure AD Connect

Sok vállalat használja az Azure Active Directoryt (Azure AD) a felhőalapú identitáskezeléshez és a SaaS alkalmazásokhoz való hozzáféréshez. Az Azure AD Connect egy olyan eszköz, amely szinkronizálja a helyi Active Directory felhasználóit, csoportjait és egyéb objektumait az Azure AD-vel. Ez a szinkronizációs folyamat a helyi Active Directory tartományvezérlőkhöz és a globális katalógusokhoz is hozzáfér.

Az Azure AD Connect szervernek képesnek kell lennie a helyi AD környezet összes releváns attribútumának lekérdezésére. Bár az Azure AD Connect elsősorban a helyi tartományvezérlőket célozza meg, a globális katalógusok megfelelő működése biztosítja, hogy a szinkronizáció során az összes szükséges információ (például az univerzális csoporttagságok) elérhető legyen, és a felhasználók helyesen kerüljenek szinkronizálásra az Azure AD-be. A GC megbízhatósága közvetlenül befolyásolja a hibrid identitáskezelés integritását és pontosságát.

Az Azure AD Connect gyakran használja a GC-t, különösen akkor, ha több tartomány van a helyi AD erdőben, és a szinkronizációhoz erdő-szintű információkra van szükség. A GC biztosítja, hogy az Azure AD Connect mindenhol megtalálja a felhasználókat és csoportokat, függetlenül attól, hogy melyik tartományban vannak.

GC szerepe a komplex, több erdős környezetekben

Bár a globális katalógus egy erdőn belüli keresésre optimalizált, a több erdős (multi-forest) környezetekben is van szerepe, ha bizalmi kapcsolatok (trusts) vannak kiépítve az erdők között. A bizalmi kapcsolatok lehetővé teszik a felhasználók számára, hogy egy erdőből hozzáférjenek a másik erdőben lévő erőforrásokhoz.

Ebben az esetben, amikor egy felhasználó egy másik erdőben próbál hozzáférni egy erőforráshoz, a hitelesítési folyamat magában foglalhatja a globális katalógusok lekérdezését a bizalmi kapcsolatokon keresztül. Bár a GC nem tárolja a másik erdő objektumait, segíthet a névfeloldásban és a hitelesítési kérések irányításában a megfelelő tartományvezérlőhöz a másik erdőben.

A több erdős környezetek tervezésekor a GC elhelyezése és a bizalmi kapcsolatok konfigurációja különösen fontos a teljesítmény és a biztonság szempontjából.

Jövőbeli trendek

Az identitáskezelés egyre inkább a felhőbe tolódik, és a Microsoft folyamatosan fejleszti az Azure AD-t. Bár a helyi Active Directory és a globális katalógus még hosszú évekig alapvető elemei maradnak a vállalati infrastruktúráknak, valószínű, hogy a jövőben a GC funkcióinak egy része átkerül a felhőbe, vagy a hibrid környezetekben más módon valósul meg.

A Hybrid Identity koncepciója egyre hangsúlyosabbá válik, ahol a helyi AD és az Azure AD szorosan együttműködik. A GC továbbra is kulcsszerepet játszik abban, hogy a helyi AD adatai elérhetők és konzisztensek legyenek a felhőalapú szolgáltatások számára. Az Active Directory Domain Services (AD DS) mint szolgáltatás továbbra is alapvető marad a helyi erőforrások kezelésében, és ezzel együtt a globális katalógus is megőrzi fontosságát.

A technológia fejlődésével a GC-k optimalizálása és kezelése is automatizáltabbá válhat, például az Azure AD Connect Health segítségével, amely proaktív monitorozást és riasztásokat biztosít az identitásinfrastruktúra számára.

A globális katalógus és a DNS kapcsolata

Az Active Directory és a DNS (Domain Name System) kapcsolata rendkívül szoros, szinte elválaszthatatlan. A DNS alapvető szerepet játszik abban, hogy a kliensek és a tartományvezérlők megtalálják egymást, és ez alól a globális katalógus sem kivétel. A GC működése nagymértékben függ a DNS helyes konfigurációjától.

SRV rekordok és a GC felfedezése

Amikor egy kliensnek szüksége van egy tartományvezérlőre vagy egy globális katalógusra, nem az IP-címét keresi közvetlenül, hanem a DNS-t kérdezi le. A tartományvezérlők, beleértve a GC-ket is, speciális szolgáltatási rekordokat (SRV rekordokat) regisztrálnak a DNS-ben.

A globális katalógusok számára a legfontosabb SRV rekord a _gc._tcp.. Ez a rekord mutatja meg a klienseknek, hogy mely tartományvezérlők nyújtanak globális katalógus szolgáltatást az adott tartományban. Például, ha a tartomány neve contoso.com, akkor a kliens a _gc._tcp.contoso.com rekordot fogja lekérdezni a DNS-ből.

A DNS válasz tartalmazza a GC-ként működő tartományvezérlők nevét, portszámát (3268 vagy 3269) és prioritását/súlyát, ami lehetővé teszi a kliens számára, hogy kiválassza a legmegfelelőbb GC-t. A kliens általában először a saját site-jában lévő GC-t keresi, és csak akkor fordul más site-okban lévő GC-khez, ha a helyi nem elérhető.

A DNS a globális katalógus navigációs rendszere; nélküle a kliensek elvesznének az Active Directory erdőben.

DNS regisztráció és dinamikus frissítések

A tartományvezérlők automatikusan regisztrálják a DNS rekordjaikat, beleértve az SRV rekordokat is, a dinamikus DNS frissítések (Dynamic DNS updates) segítségével. Ez a folyamat biztosítja, hogy a DNS mindig naprakész legyen a hálózaton elérhető tartományvezérlőkről és azok szolgáltatásairól.

Ha a DNS dinamikus frissítések valamilyen okból nem működnek megfelelően, a GC-k SRV rekordjai elavulttá válhatnak. Ez azt eredményezheti, hogy a kliensek nem tudják megtalálni az elérhető GC-ket, még akkor sem, ha azok működőképesek. Ezért elengedhetetlen a DNS szerverek megfelelő konfigurációja és a dinamikus frissítések engedélyezése.

Fontos, hogy a DNS szerverek legyenek integrálva az Active Directoryval (Active Directory-integrated DNS zones), ami növeli a biztonságot és a replikáció hatékonyságát.

DNS hibák hatása a GC-re

A DNS hibák súlyosan befolyásolhatják a globális katalógus működését:

  • Helytelen SRV rekordok: Ha a GC SRV rekordjai hibásan regisztrálódnak, vagy egyáltalán nem regisztrálódnak, a kliensek nem találják meg a GC-t.
  • DNS feloldási problémák: Ha a kliens nem tudja feloldani a DNS szerver címét, vagy ha a DNS szerver nem tudja feloldani a GC nevét, a kommunikáció meghiúsul.
  • Hosszú DNS késleltetés: Ha a DNS lekérdezések túl sokáig tartanak, az lassítja a GC felfedezését és a bejelentkezési folyamatot.

A DNS hibaelhárítása szerves része az Active Directory és a globális katalógus problémáinak megoldásának. Az ipconfig /flushdns, ipconfig /registerdns, dcdiag /test:dns és nslookup parancsok kulcsfontosságúak a DNS problémák azonosításában és javításában.

Összefoglalva, a DNS és a globális katalógus szimbiotikus kapcsolatban állnak. A GC a DNS-re támaszkodik a felfedezéshez, és a DNS megbízhatósága közvetlenül befolyásolja a GC szolgáltatásainak elérhetőségét és teljesítményét.

Biztonsági szempontok a globális katalógusban

Mivel a globális katalógus az Active Directory erdő összes objektumának részleges másolatát tartalmazza, kulcsfontosságú a biztonsági szempontok megfelelő kezelése. Az adatok védelme, a hozzáférés-vezérlés és az auditálás elengedhetetlen a GC integritásának és bizalmasságának fenntartásához.

Adatvédelem és titkosság

A GC tárolja az erdő összes felhasználójának és csoportjának alapvető attribútumait, mint például az UPN-eket, e-mail címeket és csoporttagságokat. Bár nem tárol jelszavakat (azokat a tartományvezérlők tárolják, és nem replikálódnak a GC-re más tartományokból), az itt tárolt adatok mégis érzékenyek lehetnek, és visszaélésre adhatnak okot, ha illetéktelen kezekbe kerülnek.

Ezért fontos, hogy a GC-t futtató tartományvezérlőket fizikailag is biztonságos helyen tároljuk, és a hozzáférésüket szigorúan korlátozzuk. A szerverek operációs rendszerének és az Active Directory adatbázisának (NTDS.DIT) titkosítása (pl. BitLockerrel) további védelmet nyújthat az adatok számára.

A hálózati forgalom titkosítása is fontos. A klienseknek a 3269-es (LDAPS) porton keresztül kell kommunikálniuk a GC-vel, ha érzékeny adatokat kérdeznek le, vagy ha a hálózat nem teljesen megbízható. A megfelelő SSL/TLS tanúsítványok telepítése a tartományvezérlőkre elengedhetetlen a biztonságos LDAPS kommunikációhoz.

Hozzáférés-vezérlés

Az Active Directoryban az objektumokhoz való hozzáférést az engedélyek (permissions) szabályozzák. Bár a GC egy replikált másolatot tartalmaz, az engedélyek továbbra is az eredeti objektumon érvényesülnek. Ez azt jelenti, hogy ha egy felhasználónak nincs engedélye egy attribútum olvasására az eredeti tartományvezérlőn, akkor azt a GC-n sem tudja majd lekérdezni, még akkor sem, ha az attribútum része a PAS-nak.

Azonban a delegálás és a szolgáltatásfiókok kezelése során különös figyelmet kell fordítani a jogosultságokra. Például, ha egy alkalmazás szolgáltatásfiókot használ a GC lekérdezéséhez, győződjön meg róla, hogy csak a minimálisan szükséges jogosultságokkal rendelkezik. A „legkevesebb jogosultság elve” (principle of least privilege) itt is alapvető.

A séma módosításakor, amikor attribútumokat adunk hozzá a PAS-hoz, győződjünk meg róla, hogy az attribútumokhoz beállított engedélyek megfelelően kezelik a bizalmas információkat. Ne tegyen bizalmas attribútumokat a PAS-ba, ha nem feltétlenül szükséges, mivel ez növeli az adatok elérhetőségét az erdőben.

Auditálás

A globális katalógushoz intézett lekérdezések és a rajta végzett műveletek auditálása kulcsfontosságú a biztonsági incidensek felderítéséhez és a megfelelőségi követelmények teljesítéséhez. Az Active Directory auditálási beállításait konfigurálva nyomon követhetők a sikeres és sikertelen hozzáférési kísérletek, a címtárváltozások és egyéb releváns események.

Az auditálási naplók rendszeres áttekintése segíthet azonosítani a gyanús tevékenységeket, például illetéktelen lekérdezéseket vagy a jogosultságok megkerülésére tett kísérleteket. Különösen fontos az auditálás, ha harmadik féltől származó alkalmazások vagy szolgáltatásfiókok férnek hozzá a GC-hez.

Az auditálási beállítások finomhangolása lehetővé teszi, hogy csak a releváns eseményeket naplózzuk, elkerülve a naplók túlzott méretét. Az eseménygyűjtés és a központi naplókezelő rendszerek (SIEM) segíthetnek a naplóadatok hatékony elemzésében és a biztonsági riasztások generálásában.

A globális katalógus biztonsága az Active Directory környezet egészének biztonságát befolyásolja. A megfelelő tervezés, konfiguráció és folyamatos monitorozás elengedhetetlen a GC által kezelt adatok védelméhez és a szolgáltatás integritásának fenntartásához.

Share This Article
Leave a comment

Vélemény, hozzászólás?

Az e-mail címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük