If you want to rename a certain object in the LDAP directory you are connected with, you have to follow these steps:
There may be situations
where the options and buttons for renaming objects may be disabled. This might be if
the LEX ReadOnly Mode is active, or when the application focus lays on the attribute list.
Originally, the syntax of Distinguished Names was established in RFC 1779 and RFC 2253. In the meantime, the more modern RFC-Specification RFC 4514 applies here.
Most of the modern LDAP servers can handle easily the special characters of the ASCII table (for example the german o-umlaut). However, a few restrictions apply when building a Distinguished Name:
1. If object names (RDN names) shall start or end a space character, this must be preceded with a leading backslash '\'.
2. If the following characters shall be used in an object name, they also
have to be escaped with leading backslash '\'.
, + " \ < > ; =
3. If object names shall start with a "#" this
must be preceded with a leading backslash '\'. Especially
for ADS domain controllers or ADAM servers it's a strange effect that the
system uses the escaping backslash for the '#' at all
position in the name string. Normally this is not necessary, the backslash
is only important at the beginning because modern LDAP servers accept a
syntax where a name starts with "#" and consist
then of a hex code for the name.
4. Additionally, any character can be expressed with it's UTF8 value, encoded with a leading backslash for each value. So in environments where the LDAP server doesn't accept pure UTF-8 strings for distinguished names, you can easily encode all special characters for your object's names. You don't need this encoding in Active Directory environments, because you can use UTF-8 strings with special chars directly as distinguished names.
Here are some examples for UTF-8 escaped characters:
These objects have the following Distinguished Names:
cn=\ Balrog, ou=LOTR,dc=cerrotorre,dc=de
cn=Lee\, Christopher \<Saruman\>,ou=LOTR,dc=cerrotorre,dc=de
cn=McKellen\, Ian \+\+Gandalf\+\+,ou=LOTR,dc=cerrotorre,dc=de
There is a general problem when objects are to be renamed: If the DN of an renamed object was stored in an attribute of another directory object - what happens with this attribute after the rename?
A common example for such references to other objects are group memberships attributes. 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:
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.
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.
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 and an error will be returned.
Some directories don't allow moving or renaming objects which have child objects. This is also called 'Subtree Move/Rename'. Examples are older versions of Novell eDirectory, or OpenLDAP server where other backend database than hdb-db are used.
But LEX can handle this if you want: The container structure of the subtree which is to be renamed is copied to the destination. After the same container structure exists at the destination, all the leaf objects which are stored in the source containers are moved - this move is real and preserves all the attributes:
This LEX technique is called 'Subtree Cloning'. Please note that the containers (and only those) will be NEW objects in this case! If you source container object have important attribute properties, they are lost, because the copy operation of the container structure just takes the object names of the containers and doesn't transfer any attribute!
So if you are connected to an LDAP server which does not allow subtree move/rename, and you want to perform such an operation, you have to decide whether LEX should do the subtree cloning for you. Normally this message appears now:
If you want LEX to do the cloning without warning, just go to the application options (menu Tools - Options - Dialogs) and deactivate the Ask for subtree cloning if the directory doesnt support container renaming or moving option -or just click on the Don't show this dialog again.