Adam und Eva

Immer mehr netzwerkfähige Geräte, wie zum Beispiel Scanner oder auch Telefonanlagen, unterstützen das Einlesen der Benutzer per LDAP. Leider kranken diese Geräte oft an der fehlenden Fähigkeit, sich an einem LDAP Server zu authentifizieren oder anderen Dingen. Manchmal steht der Administrator auch vor der Aufgabe, dass beispielsweise eine Telefonanlage von mehreren Firmen genutzt wird und diese per LDAP angebunden werden soll. Welcher Administrator möchte es, dass seine Domänencontroller von einer Telefonanlage dieser Art abgefragt werden? Dadurch hätten ja unter Umständen auch andere Firmen lesenden Zugriff auf das Active Directory Verzeichnis. Genau für diese Art von Einsatzzweck hat Microsoft das Produkt ADAM entwickelt.

ADAM (Active Directory Application Mode) ist eine Art abgespecktes Active Directory, mit dem man genau diese Dinge realisieren kann, ohne dabei sein Netzwerk in Gefahr zu bringen. Microsoft liefert für ADAM auch entsprechende Werkzeuge, damit man auch ohne Programmierkenntnisse zwischen Active Directory und der ADAM Instanz eine Synchronisation durchführen kann. Wie funktioniert aber jetzt das Ganze und was wird als Voraussetzung benötigt? Im einfachsten Fall reicht hier der Einsatz von Windows XP Professional als ADAM Server. Wer möchte, kann auch einen Windows 2003 Server einsetzen. Für diesen Artikel habe ich auf der Active Directory Seite und auf der ADAM Seite einen Windows Server 2003 R2 eingesetzt. Glücklicherweise kann man unter Windows Server 2003 R2 den ADAM Dienst direkt als Windows Komponente installieren.
OK, was muss man tun, um ADAM zu konfigurieren. Als Erstes muss man die Installation über die Windows Komponenten vornehmen.

Nachdem die Installation abgeschlossen ist, findet man unter „Start -> Programme“ den neuen Ordner „ADAM“. Unterhalb des Ordners findet man eine Option „ADAM-Instanz erstellen“. Mit dieser Option wird ADAM letztendlich lauffähig gemacht.

Da in meinem Demonetzwerk noch keine Instanz besteht, muss hier die Option „Eine eindeutige Instanz installieren“ ausgewählt werden. Im nächsten Schritt wird jetzt der Instanzenname abgefragt. Da ich in diesem Artikel als Beispiel ein Telefonbuch installieren will, nenne ich meine Instanz kreativerweise „Telefonbuch FAQ-O-MATIC“.

Im nächsten Schritt fragt der Assistent nach den Portnummern, auf denen die Instanz arbeiten soll. Wenn es sich bei dem Server, auf dem ADAM installiert wird, um einen Domänencontroller handelt, dann schlägt der Assistent automatisch Ports vor, die nicht von Active Directory belegt werden. Mein Demosystem ist ein einfacher Mitgliedsserver, auf dem kein Active Directory installiert ist. Deshalb werden vom Assistenten die Standardports für LDAP (389) und LDAP/SSL (636) vorgeschlagen.

Nachdem die Ports festgelegt wurden, möchte der Assistent eine Anwendungspartition erstellen. Die Anwendungspartition wird zukünftig die Benutzerobjekte aufnehmen, die die Telefonanlage dann über eine LDAP Suche abfragen kann. Ich übergehe diesen Schritt, um später demonstrieren zu können, wie man eine Partition auf der Kommandozeile anlegt.

Bei der nächsten Frage möchte der Assistent wissen, wo er die ADAM Datenbank ablegen soll. Hier sollte man prüfen, ob der Speicherplatz auf dem Systemlaufwerk noch ausreichend ist. In den seltensten Fällen macht sich ein Verschieben der Datenbanken auf eine andere Partition bzw. ein anderes Laufwerk erforderlich.

