Active Directory

Design en Implementatie


Ontwerp

Aangezien we, voor onze 'zero administration' oplossing uitgebreid gebruik willen maken van Active Directory en de daarin voorhanden zijnde functionaliteit voor beheer van gebruikers, overdragen van beheer, groepsbeleid voor gebruikers- en computerconfiguratie, software deployment, enz., is een doordacht ontwerp van het Active Directory onontbeerlijk. Bovendien willen we de configuratie kunnen implementeren via scripts, iets waarbij we bij het ontwerp rekening moeten houden zodat de scripts niety onnodig complex worden.

We baseren het ontwerp van het Active Directory op de organizatiestructuur.

Organizational Units

We maken Organizational Units die gelijklopen met de kantoorindeling in teams

Bedoeling van deze indeling :

  1. Representatie van kantoororganisatie
  2. Granulariteit : domain group policy <=> OU group policy : laat een algemene policy te ontwikkelen (domain) + specifieke aanpassingen per team, bijvoorbeeld op vlak van
  3. OU als entiteit voor delegated control

Door de ‘team’ OU’s onder te brengen onder de OU kantoor blijft de MMC-tree overzichtelijk, en hebben we de mogelijkheid later nog andere eenheden naast kantoor binnen zelfde domein te beschouwen, vb visitors, vrijwilligers, leden, externe administrators, ...

Gebruikers en Groepen

Binnen de team-OU’s maken we groepen :

(Gebruikersaccounts van) personeelsleden worden lid van 1 (en slechts 1) groep binnen de OU van hun team. In de OU 'kantoor' maken we dezelfde groepen, en we maken de ‘team’ groepen lid van de gelijknamige ‘kantoor’groep, bijvoorbeeld : kantoor/teamleaders = VT/teamleader + CT/teamleader + FT/teamleader enz.

Op die manier kunnen gelijksoortige personeelsleden gegroepeerd worden op het niveau van ‘kantoor’ : alle Coördinatoren, alle Stagiairs, ... worden lid van respectievelijk de groepen kantoor\coordinatoren, kantoor\stagiairs, enz. (zie Figuur) Active Directory Design

Op deze manier kunnen gebruikersaccounts aangemaakt worden op het niveau van een organizational unit, en door lidmaatschap van slechts 1 groep binnen die organizational unit automatisch lid worden van alle relevante groepen. Bijvoorbeeld : Christine is gebruiker in OU ‘PT’ en lid van de groep ‘PT\Coordinatoren’, en is dus automatisch ook lid van 'kantoor/coordinatoren' en 'PT/team'. Bijgevol zullen we in staat zijn haar user configuration te bepalen aan de hand van ‘kantoor en ‘PT’ group policy, haar toegang tot resources te bepalen a.d.h.v. de genoemde groepen, o.a. bij het regelen van toegang tot bestanden en folders.

Bovendien is de structuur gelijkvormig in iedere ou, dus gemakkelijk te creëren aan de hand van een script (zie volgende hoofdsuk). De repetitieve versterkt de herkenbaarheid. Nadeel : ’t is een beetje ‘zwaar’ : in een kleine omgeving heb je evenveel (of meer) groepen dan gebruikersaccounts. Daar staat dan weer tegenover dat bij aangroei van het personeelsbestand, de gebruikers eenvoudigweg aan 1 en slechts 1 groep moeten toegevoegd worden en de structuur onveranderd en overzichtelijk blijft.

Om groepen te nesten moeten we opletten voor de group scopes : een groep die andere groepen moet kunnen bevatten, moet een domain local group zijn. Vandaar dat de groepen in de OU ‘kantoor’ domain local zijn : iedere groep in de OU kantoor heeft namelijk als leden de gelijknamige groepen in de onderliggende organizational units. De groep ‘Team’ in de ‘team-OU’s is eveneens een domain local groep, en omvat alle groepen in die OU (dus PT/Team = PT/Teamleaders + PT/Coordinatoren + PT/Administratieven + PT/Stagiairs).

Delegation of Control (Beheer overdragen)

Bedoeling : beheer van gebruikers en hun toegang tot shares overdragen aan teamleaders, per team. Op die manier kunnen zij, binnen de beperkingen van de eerder beschreven configuratie, een aantal beheerstaken uitvoeren, zoals gebruikers aanmaken, gebruikers lid maken van groepen, wachtwoorden beheren (resetten, ...), accounts beheren (enable, disable, unlock, ...). Dat moet er voor zorgen dat de ‘managed environment’ geen keurslijf wordt en enige flexibiliteit nog mogelijk is. Bijvoorbeeld : een user-account aanmaken voor een stagiair, en toewijzen aan een group binnen de OU, zodat de gebruiker de voor die groep toepasselijke user-configuratie en toegang tot bestanden krijgt.

