AD LDS-Server

ADAM steht für "Active Directory Application Mode" und ist quasi ein LDAP-Server für eigene Zwecke. ADAM kann auf einem Windows Server 2003 aber sogar Windows XP installiert werden und wird hauptsächlich von Anwendungen genutzt, die per LDAP Daten abfragen und ablegen wollen, aber dies nicht im produktiven Active Directory tun wollen.

ADAM ist lizenztechnisch Bestandteil der Windows 2003 R2-Editiion oder höher
Es ist kein eigenständig erwerbbares Produkt. Es kann von Microsofts Webseite heruntergeladen und auf Windows XP und Windows 2003 Server installiert werden.

Hinweis: Auf jedem Exchange Edge Server wird ein AD-LDS-Service zur Speicherung der Konfiguration genutzt.

Eckwerte

 Hier ein paar Erfahrungswerte zu ADAM:

  • ADAM ist klein
    Der Start einer Instanz benötigt gerade mal 12 Megabyte Hauptspeicher. Natürlich nutzt ADAM nach einiger Zeit mehr Speicher, besonders wenn die Datenbank größer ist und ADAM den Speicher zum Cachen verwendet.
  • Transaktionsorientiert
    Die Datenbank ist mit dem Active Directory und Exchange vergleichbar.
  • Einfaches Backup
    Wenn Sie heute schon mit NTBackup oder einer anderen Software mit VSS-Support sichern, dann ist damit auch die ADAM-Datenbank gesichert. ADAM registriert einen VSS-Provider und schließt die Datenbank bei NTBackup aus
  • Kleine schnelle Datenbank
    Ich habe zum Test einmal 20.000 Benutzer mit Adressen und Rufnummern generiert und importiert. Die Datenbank wurde dabei gerade mal um 30 Megabyte größer und es wurden 6-10 Objekte pro Sekunde angelegt. Hört sich wenig an, aber ist schon ganz stattlich für eine virtuelle Maschine auf einer Notebook-Festplatte und VBScript.
  • Schema und Index
    Sie können das "Schema" des LDAP-Servers ändern und damit eigene Felder und Objekte definieren. Es müssen nicht immer nur Benutzer und Kontakte sein. Weiterhin können Sie die Attribute selbst erstellen und diese indexieren. Eine Suche einer Telefonnummer in 20.000 Datensätzen dauert weit unter einer Sekunde.
  • Replikation
    Aus Aspekten der Lastverteilung und Hochverfügbarkeit können Sie sogar mehrere ADAM-Instanzen auf verschiedenen Servern Installieren, die sich dann genau wie das Active Directory in einer Multi-Master-Replikation abgleichen. Sogar über Kontinente hinweg. Auch in ADAM sollte man dazu aber Standorte und Sitelinks etc. pflegen
  • Berechtigung
    ADAM können Sie nicht als Ersatz für eine Windows Domäne nutzen. Zwar kann man auch hier Benutzer und Computer anlegen, aber es fehlen z.B.: Dienste wie Kerberos Schlüsselserver etc. ADAM ist "nur" ein LDAP-Verzeichnis. Aber ADAM kann natürlich die bestehenden Konten aus einem Active Directory zur Authentifizierung nutzen. Sie können demnach in ADAM auf OUs oder Objekte Berechtigungen vergeben und dabei Active Directory Konten nutzen. Dies erspart gesonderte Benutzer und Kennworte für den Zugriff.
  • Multiinstanzfähig
    Auf einem Server können mehrere ADAM-Instanzen nebeneinander unabhängig laufen. Jede nutzt ihre eigene Datenbank und ihre eigenen Ports. Sie können sogar eine Instanz auf dem gleichen System auf eine zweite Instanz replizieren lassen.

