AD LDS-Server

Einige Aspekte zum Betrieb habe ich auf den Seiten AD LDS Zertifikate für LDAPS und AD LDS, Set-ADUser und Firewall schon beschrieben. HIer sind dann die sonstigen Themen gesammelt, die keine eigene Seite bekommen haben.

Mit ADAM arbeiten

Was Sie nun installiert haben, ist ein LDAP-Server mit den grundlegenden Strukturen und einen Benutzer, der über entsprechende Berechtigungen verfügt. Ansonsten können Sie mit diesem LDAP-Server alles anstellen, was Sie auch mit dem Active Directory machen können. Nur zur Authentifizierung eignet sich ADAM nicht.

Mit der Installation von ADAM wird auch eine ADAM-taugliche Version von ADSIEDIT mitgeliefert und auch eine ADAM-taugliche Version der Schema-Snapins. Aber auch Hilfsprogramme wie der "ADSchemaAnalyzer.exe" und "adamsync.exe" haben sich auf die Festplatte breit gemacht.

ADAM lesen und schreiben

Wie jeder andere LDAP-Server auch, können Sie die ADAM-Instanz einfach per ADSI und LDAP ansprechen. Nur muss diesmal explizit der Hostname und optional auch Port mit angegeben werden, damit ADSI nicht automatisch das Active Directory nutzt, z.B.:

Set ou = GetObject("LDAP://localhost:50000/dc=msxfaq")

Wenn Sie statt dessen einfach nur folgendes versuchen, dann wird ADSI im Active Directory versuchen diesen Kontext zu finden.

Set ou = GetObject("LDAP://DC=MSXFAQ")

Das geht natürlich daneben. Die die Anmeldung hingegen kann ADSI und ADAM schon ihre aktuellen Anmeldedaten nutzen.

Wenn Sie einmal die DNs der verschiedenen Partitionen vergessen haben, dann starten sie einfach das Programm LDP und verbinden sich mit dem LDAP-Server. LDP zeigt nach der Verbindung die Funktionalitäten und auch die vorhandenen "Naming Context"-Einträge an.

Wenn ich heute mit AD LDS arbeite, dann nutzt ich allerdings nicht mehr VBScript sondern nutze fast immer die PowerShell. Dazu hat Microsoft selbst einen Blog-Artikel geschrieben.

AD LDS füllen

Natürlich können Sie per LDAP direkt Objekte in AD LDS eintragen, die dann von anderen Diensten genutzt werden. In vielen Fällen gibt es die Daten aber schon in einer anderen Quelle und oftmals ist das ein Active Directory. Für den Zweck hat Microsoft sogar ein Programm im Lieferumfang mit AD LDS installiert.

Siehe dazu ADAMSync

ADAMSync ist kostenfrei aber in der Funktion eingeschränkt. So kann es keine Felder umschreiben und repliziert nur vom Active Directory zu ADAM in einer Richtung. Auch werden keine Kennworte mit abgeglichen und auch das "Delete" ist über Aging gelöst.

Aus diesem Grunde gibt es mehrere Alternativen:

  • MIIS
    Der Microsoft Identity Integration Server ist das Produkt von Microsoft, um mehrere Verzeichnisse miteinander abzugleichen. Schade dabei ist, dass der Server nicht mal schnell installiert ist, sondern er zum einen 25.000 US$ kostet, einen SQL-Server und Windows Enterprise Server benötigt und auch sonst eben nicht mal schnell für den Abgleich von einigen Kontakten eingesetzt werden kann. Man muss sich schon damit beschäftigen. Dafür kann er dann aber auch wirklich nahezu alle Quellen und Ziele beschreiben und auch Kennworte abgleichen
  • MiniSync
    Als "kleine Lösung" habe ich mir mit MiniSync eine auf VBScript basierte kleine Lösung geschaffen, mit der ich aus einem Verzeichnis Informationen auslese und in ein Ziel synchronisiere. Ich kann auch Feldinhalte im Ziel nach meinen Wünschen anpassen aber natürlich keine Kennworte abgleichen.