We dragen beheer over door in MMC in het contextmenu van de OU te kiezen voor ‘Beheer overdragen’. Aan wie : de groep ‘TeamLeaders van die OU. Welke taken ? gebruikersaccounts maken en wijzigen, en toevoegen aan groepen, wachtwoorden. We kunnen ook aangepaste taken definiëren aan de hand van (het beheer over) Active Directory objecten : account-objecten, groep-objecten, gedeelde map objecten.

Microsoft Management Console

Om de TeamLeaders een beheersinstrument te geven creëren we een TeamLeader Console, ttz. een Microsoft Management console met volgende eigenschappen :

Opties : gebruikersmodus : beperkte toegang : 1 venster
Deze optie zorgt ervoor dat de gebruiker slechts 1 venster te zien krijgt en geen modules kan toevoegen. We kunnen hierbij tevens ‘geen wijzigingen opslaan’ aanvinken, zodat wijzigingen in de console niet opgeslagen worden. Op die manier krijgt de teamleider steeds hetzelfde scherm te zien als hij de console start.
Module : Active Directory Gebruikers en Computers
Deze module geeft toegang tot alle taken die we ons als doel hadden gesteld voor overdracht van beheer.

Door deze console in een gedeelde map op de server op te slaan is ze toegankelijk voor de teamleaders. We zetten NTFS security (teamleaders : lezen en uitvoeren), zodat de console slechts door deze groep gebruikt kan worden. Aangezien enkel de teamleaders beheer overgedragen gekregen hebben, is dit wellicht niet eens nodig, maar het lijkt me een goed idee.

Microsoft biedt ondersteuning voor MMC op oudere platformen (Windows NT, Windows 98) aan op http://www.microsoft.com/windows2000/technologies/management/mmc/.

Active Directory Setup

Net als bij de installatie van het serverbesturingssysteem geldt hier dat we later in staat willen zijn de setup van het active directory te reproduceren (bijv. voor disaster recovery, of bij aanschaf van een nieuwe machine, of voor een domain migratie). We voeren de setup dus uit a.d.h.v. aan answer file -- een zogenaamde ‘unattended setup’. De answer file is dan tevens de documentatie van de initiële setup van het Active Directory.
commando: dcpromo /answer:path_to_answerfile
bijvoorbeeld : dcpromo /answer:a:\dc_kicks.txt

de parameters


		DNSOnNetwork=no
		AutoConfigDNS=yes
	

geven aan dat er nog geen DNS server op het netwerk aanwezig is, en dat de AD Setup wizard er zelf een zal configureren. zie dc promo answer file : Answer File Reference : Windows 2003 CD : Deployment Tools : ref.chm

De dcpromo answer file laat toe de Active Directory setup te configureren. Merk bijvoorbeeld op op dat we de sysvol en ntds directories niet op de default locatie laten, maar op andere partities zetten. Het beste is eigenlijk van dat op verschillende harde schijven te doen. Volgens de documentatie van Microsoft is dit nuttig bij eventuele restore-procedures.

		
		logPath=D:\NTDS
		SysvolPath=D:\Sysvol
		DatabasePath=F:\NTDS
	

Active Directory configureren

Om, in een volgende stap, de data van het oude domain te integreren in het nieuwe domein, moeten we op dit punt eigenlijk user accounts aanmaken, zodat we de ACL’s van de bestanden kunnen zetten. Microsoft biedt (eindelijk) command line tools voor Windows, zodat het minder nodig is terug te vallen op ADSI scripting. Scripten d.m.v. commands in batch heeft mijn voorkeur, o.a. omdat de statements zowel in een script als aan de prompt uitgevoerd kunnen worden. Het is dus ‘intuïtiever’, ook al blijven de control structures van batch minder krachtig dan die van een complete scripting taal zoals vbs. Aan de hand van een script (een batchbestand dus ) maken we Organizational Units en gebruikers aan.
commando : dsadd ou OrganizationalUnitDN [-desc Description]
Script : createOU.bat

Vervolgens maken we groepen.
Commando : dsadd group GroupDN [-secgrp {yes | no}] [-scope {l | g | u}] [-samid SAMName]
Omwille van de repetitieve structuur, kunnen we dit doen aan de hand van enkele FOR lussen, zoals aangegeven in dit script : createUsers.bat

Op een gelijkaardige manier worden user accounts en computeraccounts aangemaakt. Analoog aan het creëren van user accounts kunnen we computeraccounts creëren via een command line, en in de Computer Distinguished Name de gepaste OU meegeven.
dsadd computer ComputerDN [-samid SAMName] [-desc Description] [-loc Location] [-memberof GroupDN ...]
Script : createComputers.bat


Koen Noens
June 7th, 2005
Alle rechten voorbehouden
Terug naar Inhoudstafel