AD LDS Installation

Diese Seite beschreibt die Installation der AD LDS Rolle und der ersten Instanz.

Feature addieren

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".

Instanz installieren

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.

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