Teil 2 - Konfiguration

Autor: olc, MCSEboard.de

Nach der Installation der AD LDS Rolle können sogenannte Instanzen angelegt werden. Instanzen sind die eigentlichen Verzeichnisse. An dieser Stelle wird ein weiterer großer Punkt deutlich, der die AD LDS von einer „normalen“ Active Directory (ab Windows Server 2008 genauer gesagt als „Active Directory Domain Services“ AD DS bezeichnet) unterscheidet und auch sehr nützlich macht: Es können auf einer Maschine mehrere Instanzen laufen, die vollkommen unabhängig voneinander sind.

: Abb. 07

Die Instanzen haben jeweils ein eigenes Schema, eigene Daten – besser Application Data Partitions - und können als jeweils eigener Dienst auch einzeln heruntergefahren, außer Betrieb genommen oder neu gestartet werden.

Klickt man nach also der Installation auf die AD LDS Rolle im Server Manager, werden noch keine Instanzen angezeigt (siehe Abb. 07).

Es können nun im mittleren Bereich der MMC neue Instanzen über den „AD LDS Setup Wizard“ hinzugefügt werden oder man kann direkt aus der MMC ADSIEdit oder LDP aufrufen. Den beiden Programmen kommt bei der Verwaltung von Instanzen eine besondere Rolle zu, da es keine eigenen Verwaltungstools für die AD LDS gibt. ADSIEdit und LDP sind ab Windows Server 2008 bei einer Standardinstallation gleich in aktualisierter Form mit dabei und müssen nicht wie unter den Vorgängerversionen der Windows Server Reihe nachinstalliert werden (siehe Abb. 08).

: Abb. 08

Im untersten Bereich der AD LDS MMC ist eine weitere Sektion verfügbar, die „Resources and Support“ Sektion (siehe Abb. 09). Hier setzt sich der oben angesprochene Ansatz fort, den Anwendern bzw. Administratoren dort Hilfestellung zu geben, wo sie benötigt wird. Neben Links als Einstiegspunkt zu Online Ressourcen hat Microsoft hier einige Best Practices aufgeführt, die den Betrieb der AD LDS betreffen. Man sollte sich diese Punkte am besten nicht nur einmal durchlesen und prüfen, ob die AD LDS Installation bzw. die jeweiligen Instanzen den Best Practices entsprechen.

: Abb. 09

Nun kann man eine neue Instanz anlegen. Hierzu wählt man den „AD LDS Setup Wizard“ in der mittleren Sektion „Advanced Tools“ aus und klickt sich durch die kommenden Wizard Seiten.

Da die AD LDS wie jeder normale Verzeichnisdienst verteilte Datenhaltung ermöglicht, gibt man im ersten Dialog des Wizards an, ob es sich bei der neuen Instanz um eine alleinstehende Instanz oder um ein Replikat handeln soll. Bei einer alleinstehenden Instanz kann später ein anderer Server als Replikat definiert werden – wir wählen daher in diesem ersten Beispiel den ersten Punkt. Im weiteren Verlauf des HowTos werden wir ein Replikat anlegen.

: Abb. 10: Wir wählen „A unique instance“ und klicken auf „Next“

: Abb. 11: Nun vergeben wir einen Namen für die Instanz; dieser sollte nach Möglichkeit nicht allzu lang, jedoch selbsterklärend sein.

Im nächsten Bildschirm legen wir die Ports fest, über die die Instanz angesprochen werden kann. Hier zeigt sich ein wichtiger Punkt für den Betrieb der AD LDS: da auf einer einzelnen Maschine mehrere Instanzen eingerichtet und gleichzeitig betrieben werden können, muss es ein Unterscheidungskriterium geben. Die Portnummern stellen dieses Kriterium dar. Standardmäßig liegt LDAP als „well known port“ auf Port 389 bzw. 686 bei LDAPS. Will man mehre Instanzen auf einer Maschine betreiben, müssen pro Instanz eigene Ports festgelegt werden. Spricht man den für eine Instanz festgelegten Port an, erhält man ausschließlich Zugriff auf die dahinterliegende Instanz, nicht auf die anderen (siehe Abb. 12).

: Abb. 12: Wir wählen exemplarisch die Ports 10.001 und 10.002

