Active Directory begrepen

Dit artikel verscheen eerder in Windows en Netwerken

Wim Verveen, e-mail: wim@win2kwereld.nl

 

De introductie van de Active Directory is in de Windows wereld behoorlijk ingrijpend geweest. Hoewel de meest essentiële functie, het beheer van gebruikers centraal staat in beide systemen zijn de verschillen groot. Deze keer wil ik u kennis laten maken met een aantal van de belangrijke eigenschappen van de Active Directory (AD) en verschillen met de NT 4 SAM. We gaan hierbij niet kijken naar diepgaande technische aspecten maar vooral de praktische kanten komen aan bod. Aan de hand van een realistisch scenario zullen de meest belangrijke begrippen de revue passeren.

Wat is nu eigenlijk de Active Directory? Door alle marketing hype is het nog wel eens moeilijk door de bomen het bos te zien. Het is echter allemaal eenvoudiger dan de naam doet vermoeden. Active Directory is primair een database, niet meer en niet minder. De database is ontworpen om te dienen als een directory, een index van objecten met hun eigenschappen. Een Windows 2000 Standalone server gebruikt geen Active Directory maar de SAM als basis voor authentificatie. Wanneer we een Windows 2000 Domein bouwen zal op een domaincontroller de SAM worden vervangen door de Active Directory database. De SAM zal echter nooit helemaal verdwijnen, ook op een domaincontroller blijft deze aanwezig. Hij is nodig om aan te kunnen loggen in de Active Directory herstel modus.
Wat is nu het grote voordeel van het gebruik van de AD ten op zichte van de SAM? De SAM is qua techniek behoorlijk veroudert, het heeft zijn wortels in het in de jaren 80 ontstane LAN manager toen het aantal gebruikers nog relatief beperkt was.
De SAM is onderdeel van de Windows NT registry en als zodanig onderhevig aan beperkingen, er kunnen daardoor maar maximaal 40000 objecten (gebruikers, groepen, werkstations) worden opgeslagen. In de praktijk zijn Windows NT domeinen met 10000 of meer objecten al moeilijk te beheren.
Het replicatiemodel is ook absoluut niet geschikt voor Enterprise omgevingen. In het PDC (Primary Domain Controller) en BDC (Backup Domain Controller) model repliceert de PDC zijn wijzigingen naar de BDC's. Dit master/slave model werkt misschien goed in een wat kleinere omgeving maar wanneer het aantal BDC's oploopt tot tientallen of misschien wel honderden BDC's wordt de PDC zwaar belast.
Toen de SAM werd ontwikkeld waren veel onderdelen van de huidige IT infrastructuur nog helemaal niet aanwezig. Het is niet mogelijk om de SAM te voorzien van nieuwe objecten waardoor de functionaliteit wordt ingeperkt. De objecten die er wel zijn kunnen ook niet hiërarchisch worden geordend, waardoor het niet mogelijk is om de structuur van het bedrijf te reflecteren in het domein.
Het opsplitsen van het domein in een single master of multiple master structuur is een oplossing voor een deel van deze problemen maar creëert ook nieuwe zoals groeiende beheerinspanning. Als laatste is het niet mogelijk om de verantwoordelijkheden eenvoudig te delegeren de mogelijkheden blijven beperkt tot speciale bevoegdheden zoals accountmanagement als geheel, het is niet instelbaar voor bijvoorbeeld een afdeling in het domein.
Deze problemen zijn in Active Directory aangepakt. Door een aparte database te gebruiken wordt de registry limiet opgeheven en kunnen er meer dan 10000000 objecten worden opgenomen. Het PDC/BDC model is vervangen door een multimaster replication model waar alle domaincontrollers veranderingen kunnen accepteren. Er kunnen nu ook meer objecten worden opgenomen door een uitbreidbaar Schema, zeg maar het database model.
Met een hiërarchie van Organizational Units en de mogelijkheid tot delegatie van permissies is de Active Directory ook flexibeler in te delen. Het is echter niet zo dat alle problemen nu uit de wereld zijn. De AD is nog een 1.0 versie en er zijn dan ook nog tal van problemen te vinden in dit nieuwe product. Het is ook weer niet zo dat de AD niet bruikbaar zou zijn, voor de meeste omgevingen is het prima geschikt, het is echter wel belangrijk te begrijpen dat de AD iets totaal anders is dan de SAM en dat dit betekent dat u hier ook heel anders mee om moet gaan.

