SelfADSI - The LDAP / ADSI Scripting Tutorial ADS Databse: Structure, Access and Tools

Thus section of the SelfADSI Tutorial describes the technical design of the ADS databse and its access. Following topics are available:

	Structure of the ADS database: Partitions / Naming Contexts
	LDAP Access to ADS
	Graphic Tools for ADS Access : ADSIEdit and LDP
	Commands for ADS Access: LDIFDE, CSVDE and DS Commands
	Technique, Files and Memory of the ADS database
	Database Maintenance

Structure of the ADS Database: Partitions / Naming Contexts

The Active Directory Database is normally divided into several section. As a basic principle, these sections are called Partitions or Naming Contextes or Name Contextes too. The domain controller are so to speak those server on which single entities of these partitions are saved.

There are three different types of standard partitions:

	Schema Partition
	The design of the ADS database is determined in the schema, i.e. definitions of object classes (e.g. user, contact, group etc.) and their attributes (e.g. displayName, streetAddress, mailNickName etc.). These definitions can be customized for additional tasks: The so-called schema add-on. The schema partition has to be identical on the whole forest. It is passed out by the ADS synchronisation to all DCs of the forest.   The LDAP pathname of the schema partition in an Active Directory is always:   cn=Schema,cn=Configuration,dc=<Root domain(s) of the forest>,dc=<Toplevel domain of the root>
	Configuration Partition
	This part of the database contains important information about the structure of the ADS forest itself. E.g. ADS sites and their site links are determined here. Other systems, like e.g. Exchange or PKI store information about their configuration here, too. The configuration partition is given to all DCs of the whole forests.   The LDAP pathname of the schema partition in an Active Directory is always:   cn=Configuration,dc=<Root domain of the forest>,dc=<Toplevel domain of the Root>
	Domain Name Context
	The 'normal' objects of a domain are stored here, e.g: User, contacts, groups, printer objects, organisational units et. There is a separate domain name context for each domain in the forest, at which every DC stores only the domain name context of its own domain (the only exception is the Global Catalog Server (GC)).

Additionally, there are freely definable ADAM (Active Directory Application Mode) partitions beginning with Windows 2003 . Diese Datenbank-Teile werden von Windows und Active Directory selbst nicht verwendet, können aber von der bewährten Speichertechnik und Multimaster-Replikation auf Domänen-Controllern profitieren. Wenn man also Daten dezentral und repliziert auf DCs speichern will, die durch das LDAP-Protokoll zugegriffen werden sollen, dann kann man beliebig zusätzliche Partitionen erzeugen.

Der Clou dabei: Man kann frei bestimmen, welche Domänen-Controller im Forest die einzelnen ADAM-Partitionen speichern und einander replizieren. So kann man die Daten genau dort wo man sie braucht zur Verfügung stellen - und dabei die Infrastruktur der ADS-Replikation ausnutzen.

< nach oben

LDAP Zugriff auf ADS

Sowohl der lokale als auch der Netzwerk-Zugriff auf die ADS läuft über das LDAP-Protokoll (LightWeight Directory Access Protocol) ab. Hierfür stellt auf einem ADS Domänencontorller der lokale LSASS-Prozess einen LDAP-Server zur Verfügung. Dieser unterstützt die LDAP-Version v3 nach RFC 2251.

Das LSASS (Local Security Authority SubSystem) liefert auch andere wichtige Funktionalitäten für das Active Directory, unter anderem Kerberos. Dem Thema LDAP ist im SelfADSI Tutorial ein eigener Abschnitt gewidmet.

< nach oben

Grafik-Tools für den ADS-Zugriff

Es stehen verschiedene Tools zum Zugriff auf die ADS-Datenbank zur Verfügung, auf grafischer Ebene wären da vor allem die in den Windows Support Tools enthaltenen Programme ADSIEdit und LDP. Beide Tools sind in den Windows Support Tools enthalten. ADSI-Edit bietet die bequemere Oberfläche, wohingegen LDP einen direkten Einblick in die LDAP-Kommunikation erlaubt und außerdem für beliebige LDAP-Verzeichnisse eingesetzt werden kann.

Neben ADSIEdit und LDP wären noch Tools von anderen Herstellern zu nennen:

Softerra LDAP Administrator

LDAPAdmin (OpenSource)

LDAP Browser / Editor (OpenSource)

< nach oben

ADSIEdit

ADSI-Edit ist ein MMC-SnapIn Tool aus den Windows Support Tools (kostenloser Zusatz auf der Windows Server CDROM im Verzeichnis \Support\Tools). ADSIEdit ist speziell für den Zugriff auf ADS-Verzeichnisse konzipiert. Um das Tool aufzurufen, müssen Sie nach der Installation der Support Tools die Microsoft Management Console (MMC.EXE) aufrufen und dann ADSIEdit aus der Liste der verfügbaren Snap-Ins laden.

Öffnen Sie hier zunächst das Kontextmenü des ADSI Edit-Tools und wählen Sie die Option "Connect to...". Dann kann man im Punkt "Select a well known Naming Context" die Domänen-, Configuration oder Schema-Partition auswählen:

Außer den drei ADS-Partitionen können Sie natürlich auch ADAM-Partitionen öffnen oder den RootDSE-Eintrag auslesen. Im Menü "Advanced" könnten Sie noch spezielle Anmeldedaten übergeben oder auswählen, an welchem LDAP-Port Sie sich verbinden. Wahlweise ist auch ein Connect zum Global Catalog möglich. Später haben Sie alle Objekte und deren Attribute (über das Kontextmenü -> Eigenschaften oder mit einem Klick auf Alt-Enter) bequem im Zugriff:

< nach oben

LDP