Dies lässt sich insofern leicht nachvollziehen, da jede Instanz nach dem Anlegen als Dienst fungiert (dazu später mehr). Hinter einem Port kann immer nur ein Dienst „hören“ – zumindest bei den meisten Betriebssytemherstellern. Es gibt auch Ausnahmen, die sind jedoch für dieses HowTo nicht relevant. Ein Socket, also IP-Adresse + Portnummer, definiert den anzusprechenden Dienst – und genau dieses Prinzip nutzten auch die AD LDS.

Im nächsten Dialogfeld kann festgelegt werden, ob eine eigene Applikationsdatenpartition angelegt werden soll oder nicht. In der Praxis gibt es einige Third-Party Applikationen, die während der Installation eigene Verzeichnisdienstpartitionen anlegen. In diesem Fall würde man hier die erste Option wählen.

: Abb. 13

Da wir hier für unsere Beispiele keine Applikation verwenden werden, die die Partition anlegt, wählen wir die zweite Option. Es muss hierbei der Pfad der Anwendungspartition angegeben werden; hierbei kann der aus AD Umgebungen bekannte „Distinguished Name“ verwendet werden (siehe Abb. 13), aber auch ein LDAP / X.500 DN-Pfad in der Form „CN=<Objekt>,OU=<Organisationseinheit>,C=<County>O=<Organisation>“. Dieser Pfad muss später für die verwendeten Applikationen oder Dienste, die auf das Verzeichnis bzw. die Instanz zugreifen sollen, „lesbar“ sein, d.h. diese müssen das entsprechende Format nutzen / interpretieren können.

: Abb. 14

Der nächste Bildschirm erlaubt uns festzulegen, wo die Datenbank und die Logfiles abgelegt werden sollen. Hier können – wie auch bei anderen datenbankbasierenden Systemen – die Datenbank und die Logfiles getrennt abgelegt werden (siehe Abb. 14). Dies ist im Einzelfall zu prüfen und zu entscheiden. Für unser Beispiel legen wir beides im gleichen Verzeichnis des gleichen Volumes ab. Die Datenbank ist wie die Active Directory Datenbank eine JET-Datenbank.

Da es im nächsten Schritt notwendig sein wird, einen Service-Account festzulegen, unter dessen Rechten die neu anzulegende Instanz läuft, legen wir nun einen Benutzer auf dem Server an. Dies ist notwendig, da sich unser Server nicht in einer Active Directory Umgebung befindet. Sollte dies der Fall sein, kann entweder ein Domänen-Account genutzt werden oder der vordefinierte Account „Network Service“.
Die von uns angelegten lokalen Accounts müssen auf allen Systemen gleich sein bzw. die entsprechenden Rechte haben, auf den später Replikate einer Instanz liegen sollen. Die Benutzer bzw. Systemaccounts wie „Network Service“ haben bei Member Servern in Active Directory Umgebungen übergreifende Rechte – in Arbeitsgruppen wie in unserem Beispiel müssen die Sicherheitsprinzipale auf den beteiligten Systemen bekannt sein. Will man keine Replikation für die entsprechende Instanz ermöglichen, kann auch in Arbeitsgruppenumgebungen der „Network Service“ Account genutzt werden.

HINWEIS: Wie auch bei anderen Service Accounts sollte der Account keine administrativen Rechte besitzen – weder auf der Maschine, noch (falls vorhanden) in einer Active Directory Umgebung. Dies stellt eine große Sicherheitslücke dar und sollte grundsätzlich vermieden werden.

Ein neuer Benutzer kann z.B. über den Server Manager unter „Configuration“ --> „Local Users and Groups“ --> „Users“ hinzugefügt werden.

: Abb. 15: Wir legen einen neuen lokalen Benutzer an, der auch auf anderen Systemen eingerichtet werden kann.

: Abb. 16: Diesen Account nutzen wir als Service Account für unsere Instanz „instance1“

: Abb. 16_1: Die Nachfrage, ob dem Account „run as a service“ gegeben werden sollen, beantworten wir „Yes“

: Abb. 17

Im nächsten Dialog wird abgefragt, welcher Benutzer bzw. welche Gruppe die Verwaltung der neuen Instanz übernehmen darf. Da eine Gruppenorganisation meist mehr Sinn macht als einzelne Benutzer festzulegen, legen wir eine neue Gruppe an, deren Mitglieder die Verwaltung der Instanz übernehmen werden.

Eine neue Gruppe kann z.B. über den Server Manager unter „Configuration“ --> „Local Users and Groups“ --> „Groups“ hinzugefügt werden (siehe Abb. 17).

: Abb. 18

