3.6. Renaming and Moving an Entry

This section explains how to rename or move entries.


Use the moddn Access Control List (ACL) to grant permissions to move entries. For details, see Section, “Targeting Source and Destination DNs”.
The following rename operations exist:
Renaming an Entry
If you rename a entry, the modrdn operation changes the Relative Distinguished Name (RDN) of the entry:
Renaming a Subentry
For subtree entries, the modrdn operation renames the subtree and also the DN components of child entries:
Note that for large subtrees, this process can take a lot of time and resources.
Moving an Entry to a New Parent
A similar action to renaming a subtree is moving an entry from one subtree to another. This is an expanded type of the modrdn operation, which simultaneously renames the entry and sets a newSuperior attribute which moves the entry from one parent to another:

3.6.1. Considerations for Renaming Entries

Keep the following in mind when performing rename operations:
  • You cannot rename the root suffix.
  • Subtree rename operations have minimal effect on replication. Replication agreements are applied to an entire database, not a subtree within the database. Therefore, a subtree rename operation does not require reconfiguring a replication agreement. All name changes after a subtree rename operation are replicated as normal.
  • Renaming a subtree might require any synchronization agreements to be reconfigured. Synchronization agreements are set at the suffix or subtree level. Therefore, renaming a subtree might break synchronization.
  • Renaming a subtree requires that any subtree-level Access Control Instructions (ACI) set for the subtree be reconfigured manually, as well as any entry-level ACIs set for child entries of the subtree.
  • Trying to change the component of a subtree, such as moving from ou to dc, might fail with a schema violation. For example, the organizationalUnit object class requires the ou attribute. If that attribute is removed as part of renaming the subtree, the operation fails.
  • If you move a group, the MemberOf plug-in automatically updates the memberOf attributes. However, if you move a subtree that contain groups, you must manually create a task in the cn=memberof task entry or use the fixup-memberof.pl to update the related memberOf attributes.
    For details about cleaning up memberOf attribute references, see Section, “Regenerating memberOf Values”.

3.6.2. Renaming Users, Groups, POSIX Groups, and OUs

The dsidm utility can rename several types of objects:
  • Users:
    # dsidm -D "cn=Directory manager" ldap://server.example.com -b "dc=example,dc=com" user rename current_user_name new_user_name
    Note that the dsidm user rename command automatically places ou=People in front of the base DN you have specified.
  • Groups:
    # dsidm -D "cn=Directory manager" ldap://server.example.com -b "dc=example,dc=com" group rename current_group_name new_group_name
    Note that the dsidm group rename command automatically places ou=Groups in front of the base DN you have specified.
  • POSIX Groups:
    # dsidm -D "cn=Directory manager" ldap://server.example.com -b "dc=example,dc=com" posixgroup rename current_posix_group_name new_posix_group_name
    Note that the dsidm posixgroup rename command automatically places ou=Groups in front of the base DN you have specified.
  • Organizational Units (OU)
    # dsidm -D "cn=Directory manager" ldap://server.example.com -b "dc=example,dc=com" organizationalunit rename current_ou_name new_ou_name
    The dsidm organizationalunit rename command performs the rename operation directly in the base DN you have specified.

3.6.3. The deleteOldRDN Parameter When Renaming Entries Using LDIF Statements

When you rename an entry, the deleteOldRDN parameter controls whether the old RDN will be deleted or retained.
deleteOldRDN: 0
The existing RDN is retained as a value in the new entry. The resulting entry contains two cn attributes: one with the old and one with the new common name (CN).
For example, the following attributes belong to a group that was renamed from cn=old_group,dc=example,dc=com to cn=new_group,dc=example,dc=com with the deleteOldRDN: 0 parameter set.
dn: cn=new_group,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: old_group
cn: new_group
deleteOldRDN: 1
Directory Server deletes the old entry and creates a new entry using the new RDN. The new entry only contains the cn attribute of the new entry.
For example, the following group was renamed to cn=new_group,dc=example,dc=com with the deleteOldRDN: 1 parameter set:
dn: cn=new_group,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: groupofuniquenames
cn: new_group

3.6.4. Renaming an Entry or Subtree Using LDIF Statements

To rename an entry or subtree, use the changetype: modrdn operation and set the new RDN in the newrdn attribute.
For example, to rename the cn=demo1,dc=example,dc=com entry to cn=demo1,dc=example,dc=com:
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: cn=demo1,dc=example,dc=com
changetype: modrdn
newrdn: cn=demo2
deleteOldRDN: 1

3.6.5. Moving an Entry to a New Parent Using LDIF Statements

To move an entry to a new parent, use the changetype: modrdn operation and set the following to attributes:
Sets the RDN of the moved entry. You must set this entry, even if the RDN remains the same.
Sets the DN of the new parent entry.
For example, to move the cn=demo entry from ou=Germany,dc=example,dc=com to ou=France,dc=example,dc=com:
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: cn=demo,ou=Germany,dc=example,dc=com
changetype: modrdn
newrdn: cn=demo
newSuperior= ou=France,dc=example,dc=com
deleteOldRDN: 1