Table of Content > Renaming LDAP Directory Objects

Renaming LDAP Directory Objects

This topic of the SelfADSI tutorial deals with the renaming of LDAP directory objects. The following content is available here:

Renaming Objects with MoveHere

Directory objects are labeled with Distinguished Names. These names determine the object location in the directory hierarchy as well as the actual object name. In this context, the object name is similar with a filename in a file system (in comparison to the complete file pathname) and it is also called Relative Distinguished Name (RDN).

The renaming of an object changes its RDN - and therefore its DN also. This is the reason why this operation looks a bit strange in an ADSI script: You have to "move" the object into its own container (so essentially it isn't move at all). But: In this Move-operation the object name can be newly set. This is done with the ADSI function MoveHere:

MoveHere is a method for container objects. This means that we first have to connect to the OU in which the object to be renamed is stored.

An example: We want to rename the user object "Philipp" in the OU "ou=Developper,dc=cerrotorre,dc=de", the new name should be "PhilippFoeckeler". To achieve this, we connect with a LDAP Bind operation to the regarding OU, then we use the function MoveHere:

Download Script

A more general version:

Download Script

As you can see, the two parameters for MoveHere are different. The first (old) object name in the example is given in the notation

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

as a complete LDAP pathname, whereas the second parameter is a relative distinguished name:

cn=PhilippFoeckeler

Now you could code a quite general renaming function for your own scripts. In this function we automatically extract the container DN out of the given complete DN of the old name. This container DN starts after the first comma (Attention, commas inside the RDN have to be blanked out, they are marked with a "\," by default - see the annotations for LDAP pathnames for this detail). The necessary new RDN for the renamed object can be automatically generated as well:

Download Script

References to renamed Objects

The renaming of an object poses a general problem: If the distinguished name of an renamed object was stored in an attribute of another object - what happens with this attribute after the rename?

A common example for such references to other objects is the definition of group memberships. But there are other attributes as well which holds references and should be considered when renaming objects. This is how the different directory services handles this issue:

	Active Directory: References to other objects will be adjusted automatically by the server when objects are renamed. This is true for all attributes with DN content. A special case: There could be references even to objects in other domains in universal groups. This is more complicated, because these are objects outside of the server's own directory domain database. In this scenario the domain controller with the FSMO role 'Infrastructure Master' performs the adjustment for such references.
	OpenLDAP: When objects are renamed, OpenLDAP can adjust the references in other attributes, but it needs a special plug-in (a so called overlay) for this: For this purpose you have to activate the overlay RefInt (Referential Integrity, slapo-refint) on the OpenLDAP server.
	Novell eDirectory: References to other objects will be adjusted automatically by the server when objects are renamed. This is true for all attributes with DN content.
	Sun iPlanet / Sun Java System Directory Server: When objects are renamed, a Sun Directory Server can adjust the references in other attributes, but it needs the activation of a special plug-in for this: Referential Integrity dsconf set-server-prop -h <server> -p <port>  ref-integrity-enabled:on After this configuration you have to restart the whole server daemon, furthermore you have to configure all the attributes which are to be monitored by the Referential Integrity plug-in: 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: An Exchange 5.5 cannot handle such references on name changes. Therefore object renaming is not allowed and all trials to rename an object will be suppressed - an ADSI script will raise the runtime error 0x8007054b (LDAP_DOMAIN_DOESNT_EXIST).

Renaming Containers

If you want to rename LDAP containers (for example organizational units), it's the same approach like in renaming single objects. However, renaming of a container object with content therein needs more effort for the directory server as you might think. Because not only the DN of the container has to be changed here, but also the DNs of all the contained objects.

Some LDAP servers can handle this automatically, but others doesn't allow this so called 'subtree rename' at all.

	Active Directory: Renaming of complete subtrees with contained objects is not a problem - the directory performs all the necessary adjustments.
	OpenLDAP: Sometimes there will be runtime errors in ADSI script if you try to rename a subtree in an OpenLDAP server. It will be the quite improper error codes 0x8007054b (LDAP_DOMAIN_DOESNT_EXIST) or 0x8007052e (LDAP_INVALID_CREDENTIALS). This is because OpenLDAP supports subtree renaming only if you use the backend database hdb-db. In addition to this, it is advisable to implement extensions to the OpenLDAP server, which can handle the attribute adjustments of references to renamed objects. Such an extension is the OpenLDAP overlay RefInt (Referential Integrity, slapo-refint).
	Novell eDirectory: Renaming of complete subtrees with contained objects is normally not a problem - the directory performs all the necessary adjustments.
	Sun iPlanet / Sun Java System Directory Server: Renaming of subtrees or non-leaf objects is not allowed in modern versions (DSE 6.x), in ADSI scripts the following error code will be raised: 0x8007054b (LDAP_DOMAIN_DOESNT_EXIST). But you can change this behavior with the server parameter moddn-enabled, the directory server can handle all the necessary internal adjustments: dsconf set-server-prop -h <server> -p <port>  moddn-enabled:on
	Microsoft Exchange 5.5: An Exchange 5.5 server doesn't allow object renaming at all, no matter if it's about container or not. An ADSI script will raise the runtime error 0x8007054b (LDAP_DOMAIN_DOESNT_EXIST).