Als Mitglied dieser Gruppe fügen wir beispielsweise den Account hinzu, unter dem wir gerade arbeiten (in unserem Beispiel: „Administrator“). Aber Achtung: da die Security Token nur bei der Anmeldung eines Benutzers geschrieben werden, muss sich der Benutzer, der der Gruppe hinzugefügt wurde, erst neu am System Anmelden / Authentifizieren, da sonst die neue Gruppenmitgliedschaft nicht im Benutzertoken aufgeführt ist und somit keine Verwaltung der neuen Instanz erlaubt wird. Die angelegte Gruppe geben wir dann als verwaltungsberechtigt im "AD LDS Administrators" Dialog an (siehe Abb. 18).

Als nächsten Schritt müssen wir uns entscheiden, welche LDIF-Files wir für die neue Instanz importieren möchten (siehe Abb. 19). Microsoft liefert einige davon standardmäßig mit – wie oben erwähnt, liegen diese im „%SYSTEMROOT%\ADAM“ Verzeichnis. Die LDIF-Files enthalten Definitionen, wie das Schema mit Klassen und Attributen aussehen soll. Jede Instanz hat unter den AD LDS Ihr eigenes Schema, eine eigene „Configuration“ Partition und eine oder mehrere eigene Applikationsdatenpartitionen. Will man ein Objekt in der Anwendungsverzeichnispartition anlegen – wir haben unsere oben „CN=instance1,DC=testdom,DC=intern“ genannt – muss eine entsprechende „Vorlage“, also Schemaklassen inkl. der verfügbaren Attribute existieren. Ohne diese Schemadefinitionen gibt es keine Templates, wie ein Objekt (also z.B. ein Benutzerobjekt, ein Computerobjekt etc.) aussehen kann, welche Eigenschaften dieses Objekt haben kann usw.

Einige Drittapplikationen bringen ein eigenes Schema mit. Ist dies der Fall, kann hier diese Schemadefinition importiert werden. Hier zeigt sich wieder ein weiteres wichtiges Kriterium, warum die AD LDS als sinnvolle Ergänzung zu den AD DS gesehen werden müssen: während es ohne die AD LDS nur möglich ist, innerhalb des AD DS Schemas Erweiterungen vorzunehmen, die nicht (bzw. nicht so einfach) rückgängig gemacht werden können, und die im gesamten Forest verteilt werden, kann man die AD LDS nutzen, um diese Erweiterungen extern vorzunehmen. Benutzer / Dienste / Applikationen greifen in diesem Fall nicht mehr auf die AD DS Datenbank und deren Schema zu, um die Informationen zu bekommen, sondern auf die AD LDS. Läuft hier etwas schief bei der Erweiterung oder bei Änderungen im Schema, ist nur die entsprechende AD LDS Instanz betroffen, nicht die gesamte Active Directory Umgebung.

Man kann die Schema-Definitionen jedoch auch später laden, indem man die entsprechenden LDIF-Files via „LDIFDE“ importiert. Es liegen standardmäßig weitere Vorlagen im o.g. Verzeichnis, um das Instanz-Schema auf eine Replikation mit einer AD-Umgebung vorzubereiten. So können auch definierte Verzeichnisdienstpartitionen mit einer Active Directory synchronisiert werden, wenn dies erforderlich ist.

Nachdem wir die Zusammenfassung der Installationsaufgaben geprüft haben (siehe Abb. 20), bestätigen wir das Anlegen der Instanz mit „Next“ und warten auf die erfolgreiche Fertigstellung des Prozesses (siehe Abb. 21).

: Abb. 19

: Abb. 20

: Abb. 21

Nachdem die Instanz erfolgreich angelegt wurde, finden wir diese im Server Manager, wo einige Verwaltungsaufgaben wie das Starten und Stoppen des Dienstes möglich sind (siehe Abb. 22). Öffnen wir die Dienste MMC (services.msc), finden wir dort einen neuen Dienst mit dem Anzeigenamen „instance1“ und dem Dienstnamen „ADAM_instance1“ (siehe Abb. 23). Prüft man die Service Eigenschaften, finden sich die gerade im Wizard festgelegten Punkte wieder (siehe Abb. 24.1 + 24.2). Hierbei ist auch gut zu sehen, welcher Prozess sich hinter den AD LDS Diensten verbirgt: Unterhalb von „%SYSTEMROOT%\system32\dsamain.exe“ laufen die einzelnen Instanzen, über den Service Namen (Option „-sn:instance1“) angesprochen werden.

: Abb. 22

: Abb. 23

: Abb. 24_1

: Abb. 24_2