Im nächsten Schritt möchte der Assistent wissen, unter welchem Benutzerkonto der Dienst laufen soll. Auch hier kann man den Standardvorschlag bestehen lassen. Das Benutzerkonto „Netzwerkdienst“ ist ein eingeschränkter Security Principal, der für diese Aufgabe geeignet ist.

Jetzt muss ein Benutzerkonto angegeben werden, was administrative Rechte über diese Instanz erhält. Der Einfachheit halber lasse ich hier den Domänen-Administrator stehen. Hier könnte man natürlich auch einen anderen „normalen“ Benutzer auswählen.

Damit in einer ADAM Instanz überhaupt Objekte erstellt werden können, benötigt man ein Schema, was diese Objekte beschreibt. Auf der nächsten Seite des Assistenten hat man die Möglichkeit, bestimmte LDF Dateien für die Erweiterung des Schemas zu importieren. Wir benötigen diese Dateien nicht, da wir die Erweiterung später vornehmen.

Nachdem der Assistent noch kurz eine Zusammenfassung der Setup Parameter anzeigt, beginnt er anschließend mit der Installation.
Damit Objekte aus der bestehenden Active Directory Umgebung in die ADAM Instanz repliziert werden können, muss als nächstes das Schema erweitert werden. Im Installationsverzeichnis von ADAM befinden sich dafür zwei LDF-Dateien. Zum Einen ist das die Datei „MS-AdamSchemaW2K3.LDF“ für das Schema eines Windows 2003 Active Directory und zum Anderen die Datei „MS-AdamSyncMetadata.LDF“, die für den Objektabgleich benötigt wird.

Der Import der LDF Dateien wird über das aus Active Directory bekannte Kommandozeilenprogramm „ldifde“ realisiert.
ldifde -i -f MS-AdamSyncMetadata.LDF -s localhost -c "cn=configuration,dc=x" #configurationNamingContext

ldifde -i -f MS-AdamSchemaW2K3.LDF -s localhost -t -c "cn=configuration,dc=x" #configurationNamingContext

Somit ist die ADAM Instanz vorbereitet. Was jetzt noch fehlt, ist die Anwendungspartition, die die Userobjekte anschließend aufnehmen soll. Für diese Aufgabe steht das Programm „dsmgmt.exe“ zur Verfügung. Das Gleiche geht aber auch mit „ntdsutil“.

Jetzt ist ADAM für die erste Synchronisation bereit. Für den Abgleich zwischen Active Directory und ADAM stellt Microsoft das Programm „adamsync“ zur Verfügung. Adamsync benötigt eine XML-Konfigurationsdatei, in der alle wichtigen Parameter festgehalten sind. Im Installationsverzeichnis existiert bereits eine Beispieldatei. Diese muss nur noch auf die eigenen Bedürfnisse angepasst werden.

<?xml version="1.0"?>
<doc> 
 <configuration>  
  <description>FAQ-O-MATIC</description>  
  <security-mode>object</security-mode>        
  <source-ad-name>faq-o-matic.net</source-ad-name>  
  <source-ad-partition>dc=faq-o-matic,dc=net</source-ad-partition>
  <source-ad-account></source-ad-account>               
  <account-domain></account-domain>
  <target-dn>dc=faqomatic</target-dn>  
  <query>   
   <base-dn>dc=faq-o-matic,dc=net</base-dn>
   <object-filter>(&(objectclass=user)(telephoneNumber=*))</object-filter>
   <attributes>    
    <include>givenname</include>
    <include>sn</include>
    <include>telephoneNumber</include>    
    <exclude></exclude>
   </attributes>  
  </query>  
  <schedule>   
   <aging>    
    <frequency>2</frequency>    
    <num-objects>600</num-objects>   
   </aging>   
   <schtasks-cmd></schtasks-cmd>  
  </schedule> 
 </configuration> 
 <synchronizer-state>  
  <dirsync-cookie></dirsync-cookie>  
  <status></status>  
  <authoritative-adam-instance></authoritative-adam-instance>  
  <configuration-file-guid></configuration-file-guid>  
  <last-sync-attempt-time></last-sync-attempt-time>  
  <last-sync-success-time></last-sync-success-time>  
  <last-sync-error-time></last-sync-error-time>  
  <last-sync-error-string></last-sync-error-string>  
  <consecutive-sync-failures></consecutive-sync-failures>  
  <user-credentials></user-credentials>  
  <runs-since-last-object-update></runs-since-last-object-update>  
  <runs-since-last-full-sync></runs-since-last-full-sync> 
 </synchronizer-state>
