Re: Change a user dn

[Philip Guenther <guenther+ldaptech@sendmail.com>]

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