Damit ist ADAM einfach ein kompakter LDAP-Server, der für bestimmte Einsatzbereiche sehr viel besser geeignet ist, als z.B. ein SQL-Server. Natürlich könnte eine Anwendung ihre Daten auch einem SQL-Server oder der SQL-Express-Version (Siehe SQL-Server) ablegen aber oftmals ist der Zugriff per LDAP einfacher und universeller und gerade die Möglichkeit einer Replikation auf mehrere Server ist ein großer Vorteil des Active Directory und von ADAM. ADAM nutzt LDAP statt SQL und erlaubt eine Hierarchie der Objekte und nicht die SQL-typischen Tabellen. Überlegen Sie daher einfach mal, welche Informationen Sie speichern wollen. Vielleicht ist ADAM der ideale Platz dafür. ADAM ist aber kein Active Directory und bietet nur eine Teilmenge der Funktionen an.

ADAM ist kein Kerberos-Server, stellt keine NSPI/MAPI-Schnittstelle für Exchange bereit, kenn keine Gruppenrichtlinien, trägt keine DNS-SRV-Records ein und ist vor allem kein Global Catalog. Aber ansonsten kenn es durchaus AD-typische Replikation mit Standorten und Diensten für Hochverfügbarkeit und geografische Verteilung und ist ein ganz potenter LDAP-Server.

Es gibt natürlich auch andere LDAP-Server wie z.B.

AD LDS Installation

Mittlerweile können Sie die AD LDS-Funktion einfach über die "Features" von Windows nachinstallieren.

Das gibt es nicht nur bei Windows Servern sondern sogar für Windows Desktop Systeme. Da ist es dann auch ein Windows Feature.

Natürlich geht das auch per PowerShell.

Install-WindowsFeature -Name ADLDS -IncludeManagementTools

Damit wird aber nur das Feature "bereitgestellt". Die eigentliche Konfiguration ist dann ein zweiter Schritt:

Der Assistenz steuert dann die eigentliche Installation. Sie können die Installation natürlich auch mit einem "Antwortfile" automatisieren, wenn Sie sehr viele AD LDS-Server bereitstellen wollten

%SystemRoot%\ADAM\adaminstall.exe /answer:C:\temp\adldssetup.txt

Die Datei könnte dann einfach eine TXT-Datei mit folgendem Inhalt sein:

[ADAMInstall]
InstallType=Unique
InstanceName=AD-LDS-Test
NewApplicationPartitionToCreate="DC=test,DC=net"
DataFilesPath=C:\Program Files\Microsoft ADAM\TestInstanz\data
LogFilesPath=C:\Program Files\Microsoft ADAM\TestInstanz\data
ImportLDIFFiles="ms-user.ldf"

Über den Assistenten werden Sie die Daten dann interaktiv abgefragt:

Wussten Sie, dass sie mit dem "Problem Step Recorder" (psr.exe) sehr einfach die Installation protokollieren können?

Schritt  Beschreibung

Willkommen

Jeder Assistenz startet mit einer Willkommensseite.

Option Neue Instanz oder Replika

So wie sie mehrere Domain Controller für eine Domain bereitstellen können (und sollten) können Sie auch mehrere AD LDS-Server als Verbund betreiben. Bei der ersten Installation müssen sie natürlich eine neue Instanz anlegen, denn es gibt ja noch keine vorhandene Instanz, von der Sie die Daten beziehen können.

Beim addieren einer Replika werden Sie später natürlich nach einem Quell-Server gefragt, von dem die Daten dann initial repliziert werden. Das ist soweit zum AD identisch.

Name der Instanz

Im nächsten Schritt geben Sie dem Server einen Namen. Sie können durchaus mehrere AD LDS-Server auf dem gleichen physikalischen Server installieren. Ich belasse es hier bei den Standardwerten.

Der Name der Instanz ist zugleich der Name, unter dem der Dienst im Betriebssystem angelegt wird.

Kommunikationsport für LDAP /LDAPS

Bei der Auswahl der Ports müssen Sie umsichtig sein. Wenn AD LDS mit auf einem Domain Controller installiert wird oder der Server später doch mal ein DC werden soll, dann dürfen Sie natürlich nicht die dann verwendeten Port 389(LDAP) oder 636 (LDAPS) nutzen.