Es gibt mittlerweile noch andere Werkzeuge zum LDAP-Abgleich verschiedener Hersteller. Aber die wenigsten sind für kleines Geld zu bekommen. Auf der Seite Verzeichnisabgleich finden sie einige Link.

Proxy Authentication

Eine besondere Funktion von ADAM ist die Weiterleitung einer Anmeldung. Ich kann mit ADAMSync nicht nur einen Benutzer aus einem Forest in eine AD LDS-Instanz replizieren sondern auch einen Verweise auf die Quelle bereitstellen. ADAM repliziert natürlich keine Kennworte und ist auch kein Anmeldedienst. Normalerweise melden sich explizit angelegte AD LDS-Konten am Service an.

Mit der Funktion "ADAM bind redirection" oder auch "Proxy Bind" kann sich aber auch ein Anwender am ADAM-Server mit seinem Benutzernamen und Kennwort anmelden. ADAM findet dann den Benutzer und nutzt die übermittelten Anmeldedaten seinerseits, um sich dann beim Quellsystem zu authentifizieren.

Das mag nun auf den ersten Blick suspekt aussehen, denn die Applikation oder der Benutzer könnte sich ja direkt per LDAP auch am DC anmelden. Aber über den Weg können z.B. Programme den AD LDS-Server zur Überprüfung der Anmeldedaten von sehr vielen Benutzern nutzen ohne z.B. viele unterschiedliche Domänen abzuklappern.

So arbeiten gerne mal Druckerlösungen o.ä. mit diesem System. Auch VoIP-Anlagen können Sie z.B. die Authentifizierung zentralisieren. Von Cisco gibt es dazu ein ganz interessantes Dokument:

Für die Nutzung von UserProxy müssen Sie natürlich in ADAMSync noch weitere Felder setzen, z.B.

<doc>
  <configuration>
    <query>
      <attributes>
        <include>objectSID</include> 
      </attributes>
    </query>
    <user-proxy>
      <source-object-class>user</source-object-class>
      <target-object-class>userProxy</target-object-class>
    </user-proxy>
  </configuration>
</doc>

Wenn Sie ein eigenes Provisioning einsetzen, dann muss dieses die passende Classe beim Anlegen der Objekte berücksichtigen. 

ADAMNTDS.DIT sehr groß

Wenn Sie durch ADAMSync immer wieder viele Elemente anlegen und löschen, sollten Sie die Tombstone Lifetime (Default 180 Tage) von ADLDS reduzieren, damit die Datenbank nicht über Gebühr wächst. Denn jedes gelöschte Objekt bleibt so bis zu 180 Tage in der Datenbank. Das ist wichtig, damit bei einer Replikation zwischen mehreren AD LDS-Instanzen auch die anderen Instanzen eine Löschung erkennen. Die Tombstone Lifetime kann daher nicht 0 sein. Microsoft definiert ein Limit von 3 Tagen. Wen Sie mehrere AD LDS-Instanzen als Farm betreiben, sollten Sie einzelne Server nie länger als diese 3 Tage offline nehmen, da sie dann nicht mehr synchron sind und eine Neuinstallation dieser abgehängten Instanz erforderlich ist. Sie kennen das sicher von Active Directory Domain Controller, die über 180 Tage "offline" waren.

Wenn wir aber AD LDS nur als Single Server betreiben oder die Daten dank ADAMSync und dem dort möglichen "Aging" auch wieder schnell aufbauen können, können Sie die Tombstone Lifetime reduzieren. Dies kann auch sinnvoll sein, wenn Sie mit ADAMSync oder anderen Tools sehr oft viele Daten anlegen und löschen. Die Konfiguration ist analog zum großen Active Directory in der Konfigurationspartition:

Well-known-Context: 
“Configuration”
  ->"Services"
      ->"Windows NT"
         ->"Directory Services"
            ->"Properties":tombstoneLifetime"

ADSIEDIT prüft nicht, ob der Wert gültig ist. Sie könnten hier auch eine 0 setzen aber intern ist wohl ein Minimum von 3 Tagen definiert.

Weitere Links

ADAMSYNC is a command-line utility that performs a one-way synchronization of data from Active Directory into ADAM. Adamsync uses an XML-based con-figuration file that drives the parameters of the ongoing synchronization