On Mon, 12 Sep 2011, Juan Diego Calle wrote:
Ok, let me rephrase this, I have read many books, like O'reilly s LDAP system administratoro, or docs like Or http://tools.ietf.org/html/rfc4511#section-4.9, that explains this exactly
The Modify DN operation allows a client to change the Relative Distinguished Name (RDN) of an entry in the Directory and/or to move a subtree of entries to a new location in the Directory. The Modify DN Request is defined as follows:
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { entry LDAPDN, newrdn RelativeLDAPDN, deleteoldrdn BOOLEAN, newSuperior [0] LDAPDN OPTIONAL }Fields of the Modify DN Request are:
entry: the name of the entry to be changed. This entry may or may not have subordinate entries.
newrdn: the new RDN of the entry. The value of the old RDN is supplied when moving the entry to a new superior without changing its RDN. Attribute values of the new RDN not matching any attribute value of the entry are added to the entry, and an appropriate error is returned if this fails.
At that point in the RFC is a page break, followed by a description of the *other* two fields in the request:
- deleteoldrdn: a boolean field that controls whether the old RDN attribute values are to be retained as attributes of the entry or deleted from the entry.
- newSuperior: if present, this is the name of an existing object entry that becomes the immediate superior (parent) of the existing entry.
I read the paragraph above, and it seems pretty straight forward, I believe I understand how it works, but when I try to apply this to what I need I dont know what to do. I can change the UID, or other fields from the users or groups, but i can change the dn.
...
dn: uid=user1,ou=People,dc=mydomain,dc=com changeType: modrdn newRDN: uid=user1,ou=Group1,ou=People,dc=mydomain,dc=com deleteOldRDN: 1
The newRDN field takes a *relative* DN, not a full DN, so that has to be newRDN: uid=user1
Now, do you want "uid: user1" to continue to be present in the entry? Yes, so deleteOldRDN should be 0 instead of 1. So at that point you have this:
dn: uid=user1,ou=People,dc=mydomain,dc=com changeType: modrdn newRDN: uid=user1 deleteOldRDN: 0
Where's the specification of the rest of the new DN? Ah, that's the newSuperior field:
newSuperior: ou=Group1,ou=People,dc=mydomain,dc=com
Putting it together: dn: uid=user1,ou=People,dc=mydomain,dc=com changeType: modrdn newRDN: uid=user1 deleteOldRDN: 0 newSuperior: ou=Group1,ou=People,dc=mydomain,dc=com
Oh, and also on that next page of the RFC you'll find this paragraph:
The object named in newSuperior MUST exist. For example, if the client attempted to add <CN=JS,DC=Example,DC=NET>, the <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did exist, then the server would return the noSuchObject result code with the matchedDN field containing <DC=NET>.
So, does "ou=Group1,ou=People,dc=mydomain,dc=com" exist before you do this?
Alternatively, a simpler way to tackle this problem might be to use the ldapmodrdn binary and its -s option.
Philip Guenther