AD LDS schlägt daher 50000 und 50001 vor. Da LDAP über TCP arbeitet, besteht so auch kein Konflikt mit Teams RTP-Ports aber sie sollten prüfen ob ihre Clients, die den AD LDS-Server ansprechen auch von 389 abweichende Ports nutzen können.

Insofern kann es ratsam sein, AD LDS auf einem Mitgliedsserver ohne AD-Funktion zu installiere, damit Sie Port 389/636 ohne Risiko verwenden können. AD LDS stellt allerdings keinen "Global Catalog" bereit, d.h. Port 3268/3268 werden von AD LDS nicht angeboten.

Das für LDAPS erforderliche Zertifikat müssen Sie natürlich auch noch separat einrichten.

Application Partition

Optional kann ich eine weitere Partition für Anwendungen anlegen lassen. Ein Active Directory hat ja auch mindestens drei Partitionen (Schema, Configuration, Domain), um die verschiedenen Daten zu trennen. Der AD LDS-Server hat nur eine Partition, in der sowohl die Configuration als auch das Schema abgelegt sind.

Um den AD LDS mit einer Applikation zu nutzen, sollten Sie eine eigene Application-Partition anlegen. Das geht hier aber auch noch später. Oft legt die Installationsroutine einer 3rd-Party-Software die Partition an.

Dateiablage

Den Platz für die AD LDS-Datenbank kann ich frei wählen. SQL-Server, Exchange Server und viele andere Dienste legen ihre Daten auch im Programm-Verzeichnis an, was ich eigentlich unschön finde. Normalerweise würde ich Daten und Code immer trennen. Aber auch das Active Directory speichert seine NTDS.DIT-Datenbank sogar im Windows-Verzeichnis.

Den Default würde ich aber ändern, wenn Sie eine sehr große Datenmenge erwarten oder viele Änderungen mit damit verbundenen  IOPS mit der Systempartition ein Problem geben könnten.

Service Account

Der AD LDS Service muss sich natürlich authentifizieren. Die Standardeinstellung nutzt den recht sicher konfigurierten "Network Service", der auf jeden Fall weniger Rechte als "Local User" oder "Local System" hat.

Sie können natürlich auch ein eigenständiges Dienstkonto konfigurieren. Das kann meines Wissens nach leider kein "Managed Service Account" sein.

Admin-Account

Bei der Installation wird der initiale Administrator angelegt. In meinem Labor installiere ich den AD LDS auf einem Domain Controller und da ist der Domain Admin natürlich die einfache Lösung und zugleich der Standard.

Im kommerziellen Umfeld würde ich eine Sicherheitsgruppe mit einem passenden Namen anlegen, in der dann die Administratoren aufgenommen werden.

Damit muss man dann nicht immer "Administrator" sein und auch ein einzelnes anderen Benutzerkonto ist ungeschickt, wenn diese doch mal gelöscht wird. Da ist eine Gruppe flexibler und das gleiche Modell nutzen auch andere Produkte wie Exchange, Skype for Business etc.

Schema-Erweiterungen

Die Grundinstallation des AD LDS enthält wirklich nur die minimal notwendigen Schema-Definitionen zu Domains, OUs und wenigen Objekten. Daher ist es ratsam, schon beim der Installation eine Auswahl der angebotenen Schema-Erweiterungen zu installieren. Wer z.B. nicht nur Benutzer anlegen sondern auch weitere Properties füllen möchte, muss dies AD LDS auch mitteilen.

Diese Erweiterung ist aber nur der Anfang. Sie werden später vielleicht noch das Schema der Quelle auslesen und ggfls. nachträglich auch noch in AD LDS importieren. Wer z.B. die msRTC*-Felder von Skype for Business mit der Rufnummer für ein Routing per Session Border Controller braucht, muss später auch noch Erweiterungen vornehmen.

Ich importiere zumindest immer noch MS-User.LDF und wenn Sie eine Authentication per "ProxyAuth" brauchen, auch die nächsten beiden Klassen "MS-UserProxy.LDF" und "MS-UserProxyFull.LDF"