LDP ist ein LDAP-Browser Tool aus den Windows Support Tools (kostenloser Zusatz auf der Windows Server CDROM im Verzeichnis \Support\Tools). Mit LDP können Sie auf beliebige LDAP-Verzeichnisse zugreifen. Um das Tool aufzurufen, müssen Sie nach der Installation der Support Tools das Programm LDP.EXE direkt aufrufen.

Zuerst muss man sich hier mit einem LDAP-Server verbinden. Dazu verwenden Sie die Option "Connection -> Connect....". Hier kann man außerdem noch einen speziellen LDAP-Port angeben (z.B. 3268 für den Global Catalog) und die Art der Verbindung angeben. Die Standardwerte ermöglichen in den meisten Fällen eine problemlose Verbindung zu einem ADS DOmänen-Controller.

Beim Aufbau der Connection wird übrigens der Inhalt des RootDSE-Objektes im Datenfenster auf der rechten Seite ausgegeben. Nach dem Connect muss sich ein LDAP-Client authentifizieren, dieser Vorgang wird auch Bind genannt und geschieht unter dem Menüpunt "Connect -> Bind...". Falls es sich um einen Nicht-ADS-Domänencontroller handelt, dann sollte man die Option "Domain" deaktivieren.

Hier sollte bei einer fehlerfreien Anmeldung die Ausgabe "Authenticated as" im Datenfenster erscheinen. Nun sollte noch die Suchbasis (der SearchDN) für die anzuzeigenden Objekte festgelegt werden, und zwar unter "View->Tree". Hier muss dann der LDAP-Pfadname der jeweiligen Partition eingetragen werden. Die Pfadnamen sind weiter oben erklärt.

Danach sehen Sie die hierarchische Struktur der gewählten Partition im linken Fenster. Sie können hier auf alle Objekte und deren Attribute (sichtbar im rechten Fenster) zugreifen. Eventuell auftretende Fehler im LDAP-Protokoll werden im rechten Fenster direkt ausgegeben.

< nach oben

Kommandos für den ADS-Zugriff - LDIFDE

LDIFDE ist die Abkürzung für LDIF Directory Exchange. Mit diesem Kommando lassen sich Objekte und Ihre Eigenschaften in eine ASCII-Datei exportieren. Diese Datei ist nach dem übergreifenden format LDIF (LDAP Data Interchange Format) aufgebaut. Dieses Format wird in RFC 2849 festgelegt. Hier werden die Objekte durch Leerzeilen getrennt aufgeführt, die Attribute der Objekte werden jeweils in einer eigenen Zeile aufgeführt in der Form "<AttributName>:<Wert>". Ein Beispiel:

Nach genau diesem Format kann man auch Objekte im ADS neu erzeugen. Hierzu muss dann noch das Meta-Attribut "changetype" in der LDIF-Import-Datei verwendet werden, z.B. so:

Kommandos für den ADS-Zugriff - CSVDE

Die Verwendung und die Parameter sind hier prinzipiell die gleichen wie bei LDIFDE, nur wird für die Im- und Export-Dateien das CSV-Format verwendet: Jedes Objekt wird in eine einzige Zeile geschrieben, die einzelnen Attribute werden durch Semikolon getrennt.

Kommandos für den ADS-Zugriff - Die DS-Kommandos

DSADD

Fügt neue Verzeichnis-Objekte hinzu. Dabei ist man jedoch auf die Standard-Objektklassen "user", "contact", "group", "computer", "quota" beschränkt.

DSMOVE

Verschiebt Objekte innerhalb des Verzeichnisses. Wird auch zur Umbennen von Objekten verwendet. Das Tool beherrscht jedoch nur die oben genannten Objektklassen.

DSMOD

Modifiziert Attribute von Verzeichnis-Objekten. Das Tool beherrscht jedoch nur die oben genannten Objekt-Klassen.

DSGET

Liest Attribute von Verzeichnisobjekten aus und zeigt diese an. Das Tool beherrscht jedoch nur die oben genannten Objekt-Klassen und auch hier nur einen begrenzten Satz an Standard-Attributen.

DSRM

Löscht Verzeichnis-Objekte.

DSQUERY

Fragt das Verzeichnis nach diversen Objekt-Typen ab. Ausgegeben werden nur Objekte, keine Attribute. Interessant: Es werden LDAP Distinguished Names zurückgegeben. Über Pipe-Umleitungen können diese sofort von den anderen DS-Befehlen weiterverwendet werden. Beispiel:

Dies löscht alle Computer-Konten, die mehr als vier Wochen nicht aktiv waren.

< nach oben

Technik, Dateien und Speicherort der ADS-Datenbank

Die ADS-Datenbank wird auf einem Windows Domänen-Controller im Format der Extensible Storage Engine (ESE) gespeichert. Dieses Format wird z.B. auch für die Mail-Datenbanken von Exchange-Servern verwendet. Neben der eigentlichen Datenbank spielen auch Dateien für das Transaktionsprotokoll eine Rolle. Mit diesem soll ein konsistenter Zustand der Datenbank auch bei Systemausfällen sichergestellt werden.

Der Standard-Speicherpfad der Datenbank ist %SYSTEMROOT%\NTDS. In diesem Verzeichnis befinden sich neben mehreren Transaktions-Protokolldateien auch die eigentliche Datenbank-Datei: NTDS.DIT. "DIT" ist hierbei die Abkürzung für Directory Information Tree.

< nach oben

Datenbank Maintenance

Zur Pflege der ADS-Datenbank gehören Aufgaben wie das Verschieben der DB-Dateien oder die Offline-Komprimierung. Dies geschieht mit dem Kommando NTDSUtil.

< nach oben

zurück zu SelfADSI Startseite