The LDAP modify DN operation may be used to change an entry’s DN. It can be used to rename the entry (by changing its RDN), move it to a different location in the DIT (by specifying a new parent entry), or both. Although the correct name for this operation is “modify DN” in LDAPv3, it’s sometimes referred to as “modify RDN” because the LDAPv2 version of the operation only allowed you to alter the RDN but did not allow you to specify a new superior DN.
This operation can be requested against either a leaf entry (one that doesn’t have any subordinates) or a non-leaf entry (one that does have one or more subordinates). Since processing a modify DN operation against a non-leaf entry requires altering the DNs of all of its subordinates, some servers only support modify DN operations against leaf entries and would reject any attempt to alter the DN of a non-leaf entry with a notAllowedOnNonLeaf (66) result code. And in some environments, in which portions of the DIT are spread across multiple servers or database environments, changing an entry’s DN may require moving it to a different server or database environment. Many servers don’t support that, and those that don’t would reject such an attempt with an affectsMultipleDSAs (71) result code.
RFC 4511 section 4.9 defines the modify DN request protocol operation as follows:
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
entry LDAPDN,
newrdn RelativeLDAPDN,
deleteoldrdn BOOLEAN,
newSuperior [0] LDAPDN OPTIONAL }
The dependencies, defined elsewhere in RFC 4511, are:
LDAPDN ::= LDAPString
-- Constrained to <distinguishedName> [RFC4514]
RelativeLDAPDN ::= LDAPString
-- Constrained to <name-component> [RFC4514]
LDAPString ::= OCTET STRING -- UTF-8 encoded,
-- [ISO10646] characters
The BER type of the modify DN request protocol op is 0x6c (application class, constructed, tag number twelve), and the elements of the request sequence are:
For example, the following request can be used to rename the entry uid=jdoe,ou=People,dc=example,dc=com to uid=john.doe,ou=People,dc=example,dc=com. The new uid value of john.doe will be added to the entry, and the old uid value of jdoe will be removed.
30 3c -- Begin the LDAPMessage sequence
02 01 02 -- The message ID (integer value 2)
6c 37 -- Begin the modify DN request protocol op
04 24 75 69 64 3d 6a 64 6f 65 -- The DN of the entry to rename (octet string
2c 6f 75 3d 50 65 6f 70 -- "uid=jdoe,ou=People,dc=example,dc=com")
6c 65 2c 64 63 3d 65 78
61 6d 70 6c 65 2c 64 63
3d 63 6f 6d
04 0c 75 69 64 3d 6a 6f 68 6e -- The new RDN (octet string "uid=john.doe")
2e 64 6f 65
01 01 ff -- Delete the old RDN value (boolean true)
And the following request can be used to move entry uid=john.doe,ou=People,dc=example,dc=com to be immediately below the ou=People,dc=example,dc=com entry. The RDN will not be altered.
30 5c -- Begin the LDAPMessage sequence
02 01 03 -- The message ID (integer value 3)
6c 57 -- Begin the modify DN request protocol op
04 28 75 69 64 3d 6a 6f 68 6e -- The DN of the entry to move (octet string
2e 64 6f 65 2c 6f 75 3d -- "uid=john.doe,ou=People,dc=example,dc=com")
50 65 6f 70 6c 65 2c 64
63 3d 65 78 61 6d 70 6c
65 2c 64 63 3d 63 6f 6d
04 0c 75 69 64 3d 6a 6f 68 6e -- The new RDN (octet string "uid=john.doe")
2e 64 6f 65
01 01 00 -- Don’t delete the old RDN value (boolean false)
80 1a 6f 75 3d 55 73 65 72 73 -- The new superior DN (octet string
2c 64 63 3d 65 78 61 6d -- "ou=Users,dc=example,dc=com" with type
70 6c 65 2c 64 63 3d 63 -- context-specific primitive zero)
6f 6d
Both of the above changes (replacing the RDN and moving it beneath a new parent) could have been made in a single request. That would look like:
30 58 -- Begin the LDAPMessage sequence
02 01 02 -- The message ID (integer value 2)
6c 53 -- Begin the modify DN request protocol op
04 24 75 69 64 3d 6a 64 6f 65 -- The DN of the entry to move/rename (octet
2c 6f 75 3d 50 65 6f 70 -- string "uid=jdoe,ou=People,dc=example,dc=com")
6c 65 2c 64 63 3d 65 78
61 6d 70 6c 65 2c 64 63
3d 63 6f 6d
04 0c 75 69 64 3d 6a 6f 68 6e -- The new RDN (octet string "uid=john.doe")
2e 64 6f 65
01 01 ff -- Delete the old RDN value (boolean true)
80 1a 6f 75 3d 55 73 65 72 73 -- The new superior DN (octet string
2c 64 63 3d 65 78 61 6d -- "ou=Users,dc=example,dc=com" with type
70 6c 65 2c 64 63 3d 63 -- context-specific primitive zero)
6f 6d
RFC 4511 section 4.9 also defines the modify response protocol operation. That definition is:
ModifyDNResponse ::= [APPLICATION 13] LDAPResult
That is, the modify DN response protocol op is simply an LDAPResult (which we already covered in an earlier section) with a BER type of 0x6d (application class, constructed, tag number thirteen). The encoding of the modify DN response is the same regardless of whether the request included a new superior DN.
A successful modify DN response would be encoded as:
30 0c -- Begin the LDAPMessage sequence
02 01 02 -- The message ID (integer value 2)
6d 07 -- Begin the modify DN response protocol op
0a 01 00 -- success result code (enumerated value 0)
04 00 -- No matched DN (0-byte octet string)
04 00 -- No diagnostic message (0-byte octet string)
| Previous: The LDAP Modify Operation | Next: The LDAP Search Operation |