Hinweis: Wenn Sie mit ADAMSync arbeiten, dann sollten Sie auch die "MS-AdamSyncMetadata.ldf importieren.

Zusammenfassung

Am Ende zeigt der Assistenz noch mal einen Dialog mit allen gewählten Einstellungen.

Tipp:
Es tut nicht weh, den Text im Fenster mit der Maus zu markieren und mit CTRL-C in die Zwischenablage zu kopieren und dann in eine Dokumentation zu übernehmen.

Erreichbarkeit testen

Nach der Installation sollte der Dienst schon laufen und der AD LDS-Service erreichbar sein. Ein einfaches Tool liefert Microsoft mit LDP.EXE direkt mit. Ich kann mich damit per LDAP auf den konfigurierten Port verbinden und der LDAP-Server sollte eine Basisinformation liefern.

Hier sehe ich auch, dass der AD LDS-Server genau eine Partition "CN=Configuration,CN={138759E7-4933-4FB2-B3BB-70E3BE6BD024};" hat. Sie sehen aber auch schon Dinge wie "Schema" und "NTDS-Settings".

Der AD LDS Server läuft aber schon mal aber noch können wie nicht viel damit anfangen.

Danach finden Sie einen Windows Dienst auf ihrem Computer und unter "Programme" tauchen die Instanzen auf.

Über den Weg können Sie die Instanz aber nicht entfernen. Das geht per Kommandozeile über das Programm "adamuninstall.exe" im Verzeichnis "C:\Windows\ADAM". Sie starten es einfach mit dem Namen der zu deinstallierenden Instanz mit dem Parameetr "i"

C:\Windows\ADAM\adamuninstallexe /i:instandname

Die Instanz muss dazu laufen und erreichbar sein, denn die Deinstallation prüft, ob es z.B. weitere Replikate gibt. Es ist etwas wie ein kleines DCPROMO

Konfiguration und Verwaltung

Ehe ich z.B. mit ADAMSync oder anderen Prozessen den AD LDS mit Daten fülle, sollte ich einige Vorarbeiten durchführen. Dazu gibt es unterschiedliche Werkzeuge wie ADSIEDT aber auch die PowerShell und DSMGMT.EXE. Oft gibt es mehrere Wege eine Aktion auszuführen, die ich aber nicht alle parallel beschreibe.

Aktion Beschreibung Erledigt

ADSIEDIT und Administratoren

Zuerst verbinde ich mit mittels ADSIEDIT auf den Server. Hier "Localhost:5000" und die Configuration-Partition.

Ein erster Blick zeigt schon die Ähnlichkeit mit dem Active Directory. Neu sind aber die "Roles" mit den vier vorbereiteten Gruppen. ADLDS hat ja keine "Domain-Partition" und daher auch keine Sicherheitsgruppen wie "Domain Administratoren" oder "Enterprise Administratoren".

Sie sehen aber hier auch den "Administrator", der beim Setup schon angelegt wurde. Hier können Sie nun weitere Administratoren anlegen. Die Gruppe der "Reader" und "Users" ist per Default nicht gefüllt.

Config NC

Für fast alle Änderungen braucht man den Configuration Naming Context und der beginnt zwar mit "cn=configuation" aber endet mit einer pro Installation unterschiedlichen GUID. Daher hole ich mir erst einmal den NC in eine Variable.

$ConfigNC= (Get-ADRootDSE -Server localhost:50000).configurationnamingcontext

Forest Mode

Selbst eine Installation der ADLDS auf Windows 2019 stellt den Forest functional Mode auf Windows 2003. Damit gehen natürlich einige schöne Funktionen wie z.B. der Papierkorb nicht. Daher setze ich den Mode zumindest auf Windows 2008R2

