Inhaltsverzeichnis > LDAP Verzeichnisobjekte umbenennen

LDAP Verzeichnisobjekte umbenennen

Dieser Abschnitt des SelfADSI Tutorials beschäftigt sich mit dem Umbennen von Objekten in LDAP-Verzeichnissen. Folgende Themen stehen zur Verfügung:

Umbennen von Objekten mit MoveHere

Verzeichnisobjekte werden durch Distinguished Names benannt. Durch diese Namen wird sowohl der Speicherort des Objektes in der Verzeichnishierarchie als auch der eigentliche Objektnamen bestimmt. Der Objektname ist dabei ähnlich einem Dateinamen einer Datei in einem Filesystem (im Vergleich zum kompletten Dateipfad) und wird auch Relative Distinguished Name (RDN) genannt.

Mit der Umbenenung eines Objektes ändert sich also der RDN und damit auch der DN. Dies ist der Grund, weshalb diese Aktion in einem ADSI Script etwas seltsam ausieht: Man "verschiebt" das Objekt in seinen eigenen Container (es wird also gar nicht wirklich verchoben). Bei dieser Verschiebe-Aktion kann der Objektnamen neu gesetzt werden. Dies geschieht über die ADSI-Funktion MoveHere:

ADSI Reference on the MSDN: MoveHere()

MoveHere ist eine Methode für Container-Objekte. Das bedeutet: Man muss zuerst eine Verbindung mit der OU herstellen, in der sich das Objekt befindet, das an umbenennen will.

Ein Beispiel: Wir wollen das User-Objekt "Philipp" in der OU "ou=Developper,dc=cerrotorre,dc=de" umbennen in "PhilippFoeckeler". Dazu verbinden wir uns mit einem LDAP Bind-Vorgang zu der betreffenden OU und führen dort die Funktion MoveHere aus:

Download Script

Oder etwas allgemeiner:

Download Script

Wie sie sehen, unterscheiden sich die beiden Parameter von MoveHere. Während der erste (alte) Objektnamen in unserem Beispiel mit

LDAP://cn=Philipp,ou=Developer,dc=cerrotorre,dc=de

als kompletter LDAP Pfadnamen angegeben wurde, muß der zweite Parameter als Relative Distinguished Name so lauten:

cn=PhilippFoeckeler

Man könnte nun eine allgemeinere Umbennenungs-Funktion für eigene Scripts codieren. Dabei suchen wir aus dem kompleten DN des alten Namens automatisch den DN des entsprechenden Containers heraus. Dieser beginnt nach dem ersten Komma (Vorsicht, Kommata innerhalb des RDNs müssen vorher ausgeblendet werden, diese sind standardmäßig mit "\," markiert - Siehe Erläuterungen zu LDAP Pfadnamen). Der benötigte neue RDN des umbenannten Objektes kann dann ebenfalls automatisch erstellt werden:

Download Script

Verweise auf umbenannte Objekte

Die Umbennenung von Objekten birgt ein prinzipielles Problem: Falls der Distinguished Name eines umbenannten Objektes als Attribut eines anderen Objektes gespeichert ist, was passiert dann mit diesem Attribut nach der Umbenennung?

