Teil 4 - Replikation zweier AD LDS ServerEinführung in die Active Directory Lightweight Directory Services (AD LDS) unter Windows Server 2008

Teil 5 - Abschließendes

Autor: olc, MCSEboard.de

 

Der Einstieg in das Thema ist gemacht – es können nun beliebige Applikation an die vorhandene Instanzen gebunden werden oder neue Instanzen angelegt werden.

Es gibt jedoch noch ein paar Themen, die danach auf dem Fahrplan stehen. Beispielhaft seien ein paar davon in aller Kürze angesprochen:

So müssen etwa die Daten gesichert werden, um Datenverluste zu vermeiden. Grundsätzlich reicht es hier, die Datenbanken und die Logfiles zu sichern. Um diese Wiederherzustellen muss der jeweilige Instanz-Dienst gestoppt werden und die Daten zurück in das Verzeichnis der Instanz gesichert werden. Stoppt man den Dienst nicht, werden die Daten nur im RAM gehalten, solange die Instanz aktiv ist. Startet man den Dienst neu, sind alle Änderungen verloren. Hier wird von Microsoft empfohlen, die alten Daten der jeweiligen Instanz vor dem Wiederherstellen aus dem „data“ Verzeichnis komplett zu löschen.
Ist die Instanz des Servers jedoch Mitglied in einem „configuration set“, ist der Aufwand höher, da es hierbei einige Dinge bei der Wiederherstellung zu beachten gibt. Auch werden hier wieder Themen wie die „autorisierende Wiederherstellung“ (authoritative restore) relevant, sollten Daten versehentlich gelöscht worden sein. Hier empfiehlt sich ein Blick in die Hilfe der AD LDS. Diese behandelt das Thema sehr genau und ist ein guter Leitfaden, sich einen Desaster Recovery Plan zu erarbeiten. Wie immer gilt: Ein Backup nützt rein gar nichts, wenn die Daten nach der Sicherung nicht geprüft und keine Wiederherstellungstests durchgeführt werden.


Weiterhin stehen Themen wie Authentifizierung und Autorisierung auf der Liste. So muss man entscheiden, ob man in den AD LDS Benutzer erzeugt, die Rechte innerhalb der Instanzen haben oder ob man eine Authentifizierung gegen eine AD vornehmen möchte. In diesem Fall müssen sogenannte Proxyobjekte erzeugt werden, die die Authentifizierung eines Benutzers an die AD weiterleiten.

Zur Autorisierung von Sicherheitsprinzipalen kann DSACLS verwendet werden. Will man etwa dem Benutzer „Testuser1“ das Recht geben, alle Objekte unterhalb des Containers „Test1“ mit Vollzugriff zu bearbeiten, sieht die Kommandozeile dazu in etwa so aus:

C:\Users\Administrator>dsacls "\\VM-W2K8-01:10001\CN=Test1,CN=instance1,DC=testd
om,DC=intern" /G "CN=Testuser1,CN=Test1,CN=instance1,DC=testdom,DC=intern":GA
Owner: CN=Administrators,CN=Roles,CN=instance1,DC=testdom,DC=intern
Group: CN=Administrators,CN=Roles,CN=instance1,DC=testdom,DC=intern

Access list:
Allow CN=Testuser1,CN=Test1,CN=instance1,DC=testdom,DC=intern
                                      FULL CONTROL
Allow CN=Readers,CN=Roles,CN=instance1,DC=testdom,DC=intern
                                      SPECIAL ACCESS   
                                      READ PERMISSONS
                                      LIST CONTENTS
                                      READ PROPERTY
                                      LIST OBJECT
Allow CN=Administrators,CN=Roles,CN=instance1,DC=testdom,DC=intern
                                      FULL CONTROL   

Permissions inherited to subobjects are:
Inherited to all subobjects
Allow CN=Readers,CN=Roles,CN=instance1,DC=testdom,DC=intern
                                      SPECIAL ACCESS   
                                      READ PERMISSONS
                                      LIST CONTENTS
                                      READ PROPERTY
                                      LIST OBJECT
Allow CN=Administrators,CN=Roles,CN=instance1,DC=testdom,DC=intern
                                      FULL CONTROL   

The command completed successfully

Will man gar eine Instanz löschen, so kann man dies in der Systemsteuerung tun; dort werden alle Instanzen aufgeführt und können über eine Deinstallation entfernt werden (siehe Abb. 41).

Abb. 41

Ein grundsätzlicher Hinweis noch zum Schluss: man kann nicht oft genug betonen, dass es sich bei LDAP Diensten nicht um Datenbanken im eigentlichen Sinne handelt. LDAP Verzeichnisse sind auf Lese-Vorgänge optimierte Datenbanken, die nicht für Zwecke wie Datenhaltung beispielsweise für Webapplikationen taugen. Ein Verzeichnis stellt man sich gemeinhin wie ein Telefonbuch vor, nicht wie eine Datenbank mit Bildern oder Excel Dokumenten in Binärform (wie beispielsweise „Microsoft SQL Server“ oder „MySQL“ etc.). Man sollte also den Anwendungszweck genau prüfen und nicht einen Verzeichnisdienst mit solchen Datenbanken verwechseln.


Letztendlich lässt sich sagen, dass die AD LDS sehr interessante Anwendungsgebiete erschließen: nicht etwa als Ersatz für die Active Directory Domain Services, vielmehr als sinnvolle Ergänzung je nach Anwendungsszenario. Obwohl sie recht klein gehalten wurden, sind sie in Ihrer Anwendung doch recht komplex – gerade was die weiterführenden Themen zu dieser Materie betrifft. Man sollte sich also auch hiermit ausgiebig beschäftigen, um nicht in dieser vermeintlich kleinen Technik seinen Meister zu finden.

 

 

© MCSEboard.de, olc

Teil 4 - Replikation zweier AD LDS ServerEinführung in die Active Directory Lightweight Directory Services (AD LDS) unter Windows Server 2008