LEX Online Manual Content

Renaming Directory Objects

If you want to rename a certain object in the LDAP directory you are connected with, you have to follow these steps:

Select the object you want to rename in the object list. You must not select more than one object. If you want to rename a container object, you also can do that by select it in the treeview panel. Please note the information about renaming containers mentioned below in this topic.
You have two different options now. What you should do depends on the complexity of the renaming operation you wish to perform:

Method 1: If you just want to enter a simple object name where the RDN specifier ('cn=' , 'ou=' etc.) will remain the same, you can just press F2 and an inplace edit text box appears over the objects name:

The same in the treeview:

Please note that this quick rename is in the object list only possible if you are NOT browsing in deeptree mode and if your objects are displayed with friendly names! Otherwise you see the dialog described in the next paragraph if you press the F2 key.

Method 2: If the desired object name contains special characters or do you want to change the RDN specifier ('cn=' , 'ou=' etc.) also, then you have to use the menu option Edit - Rename Object - or you just opens the context menu (right mouse-click) and choose the option Rename Object. Then a dialog appears where you can edit the full RDN (relative distinguished name):

This would be the only possibility to set Object names which starts with a blank:

This would also be the only possibility to set multivalued RDN specifiers:

Please read the next paragraph for more information about special characters in object names.

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.

Special Characters in Distinguished Names

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:

Character	UTF-8 Representation
ä	\79
,	\2C
\	\5C
®	\C2\AE
½	\C2\BD
Ω	\CE\A9
€	\E2\82\AC

A few general examples for special characters in the distinguished name, shown in an Active Directory Environment:

Object Names with special characters

These objects have the following Distinguished Names:

cn=\ Balrog, ou=LOTR,dc=cerrotorre,dc=de
cn=\#G#o#l#u#m#,ou=LOTR,dc=cerrotorre,dc=de
cn=Blanchet\, Cate,ou=LOTR,dc=cerrotorre,dc=de
cn=Jackson\2C Peter,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

Referential Integrity for renamed Objects

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:

	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 and an error will be returned.

Renaming Subtrees

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:

Special subtree rename by LEX

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:

Subtree move/rename warning message

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.