#Forestmode anpassen
Set-ADObject `
   -Identity "CN=Partitions,$($ConfigNC)" `
   -Replace @{"msDS-Behavior-Version"=4} `
   -Server localhost:50000

Papierkorb

Schon beim Active Directory habe ich den Papierkorb das ein oder andere Mal gebraucht und wenn ihr AD LDS nicht nur ein DirSync-Ziel ist, in dem Sie die Daten einfach wieder importieren können, dann rate ich dazu, den Papierkorb zu aktivieren. Das geht per PowerShell sehr einfach

# RecycleBin für AD LDS aktivieren
Enable-ADOptionalFeature `
   -Identity 'Recycle Bin Feature' `
   -Scope ForestOrConfigurationSet `
   -Target $ConfigNC `
   -Server localhost:50000

Application Partition

Ich habe beim Setup absichtlich keine Application Partition angelegt um sie dann hier zu konfigurieren. Microsoft beschreibt das einmal als "Source Code", aber das geht auch per LDP. Über die Funktion "Add Child" gebe ich einen freien DN ab und fülle die beiden Attribute:

ObjectClass: domainDNS
instanceType 5

Ein "Run" legt dann die Partition an.

Achtung: Nach dem "Run" wird das Fenster nicht geschlossen. Der Erfolg oder Misserfolg ist hinten im LDP-Fenster sichtbar.

Die Neue Partition können Sie unter Angabe des DN z.B. mit ADSIEDIT o.ä. binden. Es gibt hier aber nicht viel zu sehen:

Es gibt nur die drei vordefinierten OUs "LostAndFound", "NTDS Quotas" und "Roles"

TLS/SSL

 Beachten Sie zur Einrichtung von LDAPS bitte die eigene Seite AD LDS Zertifikate für LDAPS

Backup

Ich muss zugeben, dass aktuell keine meiner AD LDS-Instanzen bei Kunden aktiv gesichert werden. Natürlich werden die Server per VSS oder Snapshot gesichert und wenn der VSS-Provider einen guten Job macht, ist auch der AD LDS-Service mit gesichert. Aber bislang sind die AD LDS-Services immer nur Kopien von echten Daten, die für 3rd-Party-Programme aufbereitet und vorgehalten werden. Es ist in der Regel einfacher den AD LDS einfach noch mal zu installieren und die Daten wieder zu importieren.

Allerdings können natürlich auch mit DSDBUTIL ein Backup starten:

Das Zielverzeichnis muss leer sein.

$InstanceName = "Instance1"
$BackupRoot = "C:\backup\adlds-instance1\"
dsdbutil "Activate Instance $InstanceName" ifm "Create Full $BackupRoot\$InstanceName" quit quit

Simple Bind

AD LDS erlaubt nur sichere Anmeldungen, NTLM und Kerberos gehören dazu aber eine Übertragung von Benutzername/Kennwort über eine unverschlüsselte Verbindung per "Simple Bind" ist per Default nicht aktiviert.

Ich würde dies auch nicht aktivieren aber für eine Fehlersuche und Analyse kann es temporär sinnvoll sein, den unverschlüsselten Zugriff per Simple Bind zu erlauben, dass Sie z.B. per Wireshark zuschauen können, welche LDAP-Anfragen ein Client sendet.

Editieren Sie dazu per ADSIEDIT den folgenden Wert im ADAM.

LDAP_Pfad: CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,CN={GUID}
Attribute: msDS-Other-Settings
Value Ensure RequireSecureSimpleBind = 0

 

Damit sollte sich auch eine Anmeldung mit Simple Bind ohne SSL erreichen lassen. Allerdings benötigen Sie natürlich immer noch einen "berechtigen Benutzer". Das kann ein Domain User sein, ein Benutzer auf dem ADAM-Computer oder auch ein Security Principal innerhalb der ADAM-Datenbank.

Eventlog

Als letzten Punkt nach Installation und Backup sollten Sie wissen, dass AD LDS auch ein eigenes Eventlog anlegt. Hier können Sie schauen, ob es jetzt schon Fehler gibt und für den Regelbetrieb sollten Sie vielleicht eine Überwachung implementieren.

 

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