Ein häufiges Beispiel für solche Referenzen auf andere Objekte ist die Definition von Gruppenmitgliedschaften. Aber auch weitere Objektattribute kommen in Frage, wenn in Ihnen Distinguished Names von anderen Objekten gespeichert werden. Und so gehen einzelne Verzeichnissysteme mit diesem Problem um:

	Active Directory: Verweise auf andere Objekte werden bei deren Umbenennung automatisch vom Server angepasst. Dies gilt für alle Attribute mit DN-Inhalt. Ein spezieller Fall: In Universal Groups können sogar Verweise auf Objekte in anderen Domänen vorkommen. Dies ist noch komplizierter, weil es sich um Objekte außerhalb der eigenen Domänen-Datenbank des Servers handelt. Hier sorgt der Domänen-Controller mit der FSMO Rolle "Infrastructure Master" für die automatische Anpassung cer Verweise.
	OpenLDAP: Bei Umbennenungen von Objekten kann OpenLDAP die Verweise in anderen Attributen anpassen, benötigt dafür jedoch eine Erweiterung (ein sogenanntes Overlay): Aktivieren Sie zu diesem Zweck das Overlay RefInt (Referential Integrity, slapo-refint) auf dem OpenLDAP Server.
	Novell eDirectory: Verweise auf andere Objekte werden bei deren Umbenennung automatisch vom Server angepasst. Dies gilt für alle Attribute mit DN-Inhalt.
	Sun iPlanet / Sun Java System Directory Server: Bei Umbennenungen von Objekten kann ein Sun Directory Server die Verweise in anderen Attributen anpassen, benötigt dafür jedoch die Aktivierung eines Plug-Ins: Referential Integrity dsconf set-server-prop -h <server> -p <port>  ref-integrity-enabled:on Danach muß allerdings der komplette Server-Daemon neu gestartet werden, außerdem müssen noch einzeln diejenigen Attribute hinzugefügt werden, die unter die Überwachung der Referential Integrity fallen: dsconf set-server-prop -h <server> -p <port>  ref-integrity-attr:member dsconf set-server-prop -h <server> -p <port>  ref-integrity-attr+:<attribute-name>
	Microsoft Exchange 5.5: Ein Exchange Server kann derartige Querverweise bei Namensänderung nicht verarbeiten und unterdrückt deswegen alle Versuche, ein Objekt umzubenennen. Ein ADSI-Script wird hier stets den Fehler 0x8007054b (LDAP_DOMAIN_DOESNT_EXIST) bringen.

Umbennen von Containern

Bei der Umbenennung von LDAP Containern (z.B. Organizational Units) geht man genauso wie bei einzelnen Objekten vor, allerdings steckt auch hier für die interne Verarbeitung des Verzeichnis Servers ein größerer Aufwand dahinter als man vermutet. Wenn ein Container nämlich andere Objekte enthält, so müssen bei der Umbennung alle Distinguished Names dieser Objekte mit geändert werden.

Einige LDAP Server können dies automatisch erledigen, andere hingegen erlauben die so genannte "Subtree Rename" überhaupt nicht:

	Active Directory: Umbenennungen von kompletten Subtrees sind kein Problem, das Verzeichnis sorgt intern für alle notwendigen Anpassungen.
	OpenLDAP: Manchmal treten in ADSI Scripts bei einem entsprechenden Versuch die unpassenden Laufzeit-fehler 0x8007054b (LDAP_DOMAIN_DOESNT_EXIST) oder auch 0x8007052e (LDAP_INVALID_CREDENTIALS) auf. Umbennen von Subtrees wird von OpenLDAP nämlich nur dann unterstützt, wenn als Backend-Datenbankengine hdb-db verwendet wird. Außerdem ist es in einem solchen Fall ratsam, Erweiterungen des OpenLDAP Servers zu implementieren, die sich bei Namensänderungen um die Anpassungen von evtl. vorhandenen DN-Referenzen in Attributen anderer Objekte zu kümmern. Eine solche Erweiterung ist das OpenLDAP Overlay RefInt (Referential Integrity, slapo-refint).
	Novell eDirectory: Umbenennungen von kompletten Subtrees sind bei eDirectory-Servern möglich, das Verzeichnis sorgt intern für alle notwendigen Anpassungen.
	Sun iPlanet / Sun Java System Directory Server: Umbennen von Subtrees ist in den modernen Versionen (DSE 6.x) standardmäßig nicht erlaubt, in ADSI Scripts tritt bei einem entsprechenden Versuch der Laufzeitfehler 0x8007054b (LDAP_DOMAIN_DOESNT_EXIST) auf. Man kann jedoch durch den Server-Parameter moddn-enableddas Umbenennen von ganzen Subtrees erlauben, hierdurch werden auch alle notwendigen internen Anpassungen vom Verzeichnis erledigt: dsconf set-server-prop -h <server> -p <port>  moddn-enabled:on
	Microsoft Exchange 5.5: Ein Exchange Server erlaubt überhaupt keine Umbenennung von Objekten, egal ob es sich um Container oder nicht handelt. Ein ADSI-Script wird hier stets den Fehler 0x8007054b (LDAP_DOMAIN_DOESNT_EXIST) bringen.