Nieuw met de komst van Active Directory is de omarming van DNS als lokalisatie systeem. Het is zeer belangrijk om dit te realiseren, zonder een werkende DNS is er geen werkende AD. Dit betekent dus ook dat er extra aandacht moet worden besteedt aan de inrichting en het behoudt van de integriteit van dit systeem.
In grote bedrijven wordt het DNS meestal streng bewaakt en dat niet zonder reden. Als vervelend bijeffect betekent dit dat het vaak lastig is om een goed DNS systeem voor Windows 2000 toe te voegen aan de bestaande infrastructuur. Het is echter zeer goed mogelijk beide werelden op elkaar aan te sluiten. Bij voorkeur is dit te bereiken door een delegatie van DNS waarbij een deel van de bestaande structuur van DNS wordt afgehandeld door de Windows 2000 DNS. Dit betekent dat een subdomein van de bestaande structuur wordt toegewezen aan de Windows 2000 DNS. Dat ziet er in een DNS naam uit als 'windows.bedrijf.nl' Waarbij bedrijf.nl wordt gecontroleerd door de hoofd DNS en windows.bedrijf.nl door de Windows 2000 DNS.
In een wat kleiner bedrijf is een dergelijke structuur meestal niet aanwezig, soms is er zelfs helemaal geen DNS. In zo'n geval is het van net zo'n groot belang om de DNS goed in te richten. Dit betekent dat er in het algemeen nog een domeinnaam moet worden vastgelegd. Het is verleidelijk om als DNS naam te kiezen zoals de pas geregistreerde internet domein naam. Dit kan echter een gevaarlijke val vormen. Zo'n geregistreerde domeinnaam is niet hetzelfde als een delegatie zoals in de eerder geschetste situatie. Bij een officieel gedelegeerde domeinnaam zal een zoekopdracht naar
www.bedrijf.nl altijd leiden naar de juiste DNS server. Bij een registratie zal deze leiden tot de DNS server van de ISP. Meestal geen probleem, maar DNS is het lokatiemechanisme van de AD en dit kan ertoe leiden dat in zo'n geval de AD onvindbaar wordt.
Voor een wat kleiner bedrijf is het dus meestal makkelijker om een domein naam te gebruiken die niet conflicterend werkt. Een veilige keuze is dan de variant bedrijf.local. Deze benaming is niet geldig op het internet en dus prima geschikt voor intern gebruik.
Wanneer aan deze eenvoudige regels wordt voldaan kan met behulp van het Wizard gestuurde Dcpromo proces de installatie eenvoudig worden uitgevoerd.

Het eindresultaat is dan een Windows 2000 domein met een enkele domein controller. Dat is natuurlijk nog maar een beperkte setting. Het inrichten van een tweede DC als ondersteuning is natuurlijk een belangrijke tweede stap. Wanneer deze wordt ingericht in het zelfde subnet heeft dit weinig om het lijf maar brengt toch een aandachtspunt naar voren, namelijk de sysvol share en AD replicatie. Sysvol bevat de group policies, de opvolger van system policies onder Windows NT 4. De tweede domaincontroller zal niet actief worden zonder dat deze policies zijn gerepliceerd. Het promotieproces en de replicatie zijn, alweer, afhankelijk van het DNS mechanisme en problemen op dit punt voorkomen dat de tweede DC online kan komen. Wanneer er in een later stadium problemen optreden met het sysvol kan dit leiden tot diverse vervelende problemen bij het functioneren dus controleer regelmatig of de NTFRS service geen foutmeldingen geeft.

 