</doc>

Gehen wir die wichtigsten Elemente der XML Datei einmal durch. Im Element „<description>“ wird nur eine Beschreibung festgelegt. Mit Hilfe dieser Beschreibung kann man durch „adamsync /list localhost“ die installierten Konfigurationen besser identifizieren. Die Elemente „source-ad-name“ und „source-ad-partition“ identifizieren die Quelldomäne. Mit „source-ad-name“ wird der FQDN der Quelldomäne festgelegt und mit „source-ad-partition“ die Active Directory Partition, in der die zu synchronisierenden Objekte gesucht werden. Das Element „<target-dn>“ gibt die Zielpartition an, in der die synchronisierten Objekte erstellt werden sollen. Adamsync ermittelt die zu synchronisierenden Objekte über eine LDAP Suche. Für diese Suche werden zwei Dinge benötigt. Als Erstes muss ein „<base-dn>“ festgelegt werden. Dieser distinguished Name beschreibt den Ausgangspunkt der LDAP Suche. Danach wird der eigentliche Suchfilter festgelegt. Da wir die ADAM Instanz als Telefonbuch nutzen wollen, werden nur Benutzer synchronisiert, die auch eine Telefonnummer besitzen. Dadurch ergibt sich folgender LDAP Filter:

„(&(objectclass=user)(telephoneNumber=*))“

Das kaufmännische „Und“ kann aber nicht in der XML Datei interpretiert werden. Deshalb muss dieses Sonderzeichen in der XML Datei kodiert werden.

„(&(objectclass=user)(telephoneNumber=*))“

Als nächstes kommen wir zu den Attributen, die für unsere Objekte mit repliziert werden sollen. Für ein Telefonbuch muss ja ein Userobjekt nicht mit allen Attributen repliziert werden. Für diesen Anwendungsfall sollte die Angabe von Vorname, Nachname und Telefonnummer ausreichen. Welche Attribute repliziert werden, kann man über das Element „<attributes>“ steuern. Da für den Anwendungsfall „Telefonbuch“ nur drei Attribute repliziert werden müssen, habe ich mich dafür entschieden, diese Attribute über „<include>“ anzugeben. Wenn die Zahl der zu synchronisierenden Attribute überwiegen sollte und man nur einige wenige von der Synchronisation ausschließen will, dann kann man diese über „<exclude>“ ausschließen. Ein weiterer wichtiger Punkt ist das „<aging>“. Darüber kann gesteuert werden, was passieren soll, wenn ein Objekt in der Quelle gelöscht wird. Dazu aber an späterer Stelle mehr.

Nachdem alle Einstellungen in der XML Datei vorgenommen wurden, kann diese jetzt installiert werden. Dafür bietet das Tool „adamsync“ den Schalter „/install“ an.

adamsync /i localhost NAMEDERXMLDATEI.XMLJetzt ist ADAM für die erste Synchronisation bereit.

adamsync /sync localhost dc=faqomatic

Ein Wort zur Performance. In der Active Directory Domäne, die hier als Quelle genutzt wurde, existieren 20.000 Benutzerobjekte. Der erste Synchronisationsvorgang, zwischen Active Directory und ADAM, nahm ca. 2 Minuten und 30 Sekunden in Anspruch. Dabei wurden ca. 68,1 MB an Daten übertragen. Jede weitere Synchronisation wurde innerhalb von 5 Sekunden beendet und es wurden dabei ca. 69 KB übertragen.

