Az Active Directory, röviden AD a Microsoft egyes hálózati szolgáltatásainak gyűjtőneve, ezek:
- X.500-alapú, LDAPv3 protokollal lekérdezhető, elsősorban Microsoft Windows-környezetben használatos címtárszolgáltatás;
- Kerberos protokoll-alapú autentikáció;
- DNS-alapú névszolgáltatás és egyéb hálózati információk.
Az Active Directory címtár az adatbázisból és az azt futtató Active Directory szolgáltatásból áll. Fő célja a Windowst futtató számítógépek részére autentikációs és autorizációs szolgáltatások nyújtása, lehetővé téve a hálózat minden publikált erőforrásának (fájlok, megosztások, perifériák, kapcsolatok, adatbázisok, felhasználók, csoportok stb.) központosított adminisztrálását – vagy éppen a rendszergazdai jogosultságok delegálásával a decentralizált felügyeletét. Számos különböző erőforráshoz (megosztott mappák, nyomtatók, levelezés stb.) egyetlen felhasználónév/jelszó páros megadásával biztosít hozzáférést (Single Sign On, SSO). Lehetőséget nyújt a rendszergazdák számára házirendek kiosztására, szoftverek és szoftverfrissítések telepítésére a szervezeten belül. Az Active Directory az információkat és beállításokat egy központi adatbázisban tárolja, a tartományvezérlő számítógépe(ke)n. Ennek az adatbázisnak a mérete egy kisvállalat néhány száz objektumától egy több ezer szervert üzemeltető nemzetközi vállalat sok millió objektumáig terjedhet. Az Active Directory szükséges néhány Windows-összetevő, mint például az Exchange, az RRAS, az ISA Server vagy a Certificate Services működéséhez.
Egy Active Directory-címtár legmagasabb szintje az erdő (forest), ami egy vagy több bizalmi kapcsolatokkal (trust) összekötött tartományt (domain) magába foglaló egy vagy több fa (tree) összessége. A tartományokat DNS-beli névterük azonosítja. A címtár objektumait a Directory Information Tree (címtárinformációs fa, DIT) adatbázisa tárolja, ami három partícióra bomlik, ezek: az objektumok tulajdonságait leíró sémapartíció (schema partition), az erdő szerkezetét (tartományokat, fákat, helyeket) leíró konfigurációs partíció (configuration partition) és a tartomány objektumait tartalmazó tartományi partíció (domain partition). Ezeken kívül létezhetnek alkalmazáspartíciók (application partition) is.
Az Active Directory előzetes változatai 1999-ben jelentek meg, a végleges változat a Windows 2000 szerverváltozatával látott napvilágot. A Windows Server 2003-ban átdolgozott verzió jelent meg kiterjesztett szolgáltatáskészlettel és javított adminisztrációs lehetőségekkel. További előrelépések történtek a Windows Server 2003 R2 és a Windows Server 2008-as változatokban, ahol az Active Directory Domain Services nevet kapta.
Az Active Directoryt korábbi Microsoft dokumentumokban NTDS-nek (NT Directory Service) nevezték, egyes AD-segédprogramokban (például ntdsutil) még fellelhető ez az elnevezés.
Gyakori tévedés, hogy az Active Directory szoftverterjesztésre használható. Ez nem pontos, a szoftverterjesztést egy másik szolgáltatás nyújtja, ami az LDAP gyártóspecifikus séma-attribútumait használja fel. Tehát az AD nem automatizálja a szoftverterjesztést, csak egy mechanizmust biztosít, amit más szolgáltatások erre használhatnak.
Objektumok
Az Active Directory objektumokból épül fel. Ezek három fő kategória egyikébe tartoznak: erőforrások (például nyomtatók), szolgáltatások (például e-mail) és felhasználók (felhasználói fiókok, csoportok). Az AD információkat tárol ezekről az objektumokról, rendszerezi őket, szabályozza a hozzáférést és biztonsági beállításokat tárol; ezzel egyben központosítva a hálózatot.
Minden objektum egyetlen entitást reprezentál – legyen az felhasználó, számítógép, nyomtató vagy egy csoport – attribútumaival együtt. Bizonyos objektumok más objektumokat tartalmazó konténerként is működhetnek. Egy objektumot egyértelműen azonosít megkülönböztetett neve (dn, distinguished name), ami tulajdonképpen az objektum neve és a fában elfoglalt helye együttesen. Például a Fabrikam.com tartomány felhasználóit tartalmazó szervezeti egység megkülönböztetett neve: "CN=Users, DC=Fabrikam, DC=com". Egy objektum megkülönböztetett neve változhat az objektum áthelyezésével, átnevezésével. Egy másik egyértelmű azonosító, ami viszont az objektum teljes élettartama alatt változatlan marad, az objectGUID attribútuma. Ez egy 128 bites, erdő-szinten garantáltan egyedi azonosító. Azt, hogy milyen típusú objektumok lehetnek az AD-ben, és ezek az objektumok hogyan viselkedhetnek, milyen információkat (attribútumokat vagy tulajdonságokat) tartalmazhatnak, a séma határozza meg.
Az AD-ban lévő sémaobjektumok határozzák meg az AD objektumainak tulajdonságait. Fontos szerepük miatt – az AD struktúráját alkotják – megváltoztatásuk vagy törlésük komoly következményekkel járhat, ezért csak szigorúan meghatározott szabályok alapján lehet változtatni rajtuk. Egy sémaobjektum megváltoztatása automatikusan továbbterjed az egész Active Directoryban, a létrehozott objektumot csak deaktiválni lehet – törölni nem. A séma megváltoztatása (tipikusan: bővítése) ezek miatt általában komoly tervezést igényel.[1]
A Windows Server 2008-ban már lehetőség volt egyes objektumokat védeni a véletlen törlés ellen. A Windows Server 2008 R2-ben bevezetett újdonság az Active Directory Lomtár, ami képes megőrizni az objektumok összes csatolt és nem csatolt értékű attribútumát, és az objektumokat ugyanabba a konzisztens logikai állapotba visszaállítani, mint amelyben a törlés előtt voltak (pl. csoporttagság, kapcsolódó hozzáférési jogok visszaállítása). A korábban hozzáférhető eszközökkel a logikailag törölt AD-objektumok nem voltak teljes értékűen visszaállíthatók. Az AD Lomtár csak Windows Server 2008 R2 erdő működési szinten hozzáférhető, de alapértelmezés szerint ott sincs engedélyezve.
Helyek
Az Active Directory támogatja a helyek (Site) létrehozását, ami nem logikai, hanem fizikai, méghozzá IP subnet (alhálózat) szerinti felosztást takar.[2] A helyek egymás között jó hálózati kapcsolattal rendelkező alhálózatok halmazaiként határozhatók meg. A helyek segítségével el lehet különíteni az alacsony (például WAN vagy VPN) és a magas sávszélességű kapcsolattal összekötött (LAN) helyszíneket. A helyek kialakítása független a tartományi és a szervezeti egység szerinti hierarchiától, és erdő-szinten egységes. A helyek szerepe a replikáció hálózati forgalmának szabályozásában van, továbbá abban, hogy a felhasználók a hozzájuk lehető legközelebb eső tartományvezérlőhöz csatlakozzanak, illetve más szolgáltatások esetén is a lokális példányt használják. A helyek összeköthetők (linkelhetők), a linkekhez költség rendelhető, ami a hálózati kapcsolat sebességét, megbízhatóságát vagy más fizikai jellemzőjét reprezentálja. Más szolgáltatások is „helytudatosak”, ilyenek a DFS-erőforrások, illetve a Microsoft Exchange 2007+ a levelek útválasztására is felhasználja a helytopológiát. A csoportházirendek szintén alkalmazhatók a helyek szintjén.
Erdők, fák, tartományok és partíciók
Az Active Directory objektumait a Directory Information Tree (címtárinformációs fa, DIT) adatbázisa tárolja (a Windows NT tartományban a „címtár” jellegű adatok még a registryben kaptak helyet), ebben egy többszintű keretrendszer foglal helyet. A struktúra legmagasabb szintjén foglal helyet az erdő (forest) – az AD minden objektumának, azok attribútumainak és szabályainak (az attribútumok szintaxisa) gyűjteménye. Az azonos erdőben található tartományvezérlőkről elmondható, hogy közös sémán és konfigurációs partíción osztoznak, és a globális katalógusokról azonos információkat érnek el. Az erdőt egy vagy több, kétirányú és tranzitív[3] bizalmi kapcsolat (trust) által összekötött fa (tree) alkotja. Egy-egy fában egy vagy több, konfigurációs és sémapartíciójukban megegyező tartomány (domain) lehet, amik egy tartományhierarchiát alkothatnak, melyben a szülő- és a gyermektartományok között automatikusan létrejövő, tranzitív kétirányú bizalmi kapcsolat van. Az azonos szintű tartományok között explicit bizalmi kapcsolatokat lehet létrehozni, ha szükséges. A tartományokat DNS-beli névterük azonosítja, és ez a tartományi hierarchiát is tükrözi (például a child.parent.root.com tartomány szülője a parent.root.com).
A tartományban lévő objektumok szervezeti egységekbe (Organizational Unit, OU) rendezhetők. Az OU-k adnak a tartománynak az adminisztrációt megkönnyítő hierarchiát, segítségükkel az Active Directory struktúrájára leképezhető a vállalat szervezeti felépítése vagy földrajzi elhelyezkedése. Egy OU tartalmazhat egy vagy több más OU-t is (ilyen értelemben a tartomány is tekinthető OU-nak), a többszörös egymásba ágyazás is megengedett. A Microsoft azt javasolja, hogy az Active Directoryt minél kevesebb tartományra bontsuk szét, és inkább szervezeti egységek létrehozásával tagoljuk a címtárat. A csoportházirendek (amik szintén AD objektumok, csoportházirend-objektum – Group Policy Object, röviden GPO néven) általában az OU szintjén fejtik ki hatásukat, bár tartomány és hely (site) szinten is alkalmazhatók. Többnyire az OU szintjén szokás a rendszergazdai jogosultságokat delegálni, bár a delegáció akár egyedi objektumok, sőt attribútumok szintjén is beállítható.
A vállalat informatikai infrastruktúrájának felosztása tartományok és szervezeti egységek hierarchiájára kulcsfontosságú tervezési lépés. A gyakori felosztási modellek közé tartozik az üzleti egységeket, a földrajzi elhelyezkedést, az informatikai szolgáltatási igényeket vagy az objektumtípusokat követő felosztás. Ezeket a modelleket gyakran együttesen alkalmazzák. A szervezeti egységek kialakításakor elsősorban a rendszergazdai jogok delegációját és a csoportházirendek alkalmazását érdemes szem előtt tartani. Bár a szervezeti egységek és a tartományok adminisztratív határvonalat képeznek, az egyetlen valódi biztonsági határt maga az erdő alkotja: az AD kialakítása szükségessé teszi, hogy minden tartományi rendszergazda megbízható legyen az egész vállalat (erdő) szintjén is.
Fizikailag az Active Directory adatai egy vagy több egyenrangú tartományvezérlőn (domain controller, DC) tárolódnak, szemben a Windows NT PDC/BDC (Primary/Backup DC) modelljével. Minden tartományvezérlőn megtalálható az Active Directory egy kópiája; általában valamelyik DC kópiájának változásai multi-master (több főkiszolgálós) replikációval szinkronizálódnak a többi DC-re (szemben például a sémaváltozások single-master replikációjával). Ez azt jelenti, hogy nincsen alá-fölérendeltségi viszony a replikációs partnerek között, hanem egy változtatásból eredő replikációs folyamatot – amely végighalad az adott tartomány tartományvezérlőin – bármelyik tartományvezérlő kezdeményezhet. Ütközés esetén a későbbi (pontosabban: magasabb frissítési sorszámmal, azaz Update Sequence Numberrel, USN-nel rendelkező) változás az erősebb. Ezt a helyzetet bonyolítja, hogy a Windows Server 2008-ban bevezetésre került az írásvédett tartományvezérlő (Read-Only Domain Controller, RODC) fogalma, melynél a replikáció csak „lefelé”, a központban található, írható tartományvezérlőtől a telephelyi RODC kiszolgáló felé történik. A tartomány részeként működő, de nem tartományvezérlő kiszolgálókat tartományi szervernek vagy tagkiszolgálónak (Member Server) nevezik.
Az Active Directory adatbázisa, a Directory Information Tree (címtárinformációs fa, DIT) az alábbi három tárterületre vagy partícióra bomlik (ezek a microsoftos terminológiában elnevezési környezet vagy névkörnyezet – Naming Context névre is hallgatnak):
- Sémapartíció (schema partition): az egész erdő számára meghatározza az objektumosztályokat: az objektumok létrehozásának és módosításának a szabályait, az objektumok lehetséges tulajdonságait (attribútumait). Az erdő minden tartományvezérlőjére replikálódik, ezért ún. vállalati partíció (enterprise partition). Helye: cn=configuration,dc=forestRootDomain.[4]
- Konfigurációs partíció (configuration partition): az egész erdő fizikai szerkezetét (például topológiáját) és beállításait határozza meg, beleértve a fákat, tartományokat, tartományi bizalmi kapcsolatokat és helyeket (sites, TCP/IP alhálózatok). Az erdő minden tartományvezérlőjére replikálódik, ezért ez is ún. vállalati partíció (enterprise partition). Helye: cn=schema,cn=configuration,dc=forestRootDomain.[4]
- Tartományi partíció (domain partition): minden információt tárol az adott tartomány objektumairól (beleértve a szervezeti egységeket, csoportokat, felhasználókat stb.). Kizárólag az adott tartomány tartományvezérlőire replikálódik (illetve az erdő globális katalógusi – Global Catalog, GC – szerepkörű tartományvezérlőire is, részlegesen).
- Részleges tartományi partíció – minden tartományi objektumot tartalmaz, de az objektumok tulajdonságainak csak részleges listájával.
- Az alkalmazáspartíciók application partition közé (legalább Windows 2003-as működési szint esetén) tartozhatnak a tartomány vagy erdő szintű, AD-integrált DNS-zónák (ForestDnsZones, DomainDnsZones) is.[5]
Az Active Directory adatbázisa (a directory store) a Windows 2000-ben a Jet Blue-alapú Extensible Storage Engine-t (ESE98) használja adatbázismotornak, 16 terabájtos és 1 milliárd objektumos korláttal tartományvezérlőnként. Hoztak már létre kísérletképpen NTDS adatbázisokat 2 milliárdnál is több objektummal[6] – ehhez képest az NT4 Security Account Managere – biztonsági fiókkezelő adatbázisa – legfeljebb 40 000 objektumot volt képes kezelni. Az NTDS.DIT fájlnevű adatbázisnak két fő táblája van: az adattábla (data table), ami az objektumokat tárolja (a sorok reprezentálnak egy-egy objektumpéldányt, például egy felhasználót, az oszlopok pedig a hozzá tartozó attribútumokat) és a jóval kisebb hivatkozástábla (link table), ami a más objektumokra hivatkozó attribútumokat tárolja (például a csoporttagsági – MemberOf – attribútum). Ezeken kívül létezik az objektumokat leíró sématábla (schema table), ez kisebb méretű és lényegében statikus. A Windows 2003-ban az adatbázis Single Instance Store-t használ a jobb helykihasználás érdekében.
Replikáció
A replikációs kapcsolatok az Active Directory tartományvezérlői között partíció szinten állnak fenn, tehát minden partíciónak külön összeköttetései vannak. Az erdő szintű partíciók (séma, konfiguráció, esetleg alkalmazáspartíciók) kapcsolati objektumai az erdő bármely két tartományvezérlőjét összeköthetik, a tartományi partíció kapcsolati objektumai csak tartományon belüli összeköttetéseket hoznak létre.
A Windows korábbi verzióival ellentétben, amik a NetBIOS protokoll segítségével kommunikáltak, az Active Directory teljes mértékben DNS- és TCP/IP-integrált – valójában a jól működő DNS elengedhetetlen az AD működéséhez. Ha nem a Windowsba épített DNS szolgáltatást használjuk, olyan DNS szerverre van szükség, ami támogatja a 2782-es RFC-ben definiált SRV erőforrásrekordokat (SRV resource record).
Az AD-beli replikáció pull („lekéréses”), nem pedig push („leküldéses”) típusú. A konzisztencia-ellenőrző szolgáltatás (KCC = Knowledge Consistency Checker) létrehoz egy site linkekből (helyek közötti hivatkozásokból) álló replikációs topológiát, a definiált helyeket használva a forgalom szabályzására. A site-on belüli (intrasite) replikáció gyakran és automatikusan megtörténik: minden változási értesítés egy lekéréses replikációs ciklust indít meg. Ez tömörítetlen adatforgalmat jelent, ami szinkron RPC kapcsolaton keresztül továbbítódik. A site-ok közötti (intersite) replikáció ritkábban, megadott időközönként történik és nem használja a változási értesítéseket, ám ez konfigurálható akár a site-on belüli replikációval megegyezőre is. Tömörített adatforgalom, amely RPC vagy aszinkron SMTP kapcsolaton keresztül történik. Az ISTG (Intersite Topology Generator) szolgáltatás alakítja ki az általában nem redundáns replikációs útvonalat. Különböző „költségeket” lehet az egyes helyek közötti hivatkozásokhoz rendelni (például a DSL vonallal összekötött telephelyeken a replikáció „olcsóbb” lehet, mint ISDN vonal használatakor), és a site linkek topológiáját a KCC ehhez igazodva változtatja meg. A tartományvezérlők közötti replikáció történhet tranzitív módon, több site linken keresztül (az azonos protokollt használó site link bridge-eken), ha az azokhoz rendelt költség alacsony, bár a KCC automatikusan alacsonyabb költséget rendel a közvetlen site-site kapcsolódásokhoz mint a tranzitívekhez. Két site közötti replikáció beállítható úgy is, hogy egy-egy bridgehead server („hídfőállás-kiszolgáló”) között történjen, amik aztán site-on belüli replikációval adják át a változásokat a site-on belül.
A KCC a site-on belüli topológia előállítása során arra törekszik, hogy a változások replikációja legfeljebb három ugráson (hop) keresztül eljusson a site-on belül minden tartományvezérlőhöz. Ehhez a Simplified Ring Topology Generation metódust követi. A legegyszerűbb, egy tartományos esetet nézve: létrehoz egy (kétirányú) gyűrűt a tartományvezérlőkből – ha hét vagy kevesebb tartományvezérlőt tartalmaz a site, ezzel elő is állt a kívánt topológia. Ha a szerverek számra a hetet meghaladja, a gyűrűt kialakító kapcsolatokon kívül a KCC véletlenszerű módon további, optimalizáló kapcsolatokat hoz létre, időnként pedig a régiek közül egyet-egyet kitöröl. Az optimalizáló kapcsolatok valamennyi replikálandó partíció között kiépülnek.[7] Az automatikusan létrehozott replikációs topológia kézzel változtatható, fel lehet venni újabb replikációs linkeket.
A több tartománnyal bíró erdőkben az Active Directory adatbázisa részekre bontva van jelen: az egyes tartományok tartományvezérlői csak azokról az objektumokról vezetnek listákat, amik abba a tartományba tartoznak. Tehát például az „A” tartományban felvett felhasználóról nem tudnak a „B” tartomány tartományvezérlői. A globális katalóguskiszolgálók (GC servers) feladata, hogy az erdő minden objektumát számon tartsák. A globális katalógust az erre a katalóguskiszolgálói szerepkörre bekonfigurált tartományvezérlők vezetik. A globális katalóguskiszolgálók minden tartomány minden objektumát replikálják, így az egész erdő objektumainak listáját tartalmazzák. A replikációs forgalom, valamint a GC adatbázisméretének csökkentése érdekében azonban csak az objektumok néhány kiválasztott attribútuma kerül replikálásra (többnyire azok, amik alapján valószínűleg kereshetik az objektumot). Ezt részleges tulajdonsághalmaznak (partial attribute set – PAS) nevezik. A PAS-ben szereplő attribútumok finomhangolhatók, a sémát kell hozzá módosítani és beállítani az érintett attribútumoknál a GC-kre való replikációt.
Az AD replikációja távoli eljáráshívásokat (Remote Procedure Call, RPC) használ. Különböző helyek között SMTP protokoll is választható a replikációra, de csak konfigurációs vagy sémaváltozás replikálására (tanúsítványkiadó – CA – szerverre is szükség van ehhez az üzemmódhoz). Mivel az SMTP nem alkalmas a tartományi partíció replikációjára, ha egy tartomány egy WAN kapcsolat mindkét oldalán jelen van, a replikációhoz akkor is RPC-re lesz szükség.
Az alkalmazáspartíció replikációja az erdőn belül bármely tartomány vezérlői között megtörténhet, széles körben testre szabható.[8]
Szimulált, valójában lapos hierarchia
Az Active Directory adminisztrációt segítő, tetszőlegesen egymásba ágyazható szervezeti egységei valójában csak a rendszergazda munkáját segítő absztrakciók; a tartományok úgy működnek, mintha az objektumok egyszerű, lapos struktúrában lennének létrehozva, szervezeti egységek nélkül. Nem lehetséges például egy tartományon belül, de különböző szervezeti egységekben ugyanolyan felhasználói névvel (sAMAccountName) felhasználót felvenni. A felhasználói név egyediségének megkövetelése miatt az olyan több ezer felhasználós hálózatokban, ahol nem célszerű tartományokra bontani a címtárat (pl. iskolák, rendőrség), a felhasználói név generálása némi fejfájást jelenthet. A felhasználók számának növekedésével ugyanis az egyszerű generálási módszerek, mint pl. „vezetéknév, középső név első betűje, keresztnév első betűje” számos duplikátumot eredményeznek, pl. több TothI, KovacsJ jön létre, amiknek a végére általában sorszámot vagy véletlenszámot illesztenek (KovacsJ12, TothI4). Ha ilyenekből nagyon sok van, az adminisztrációs személyzet akár le is mondhat a felhasználói nevek könnyű memorizálhatóságának konvenciójáról, és egyszerűen 5-10 jegyű sorszámként tekintik, hogy a tartományon belüli egyediség követelményének megfeleljenek.
Az AD tartományvezérlői általában multi-master replikációs modellben működnek, tehát a legtöbb műveletet bármelyik kiszolgálón el lehet végezni, mert replikáció útján automatikusan eljutnak a változások a többi, egyenrangú tartományvezérlőre. Van azonban néhány olyan feladatkör, ahol ez másként van: például a séma csak a Schema Master-en módosítható. Ezek az úgynevezett FSMO szerepkörök (kiejtés: kb. „fizzmó”), FSMO=„Flexible Single Master Operations” ~ „Mozgó egyedüli főkiszolgálóval végzett műveleti szerepek”, vagy szokásosan csak műveleti főkiszolgáló-szerepek kizárólag 1-1 kitüntetett tartományvezérlőn fordulhatnak elő, a következőképpen:
| Szerep neve | Hatásköre | Leírása |
|---|---|---|
| Schema Master Séma-főkiszolgáló |
Erdőnként 1 | A séma minden frissítését és módosítását ellenőrzi. Ha nem elérhető, nem lehet sémát bővíteni/frissíteni. |
| Domain Naming Master Tartománynév-kiosztási főkiszolgáló |
Erdőnként 1 | Tartományok erdőhöz való hozzáadását/erdőből való eltávolítását ellenőrzi. Ha nem elérhető, a tartományfákkal kapcsolatos változtatások nem hajthatók végre. |
| PDC Emulator PDC-emulátor |
Tartományonként 1 | Visszamenőleges kompatibilitást nyújt az NT 4-es kliensek számára a (Windows NT idejében csak a) PDC-n végezhető műveletekhez, mint például jelszócsere, tulajdonképpen elsődleges Windows NT tartományvezérlőként (Primary Domain Controller) működik. Szintén a PDC-kre hárul néhány tartomány-specifikus feladat, mint a Security Descriptor Propagator (SDPROP) futtatása, továbbá ők a tartományuk elsődleges időkiszolgálói. |
| RID Master RID-főkiszolgáló |
Tartományonként 1 | Valamely tartományvezérlő kérésére kiosztja egy új objektum részére a relatív azonosító (Relative IDentifier) részt a biztonsági azonosítóból (SID). Ez a művelet az új objektum létrehozásakor zajlik. A relatív azonosító egy tartományon belül egyértelműen azonosítja az objektumot. Ha nem elérhető, nem lehet a tartományban új objektumokat létrehozni. Megakadályozza, hogy két objektum ugyanazt a security ID-t kapja. |
| Infrastructure Master Infrastruktúra-főkiszolgáló * |
Tartományonként 1 | A saját tartományába tartozó objektumok más tartományokba tartozó objektumokra való hivatkozásainak frissítéseit végzi (jellemzően a tartományközi csoporttagság-változásokat szinkronizálja). Ha nem elérhető, a többi tartománnyal való kapcsolattartás során frissítési problémák lépnek fel. Felelős a tartományi kereszthivatkozások megfelelő működéséért. Több tartományvezérlős környezetben az IM nem lehet Global Catalog (GC) szerver is egyben, mivel ebben az esetben a kiszolgáló nem tudja, hogy melyek az általa nem tárolt objektumokra mutató hivatkozások, hiszen a GC szerveren az erdő összes objektumáról van részleges replika. A domain-közi kereszthivatkozások frissítése ilyenkor hibaüzenettel leáll. Amennyiben viszont minden egyes DC egyben GC is, úgy már nincs jelentősége, hogy ki hordozza ezt a szerepkört. |
Minden tartományban szükség van RID, Infrastructure-master, és PDC emulatorra. Ezeknek a szerepköröknek az elosztása utólag is változtatható a tartományvezérlők között. Ez történhet alapesetben a szerepkör átadásával, tartományszintű műveleti főkiszolgálóknál az „Active Directory – felhasználók és számítógépek” eszközzel, a tartománynév-nyilvántartási főkiszolgálónál az „Active Directory – tartományok és bizalmi kapcsolat” eszközzel, a séma-főkiszolgálónál pedig a Schema Manager-rel. Ha valamiért nem lehet szabályosan átadni a szerepkört – például mert a szerver fizikailag tönkrement –, és biztosak vagyunk benne hogy nem kerül fel többé a hálózatra, akkor az ntdsutil parancssori segédprogrammal a szerepkör „erőszakos” átvételére is mód van.
*: Az Infrastructure Master a táblázatban vázolt szerepköre csak a „normál” tartományra, tehát az alapértelmezett névhasználati környezetre vonatkozik, a netdom parancs, valamint az ntdsutil eszköz is csak ezt kérdezi le. Az összes alkalmazáspartíció, továbbá a tartományi DNS zónák, valamint az erdő szintű DNS zónák partíciója saját infrastruktúra-főkiszolgálóval rendelkezik. Ezeknél az alkalmazáspartícióknál a partíció gyökerében található Infrastructure objektum fSMORoleOwner attribútumában tárolódik a főkiszolgáló; módosításához az ADSIEdit eszközzel pl. a CN=Infrastructure,DC=DomainDnsZones,DC=yourdomain,DC=tld objektum fSMORoleOwner attribútumát módosítani kell CN=NTDSSettings,CN=Name_of_DC,CN=Servers,CN=DRSite,CN=Sites,CN=Configuration,DC=Yourdomain,DC=TLD-re.[9]
Az Active Directory támogatja az UNC (\), URL (/) és LDAP szintaxisú URL-eket objektumainak elérésére. Belsőleg az X.500 elnevezési struktúra LDAP változatát használja.
Minden objektumnak van egy megkülönböztetett neve (Distinguished name, röviden DN), például a foo.org tartomány Marketing szervezeti egységében található HPLaser3 nevű nyomtatóobjektum DN-je: CN=HPLaser3,OU=Marketing, DC=foo, DC=org, ahol CN a common name (közönséges név), DC a tartomány objektumosztály. A megkülönböztetett név természetesen négynél több részből is állhat. Az objektumnak lehet kanonikus neve (canonical name, röviden CN), ami lényegében a DN megfordítva, azonosítók nélkül és perjeleket használva: foo.org/Marketing/HPLaser3. Egy tárolón belül az objektum azonosítható a relatív megkülönböztetett nevével (relative distinguished name, röviden RDN): CN=HPLaser3. Valamennyi objektum rendelkezik globálisan egyedi azonosítóval (GUID) is, ami egy egyedi, az objektum élettartama során változatlan, 128 bites érték, amit az AD-n belüli keresés és replikáció során használnak. Egyes objektumoknak elsődleges felhasználóneve (User principal name, röviden UPN) is van, ez objektumnév@tartománynév formátumú.
Már amikor az első Windows 2000 Serverek megjelentek a Windows NT-tartományokban, felmerült a tartományok üzemmódjainak kompatibilitási okokból történő szétválasztása. A Windows Server 2003-mal és a Windows Server 2008-cal a helyzet tovább bonyolódott. Általánosan elmondható, hogy újabb szerververziók nagyobb teljesítményt, új funkciókat hoznak, amiket azonban csak akkor lehet teljes körűen kihasználni, ha a tartomány (vagy erdő) teljes infrastruktúrája már az új verziót futtatja. Általában igaz, hogy a tartomány működési szintje akkor emelhető, ha minden tartományvezérlője már az új szinten van, az erdő működési szintje pedig akkor, ha az összes tartomány már emelt szintű. Magasabb szintű tartományba nem lehet régebbi tartományvezérlőt, magasabb szintű erdőbe pedig régebbi tartományt csatlakoztatni. A funkcionalitási szintet mindig csak felfelé állíthatjuk, visszatérés nincs.
A funkcionalitási szint megtekintésére és átállítására az Active Directory – tartományok és bizalmi kapcsolatok MMC-eszköz szolgál: a tartomány nevén kattintva tartományszintű, az MMC-konzol gyökerén az erdőszintű beállításhoz jutunk.
Az Active Directory működési szintjei (Functionality levels):
| Működési szint (tartomány) | Támogatott tartományvezérlők | Leírás |
|---|---|---|
| Windows 2000 vegyes mód (Windows 2000 mixed mode) | Windows NT Server Windows 2000 Server Windows Server 2003 | Vegyes módban Windows NT BDC-ket (Backup Domain Controller) is csatlakoztathatunk a tartományhoz. A címtár legfeljebb 40 000 objektumot tartalmazhat. |
| Windows 2000 natív (Windows 2000 native) | Windows 2000 Server Windows Server 2003 Windows Server 2008 (sémabővítéssel) | Univerzális csoportok; a csoportok típusai változtathatók; egymásba ágyazható csoportok; SID history; RAS házirendek; a méretezési problémák megoldása. |
| Windows 2003 köztes mód (Windows 2003 interim mode) | Windows NT Server Windows Server 2003 | A tartományi köztes mód az erdő első Windows NT tartományának frissítésekor használható, nem automatikus módon. Inkább csak átmenetileg, NT→2003 migrációkor használatos, ha biztosan tudjuk, hogy nem fogunk Windows 2000 tartományvezérlőt használni. |
| Windows 2003 natív mód (Windows 2003 native mode) | Windows Server 2003 Windows Server 2008 Windows Server 2008 R2 Windows Server 2012 Windows Server 2012 R2 (csökkent funkcionalitás, deprecated) | Netdom.exe eszköz (tartományvezérlő átnevezése); frissíti, de nem replikálja a LastLogonTime attribútumot; replikálja a nem túl pontos LastLogonTimeStamp-et (mindkettő bejelentkezési időbélyeg); a Users és Computers tárolók átirányítása; az Authorization Manager az AD-ban képes tárolni funkció-alapú házirendjeit; Kerberos Secure Delegation az alkalmazások részére. |
| Windows 2008 natív mód (Windows 2008 native mode) | Windows Server 2008 Windows Server 2008 R2 Windows Server 2012 Windows Server 2012 R2 Windows Server 2016 | Csak olvasható tartományvezérlők (RODC); DFS-R replikáció a SYSVOL megosztás számára – a különbségi replikációs módszerrel magasabb tömörítési hatásfok érhető el; a Kerberos támogatja az AES 128/256 algoritmusokat; Last Interactive Logon Information, mely kijelzi a felhasználó utolsó sikeres interaktív belépésének idejét, az ehhez használt munkaállomást és a sikertelen belépések számát; finomhangolt jelszóházirend (a korábbi verziókban tartományonként, a 2008-tól akár szervezeti egységenként beállítható – de csak felhasználókra, nem számítógépekre vonatkozhat). |
| Windows 2008 R2 | Windows Server 2008 R2 Windows Server 2012 Windows Server 2012 R2 Windows Server 2016 | Hitelesítési mechanizmust biztosító funkció (Authentication mechanism assurance) – extra jogok adhatók a smart carddal való bejelentkezéskor;[10] felügyelt szolgáltatásfiókok jelszavainak és elsődleges szolgáltatásneveinek (SPN) automatikus kezelése (Automatic SPN management for Managed Service Accounts).[11] Active Directory-Lomtár (alapértelmezetten kikapcsolva; 2012 R2 alatt GUI is van hozzá).[12] |
| Windows Server 2012 | Windows Server 2012 Windows Server 2012 R2 Windows Server 2016 | A KDC szolgáltatás jogcímalapú hitelesítés, összetett hitelesítés és Kerberos-megerősítés (claims, compound authentication és Kerberos armoring) funkcióit kezelő felügyeleti sablon két beállításának kezelése (Mindig szükséges jogcímalapú hitelesítés és Utasítsa el a megerősítetlen hitelesítési kísérleteket; Always provide claims and Fail unarmored authentication requests) kívánja meg a Windows Server 2012 funkcionalitási szintet.[13] |
| Windows Server 2012 R2 | Windows Server 2012 R2 Windows Server 2016 | DC-oldali védelem a Protected Users („Védett felhasználók”) csoportnak. A Protected Users csoport tagjai Windows 2012 R2 szintű tartományban autentikáláskor többé:[14]
Új, erdő alapú felhasználói házirendek, amik korlátozzák, hogy a felhasználó milyen gépekről jelentkezhet be, valamint szabályozzák a szolgáltatásként bejelentkező felhasználók autentikációját. |
| Windows Server 2016 | Windows Server 2016 |
|
Az erdők között kisebb a lehetséges működési szintek száma.
| Működési szint (erdő) | Támogatott tartományvezérlők |
|---|---|
| Windows 2000 | Windows NT Server Windows 2000 Server Windows Server 2003 Windows Server 2008 Windows Server 2008 R2 |
| Windows 2003 köztes mód (Windows 2003 interim mode) |
Windows NT Server Windows Server 2003 |
| Windows Server 2003 | Windows Server 2003 Windows Server 2008 Windows Server 2008 R2 Windows Server 2012 Windows Server 2012 R2 (csökkent funkcionalitással, deprecated) |
| Windows Server 2008 | Windows Server 2008 Windows Server 2008 R2 Windows Server 2012 Windows Server 2012 R2 Windows Server 2016 |
| Windows Server 2008 R2 | Windows Server 2008 R2 Windows Server 2012 Windows Server 2012 R2 Windows Server 2016 |
| Windows Server 2012 | Windows Server 2012 Windows Server 2012 R2 Windows Server 2016 |
| Windows Server 2012 R2 | Windows Server 2012 R2 Windows Server 2016 |
| Windows Server 2016 | Windows Server 2016 |
A Windows Server 2003-as működési szintű erdő újdonságai:
- Erdőszintű bizalmi kapcsolatok (Cross Forest Trust)
- Nehézkesen, de megoldható a tartomány átnevezése
- Finomított replikáció: nem az egész tömb, csak a megváltozott elem replikálódik (Link valued replication)
- Sémaelemek inaktiválása és deaktiválása (törölni továbbra sem lehet)
- RODC, csak olvasható tartományvezérlő, a Windows 2008 újdonságaként itt is működik.
A Windows Server 2008 erdő-szinten nem hozott újdonságot. A Windows Server 2008 R2 erdő-szinten bevezetésre került az Active Directory lomtár. A Windows Server 2012 erdő-szinten nem hozott újdonságot. A Windows Server 2012 R2 erdő-szinten nem hozott újdonságot.
A Windows Server 2016-os működési szintű erdő újdonságai:
- Privileged access management (PAM) using Microsoft Identity Manager (MIM)
A tartományok közötti kommunikáció bizalmi kapcsolatokon (trusts) keresztül történik. Ez egy olyan hitelesítési csatorna, amely lehetővé teszi a tartományi felhasználók számára egy másik tartomány erőforrásainak elérését.
Fajtái (Windows 2000-natív módban):
- Egyirányú bizalmi kapcsolat (One way trust) – az egyik tartomány felhasználói hozzáférhetnek a másik tartomány erőforrásaihoz, de a másik tartomány felhasználóinak nem enged hozzáférést az elsőhöz.
- Kétirányú bizalmi kapcsolat (Two way trust) – két tartomány felhasználói hozzáférnek egymás erőforrásaihoz
- Tranzitív bizalmi kapcsolat (Transitive trust) – olyan bizalmi kapcsolat, ami a részt vevő két tartományon túl is kiterjeszthető.
- Nem tranzitív bizalmi kapcsolat (Intransitive trust) – olyan bizalmi kapcsolat, aminek a hatálya csak a részt vevő két tartományra terjed ki.
- Explicit bizalmi kapcsolat (Explicit trust) – a rendszergazda által létrehozott bizalmi kapcsolat. Nem tranzitív, és egyirányú (két egyirányú kapcsolat létrehozásával kvázi kétirányúvá tehető).
- Közvetlen bizalmi kapcsolat (Cross link/shortcut trust) – két külön tartományfában lévő tartományok, vagy egy tartományfán belüli, de szülő-gyermek viszonyban nem álló tartományok között létrehozott explicit bizalmi kapcsolat. Tranzitív, egy- vagy kétirányú.
Az erdő, illetve tartomány létrehozásakor a bizalmi kapcsolatok két alapértelmezett fajtája jön létre: a gyermektartomány létrehozásakor szülő–gyermek típusú (parent-child), kétirányú tranzitív kapcsolat, illetve új tartományfa létrehozásakor tartománygyökér szintű (tree-root), kétirányú tranzitív bizalmi kapcsolat jön létre. Az Új bizalmi kapcsolat varázsló vagy a Netdom parancssori eszköz segítségével négy további típusú kapcsolat hozható létre: külső (external), tartományi (realm), erdőszintű (forest) és közvetlen (shortcut) bizalmi kapcsolat.
Alapértelmezett bizalmi kapcsolatok (az Active Directory-telepítővarázsló hozza létre):[17]
| Kapcsolat típusa | Tranzitivitás | Irány | Leírás |
|---|---|---|---|
| Szülő–gyermek (Parent and child) | Tranzitív | Kétirányú | Új gyermektartomány létező tartományfához adásakor egy új, szülő–gyermek típusú bizalmi kapcsolat jön létre. Az alárendelt tartományok hitelesítési kérelmei szülőtartományaikon keresztül jutnak el a megbízó tartományhoz. |
| Tartománygyökér szintű (Tree-root) | Tranzitív | Kétirányú | Új tartományfa létező erdőben történő létrehozásakor új, tartománygyökér szintű bizalmi kapcsolat jön létre. |
Egyéb bizalmi kapcsolatok:[17]
| Kapcsolat típusa | Tranzitivitás | Irány | Leírás |
|---|---|---|---|
| Külső (External) | Nem tranzitív | Egy- vagy kétirányú | A külső bizalmi kapcsolat olyan erőforrásokhoz nyújt hozzáférést, amelyek Windows NT 4.0 alapú tartományban vagy egy másik erdőben lévő, erdőszintű bizalmi kapcsolattal nem rendelkező tartományban találhatók. |
| Tartományi (Realm) | Tranzitív vagy nem tranzitív | Egy- vagy kétirányú | A tartományi bizalmi kapcsolat egy nem Windows-alapú Kerberos-tartomány és egy legalább Windows Server 2003 alapú tartomány között jöhet létre. |
| Erdőszintű (Forest) | Tranzitív | Egy- vagy kétirányú | Az erdőszintű bizalmi kapcsolat legalább Windows 2003 rendszerű erdők közötti erőforrás-megosztásra használható. Ha az erdőszintű bizalmi kapcsolat kétirányú bizalmi kapcsolat, bármelyik erdő hitelesítési kérelme eljuthat a másik erdőhöz. Például nagyvállalatok összeolvadásakor lehet szükség rá. |
| Közvetlen (Cross link/shortcut) | Tranzitív | Egy- vagy kétirányú | A közvetlen bizalmi kapcsolat csökkenti az erdőn belül a két tartomány közötti bejelentkezési időt. Használata különösen hasznos, ha a két tartomány két külön tartományfában található. |
| PAM trust (Privileged Access Management) | ? | Egyirányú | A Microsoft Identity Manager által használt bizalmi kapcsolat, ami egy (potenciálisan alacsonyabb szintű) éles tartományi környezet erdőjéből mutat egy (Windows Server 2016 funkcionalitási szintű) „bástya” ('bastion') erdő felé, mely utóbbi képes az időkorlátos árnyék-csoporttagság, illetve a felhasználó ACCOUNTDISABLE flagje árnyékának számon tartására.[18][19] |
Az erdőszintű bizalmi kapcsolat a Windows 2003 újdonsága, legalább Windows 2003-as funkcionalitású szintű erdők között hozható létre. Ilyenkor az NTLM autentikáció nem jöhet szóba, kizárólag Kerberos 5-alapú.
Az Active Directory séma kiterjesztésével a Microsoft lehetőséget nyújtott az alkalmazások adatainak a címtárban való tárolására, azonban ez nem minden alkalmazás céljaira megfelelő. Az Alkalmazásmódú Active Directory (Active Directory Application Mode, ADAM) a Windows 2003 újdonsága, az Active Directory pehelysúlyú megvalósítása. Az ADAM Windows szolgáltatásként fut XP Professional vagy Windows Server 2003 operációs rendszerű számítógépeken. Az ADAM ugyanazt a címtár-szolgáltatási kódot használja, az Active Directory funkcionalitását nyújtja (azonos API-t), de nem kívánja meg tartományok vagy tartományvezérlők létrehozását (az ADAM telepíthető akár tartományvezérlőre, tagkiszolgálóra vagy munkacsoporti gépre is). Ha az AD jelen van, az ADAM képest azt használni hitelesítésre.
Az AD-hez hasonlóan az ADAM is egy a címtárobjektumok tárolására szolgáló hierarchikus adattárolóból (Data Store) és egy címtárszolgáltatásból (Directory Service) áll, amiket LDAP Directory Service Interface-en keresztül lehet elérni. Az AD-tól eltérően azonban egy szerveren több ADAM-példány is futhat, mindegyik külön adattárolóval, szolgáltatásnévvel és leírással. A Windows 2003 R2 verzióban található AD–ADAM szinkronizáló eszközzel az ADAM-példányba szinkronizálhatók az Active Directoryban meglévő objektumok.
Az ADAM adatbázisa logikai partíciókra van osztva:
- Konfigurációs partíció – az adott ADAM-példány beállításait tartalmazza.
- Sémapartíció – információt tárol arról, hogy milyen típusú adatok tárolhatók az adatbázisban.
- Alkalmazáspartíció – a tényleges, ADAM-ban tárolt adatok vannak itt.
Ha több példányban futtatjuk, minden ADAM példánynak különálló sémája van.
Több kereskedelmi gyártó kínál Active Directory-integrációs termékeket Unix platformokra (köztük a UNIX, Linux, Mac OS X platformok, valamint számos Java- és UNIX-alapú alkalmazás). A nagyobb gyártók közé tartozik a Thursby Software Systems (ADmitMac), a Quest Software (Vintela Authentication Services), a Centrify (DirectControl) és a Centeris (Likewise). A Microsoft szintén jelen van ezen a piacon ingyenes Microsoft Windows Services for UNIX termékével. A Linux és Unix operációs rendszerek újabb változatai különböző szinten működnek együtt az Active Directoryval, de hiányzik belőlük a fejlettebb Active Directory-képességek támogatása, mint például a csoportházirendeké vagy az egyirányú bizalmi kapcsolatoké. Lehetséges integrációs megoldás az is, hogy párhuzamosan másik címtárszolgáltatást is használunk, mint például a Fedora Directory Server (korábbi nevén Netscape Directory Server), ami azután két irányban szinkronizálódik az Active Directoryval. Így a Unix/Linux kliensek a Fedora szerverével autentikálódnak, a windowsos kliensek pedig az Active Directoryval.
Linux alatt az AD tartományba való integráció kliensként (vagy tartományi szerverként, de nem tartományvezérlőként) megvalósítható a szabad szoftver Samba (pontosabban a Kerberos, ntp, Samba és Winbind csomagok) segítségével.[20] A teljes értékű integrációt megcélzó Samba 4-es verzió 2012 decemberében jelent meg.
Ahhoz, hogy a Windows-alapú kliens számítógépek vándorló profilokat (roaming user profiles) használjanak, nincs feltétlenül szükség sem Active Directoryra, sem Windows-alapú fájlszerverre. A címtár teljes egészében lecserélhető valamely konkurens termékre, mint amilyen a Novell eDirectory. A Novell a Windows 2000 óta támogatja a vándorló profilokat ZENworks Desktop Management termékében, a Windows XP óta pedig a csoportházirend-objektumokat is – egyéb menedzsmentfunkciók, mint a távoli asztal megtekintése/vezérlésének átvétele, távoli alkalmazástelepítés, hardver- és szoftverleltár. A Novell kliens telepítésével a vándorló profil tárolódhat Novell fájlszerveren is.
A nem-Microsoft alapú címtárakkal való együttműködés során felléphet néhány probléma:
- a Novell megengedi azonos felhasználónevek alkalmazását, ha azok különböző szervezeti egységekben találhatók; az Active Directory ezt nem támogatja;
- a Novell a Windows 2000-alapú és a Windows XP-alapú felhasználói profilokat külön mappákba teszi, hasonlóan ahhoz, ahogy a Microsoft elkülöníti az XP- és Vista-profilokat;
- a kapcsolat nélküli mappákat nem teszi lehetővé az NCP protokoll;
- a windowsos kliens bejelentkezéskor alapértelmezésben ellenőrzi, hogy a profilt tároló mappa tulajdonosa megegyezik a felhasználó SID-jével, de ez kikapcsolható, így lehetséges az együttműködés más címtárakkal.
- Active Directory – felhasználók és számítógépek (ADUC – Active Directory Users and Computers). A leggyakrabban használt MMC-konzol, ezzel kezelhetők a címtár objektumai, létrehozhatók a felhasználói és számítógépfiókok, csoportok, szervezeti egységek, megosztott mappák és nyomtatók, illetve beállíthatók ezek tulajdonságai. Használható a tartományi szintű egyedi főkiszolgálói műveleteket (FSMO) végző tartományvezérlők megadására (RID Master, PDC Emulator, Infrastructure Master), a felügyeleti jogok delegálására és a tartomány működési szintjének emelésére is.
- Active Directory – helyek és szolgáltatások (Active Directory Sites and Services). Ez az MMC-konzol a tartományok közötti bizalmi kapcsolatok kezelésére szolgál. Szintén alkalmas a Domain Naming Master FSMO szerepkört ellátó kiszolgálót kijelölésére.
- Active Directory – tartományok és bizalmi kapcsolatok (Active Directory Domains and Trusts)
- Active Directory Séma (Active Directory Schema). Beépülő modul, a séma kezelésére szolgál, és ennek segítségével mozgatható másik tartományvezérlőre a Schema Master szerep is.
- DCPROMO – tartományvezérlővé való előléptetését/lefokozását végző varázsló
- ntdsutil [ halott link]] – címtárszolgáltatás-karbantartási segédprogram, alkalmazáspartíciók létrehozására is használható.
- Adprep [ halott link]] – Windows 2000 tartományok/erdők 2003-as frissítését készíti elő (sémát bővít, biztonsági beállításokat változtat, új címtárobjektumokat hoz létre)
- LDIFDE – AD-objektumok parancssori import/exportja, sémabővítés; a program által is használt LDIF-formátum az LDAP-címtárak közötti replikáció szabványa, így ezzel bármilyen művelet elvégezhető.
- egyéb parancssori segédprogramok: DSadd, DSmod, DSquery, DSmove, DSrm, DSget, CSVDE
- Active Directory felügyeleti központ (Administrative Center – PowerShell-alapú, Windows Server 2008 R2-ben jelent meg)
- Ez a szócikk részben vagy egészben az Active Directory című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.
- (angol)Windows 2000 Resource Kit: Active Directory[halott link]
- (magyar)Sulinet: AD alapok
- (magyar)Sulinet: Az Active Directory mélyebben – Az egyedi főkiszolgáló szerepkörök
- (angol)AD séma Archiválva 2008. január 25-i dátummal a Wayback Machine-ben
- (magyar)Bizalmi kapcsolat tranzitivitása[halott link]
- (magyar)A bizalmi kapcsolatok típusai
- (angol)Design Considerations for Delegation of Administration in Active Directory
- (angol)InformIT: Understanding Active Directory
- (magyar)Sulinet: Az AD funkcionalitási szintjei
- (magyar)TechNet: Windows Server 2008 – működési szintek[halott link]
- (angol)A 2782-es RFC
- (angol)Directory Replication Basics for Windows 2000
- (angol)How Active Directory Replication Topology Works
- (angol)Active Directory Maximum Limits
- (magyar)FSMO szerepkörök áthelyezése másik tartományvezérlőre
- (magyar)Active Directory alkalmazási módban[halott link]
- (magyar)TechNet: Az alkalmazásmódú Active Directory
- (magyar)TechNet: Az ADAM és az Active Directory összehasonlítása
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