Stel nu dat we het aantal DC's uitbreiden met nog een extra DC in een ander subnet. Hierbij begint een wat meer bijzondere situatie te ontstaan. Nu zijn er ruwweg twee mogelijkheden. De DC bevind zich in een ander subnet op het LAN of op een ander subnet op een andere lokatie. In beide gevallen moet extra werk worden verricht. Active directory deelt namelijk het forest (de verzameling domeinen) in naar sites, ofwel lokaties.We zullen de AD moeten vertellen dat het nieuwe subnet onderdeel is van deze lokatie. Dit kan met behulp van de MMC tool 'sites and services'. Hier kunnen we een nieuwe site aanmaken voor de locatie en daar vervolgens een nieuw subnet aan verbinden.
Wanneer we dit hebben gedaan kunnen we een nieuwe DCPromo starten en DC nummer drie bekend maken. Er is nu een belangrijk verschil met de eerdere situatie. Dit begon al nog voordat we de DCPromo startten. Een onderzoek in het eventlog zal uitwijzen dat de andere domain controllers meldden dat zij de nieuwe site gaan 'coveren'. Dit is niet meer dan dat er een aantal DNS records worden aangemaakt die een werkstation in staat stellen om de juiste DC vinden om aan te melden. Nadat de DCPromo zijn werk heeft gedaan zal een soortgelijke melding verklaren dat de nieuwe DC het werk heeft overgenomen. Er is echter nog meer veranderd, de derde DC zal moeten repliceren met de andere twee om veranderingen in de AD te ontvangen. Het mechanisme hiertoe wordt gestuurd door zogenaamde sitelinks. Een sitelink legt vast met welke server moet worden gerepliceerd. Sitelinks zijn altijd van het type pullreplicatie, wijzigingen worden dus van een andere machine afgehaald. Om het proces dus volledig te laten werken moet er dus ook een omgekeerde link naar een van de andere servers bestaan.
Nu er een redelijk complete omgeving begint te ontstaan worden ook een aantal andere begrippen belangrijk. Zo is er het inrichten van Global Catalogs (GC). Het doel van de global catalog is dienen als een index van een forest. U kunt zich voorstellen dat een forest kan bestaan uit een grote verzameling domeinen, elk met hun objecten. Wanneer een gebruiker aanlogt of er worden bronnen binnen het forest benadert zal er veel tijd worden verloren met het lokaliseren van deze objecten. De Global Catalog lost dit probleem op door een gedeeltelijke kopie te bewaren van alle objecten in het forest. Wanneer er nu gegevens moeten worden opgevraagd kan direct de GC worden benadert die meestal over voldoende informatie beschikt. Deze snelheidsverbetering heeft echter een prijs, deze informatie moet wel naar de GC worden gerepliceerd, het is dus zaak een goede afweging te maken over de plaats waar de GC's worden geplaatst. en het aantal GC's wat wordt ingezet. In een enkel domein ligt dit wat simpeler, hier kan van elke DC een GC worden gemaakt zonder dat er extra verkeer wordt gegenereerd, de GC bezit immers al alle gegevens, zo kan met weinig inspanning performanceverbetering worden geboekt.

De Active Directory kent weliswaar een multi-master replicatiemodel waarbij elke wijziging overal kan worden uitgevoerd maar er zijn een aantal activiteiten die slechts op één DC tegelijk kunnen worden gedaan. Hiervoor zijn de zogenaamde FSMO (Flexible Single Master Operation) rollen in het leven geroepen. Kritische activiteiten kunnen alleen worden uitgevoerd op de DC met de bijbehorende rol.
Er zijn totaal 5 rollen, de Schema master is verantwoordelijk voor wijzigingen aan het database model, de Domain naming master voor het toevoegen en verwijderen van domeinen, de RID master voor het uitgeven van RID's , zeg maar serienummers voor objecten, de PDC emulator voor de compatibiliteit met eerdere Windows versies en de infrastructure master  is verantwoordelijk voor interdomein operaties.
Het uitvallen van een van de masters zal betekenen dat de betreffende functie niet meer kan worden uitgevoerd. Dit is over het algemeen niet direct acuut maar bij een aantal van deze rollen is ingrijpen toch gewenst. Bij voorkeur door het weer opbrengen van de master, het is echter ook mogelijk te rollen geforceerd over te dragen op een andere DC, het zogenaamde seizen. Wees u ervan bewust dat dit meestal betekent dat de oude Master moet worden verwijdert.

Spelenderwijs heeft u nu kennis kunnen maken met de opbouw en structuur van een Windows 2000 domein. Het moge duidelijk zijn dat de verschillen met het verleden groot zijn en dat u hiermee rekening dient te houden. Als u echter de regels in acht neemt kunt u werken met een uitermate verbetert systeem om uw gebruikers database en applicaties te beheren. Met de aankomende .NET server zijn veel van de gebreken die in Active Directory zijn aangetroffen nog verder verbeterd waardoor het u nog beter van dienst kan zijn.

 

W. Verveen is verbonden aan Ormer ICT dienstverlening als Consultant, daarnaast beheert hij Windows 2000 Wereld
E-mail: w.verveen@ormer.nl
Web: http://www.ormer.nl en http://www.win2kwereld.nl

privacy policy