Nachdem also die erste Replikation erfolgreich abgelaufen ist, kann man die oben stehende Kommandozeile als geplanten Task einrichten. Dadurch kann ein periodischer Abgleich zwischen Active Directory und ADAM sichergestellt werden. Was passiert aber mit den gelöschten Objekten? Diese bleiben bei der momentanen Konfiguration bestehen. Hier kommt jetzt das Element „<aging>“ der XML Konfigurationsdatei ins Spiel. Über das Unterelement „<frequency>“ kann bestimmt werden, aller wie viel Sychronisationszyklen eine Überprüfung auf gelöschte Objekte vorgenommen wird. Das Unterelement „<num-objects>“ gibt an, wie viele Objekte auf einmal untersucht werden sollen. Wenn wir in unserem Beispiel für „<frequency>“ den Wert „2“ setzen und für „<num-objects>“ den Wert 500, dann bedeutet dies, dass „adamsync“ im schlimmsten Fall 80 Replikationszyklen benötigt, um alle Objekte auf einen eventuellen Löschvorgang zu prüfen. Findet adamsync ein im Active Directory gelöschtes Objekt, dann wird es auch in der Adaminstanz entfernt. Um die Performance hier einmal zu testen, habe ich mit drei verschiedenen Werten in „<num-objects>“ gearbeitet.

Leider gibt es bei der Synchronisation einen unschönen Nebeneffekt. Adamsync scheint bei der Synchronisation der gelöschten Objekte den LDAP Filter „(&(objectclass=user)(telephoneNumber=*))“ zu nutzen. Da bei einem Löschvorgang aber das Attribut „telephoneNumber“ vom Objekt entfernt wird, kann adamsync ein gelöschtes Objekt nicht korrekt erkennen. Das kann dazu führen, dass adamsync alle synchronisierten Objekte verwirft und in den Container „LostAndFound“ der ADAM Partition verschiebt. Dieser Tatsache kann man aber mit einem kleinen Hack entgegenwirken. Dazu muss man im Active Directory Schema der Quelle eine kleine Anpassung im Attribut „telephoneNumber“ vornehmen. Durch das Verändern der Eigenschaft „searchflags“ im Attribut „telephoneNumber“ kann man verhindern, dass dieses Attribut von einem Objekt entfernt wird. Dazu muss die Eigenschaft „searchflags“ des Attributs „telephoneNumber“ auf den dezimalen Wert 8 gesetzt werden. Dieser Wert entspricht binär dem vierten Bit.

Dadurch bleibt beim Löschen eines Objekts dieses Attribut am gelöschten Objekt erhalten und adamsync kann eine erfolgreiche Synchronisation durchführen.

Kommen wir jetzt zum letzten Punkt dieses Artikels. Jetzt muss nur noch sichergestellt werden, dass auch mit einer anonymen Anmeldung auf die Informationen im ADAM lesend zugegriffen werden kann. Um das zu ermöglichen, müssen zwei Schritte durchgeführt werden. Als erstes muss der anonymen Anmeldung erlaubt werden, sich ohne Authentifizierung mit der Telefonbuch Partition zu verbinden. Standardmäßig ist das nicht erlaubt. Um es zu ermöglichen, muss das „dsHeuristics“ Attribut in den Eigenschaften des Directory Services Objekts der Konfigurationspartition auf den Wert „0000002001000“ angepasst werden.

Jetzt kann zumindest schon ein LDAP Bind auf alle Partitionen der ADAM Instanz durchgeführt werden. Dadurch kann aber eine anonyme Anmeldung noch keine Objekte der einzelnen Partitionen lesen. Damit die einzelnen Partitionen auch durchsucht werden können, fügt man im einfachsten Fall das Konto „Anonymous-Anmeldung“ in die ADAM Rolle „Readers“ der entsprechenden Partition hinzu.

Jetzt können die Userobjekte in der ADAM Partition auch ohne Authentifizierung gelesen werden. Damit wäre es jetzt möglich, diese ADAM Instanz für das Erstellen eines Telefonbuchs zu nutzen.