Add an attribute (UID) to the DN

This topic has 5 replies, 2 voices, and was last updated 5 years, 1 month ago by Bill Nelson.

  • Author
    Posts
  • #13573
     pier
    Participant

    Hi,

    Please bear with me as I am no LDAP expert, I am looking for the best practice to add an attribute to the DN, (the UID in this case).

    I found out that this was possible but I do not want to try anything before having some expert advices :)

    thank you

    #13575
     Bill Nelson
    Participant

    The DN (or distinguished name) represents the path of the entry in relation to your root suffix. For instance, the following DN would represent an entry identified by a uid of bnelson that exists beneath the people container, in the suffix dc=example,dc=com.

    uid=bnelson,ou=people,dc=example,dc=com

    The leftmost portion of the DN is referred to as the RDN (or “relative” distinguished name) as the entry identified by the RDN must be unique at this portion of the tree structure (i.e. you cannot have two entries represented by uid=bnelson beneath the ou=people container).

    Now, having said all that, when you create a new record, you define the RDN and can select any attribute contained in the user’s object to do so. There are common naming attributes that are typically used over others, and uid is one of the most common when referring to a user type of object. So, how do you add this? There are many LDAP tools out there that you can use, but OpenDJ ships with a command line tool called ldapmodify that is used to modify the OpenDJ directory tree.

    /path/to/opendj/bin/ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -w password --defaultAdd --continueOnError --filename ./entries.ldif 1> stdout.fil 2> rejects.fil

    Where the contents of the entries.ldif LDIF file would be:

    dn: uid=bnelson,ou=people,dc=example,dc=com
    objectClass: inetOrgPerson
    objectClass: person
    objectClass: organizationalUnit
    objectClass: top
    cn: Bill Nelson
    sn: Nelson
    uid: bnelson

    The uid attribute is defined in the inetOrgPerson object class, you must include an object class that defines the RDN attribute when you add it (objectClass: inetOrgPerson). The uid and corresponding value (uid: bnelson) must also be included in the entry when you add it as well as any other attributes required by the schema you select.

    So in a nutshell, you define the DN when you add the entry to the tree. But you need to a) select an objectclass that includes the naming attribute, and b) include the value of the attribute in the entry’s data.

    bill

    #13608
     pier
    Participant

    Thanks a lot bill, you’ve been pretty useful as usual.

    In my case we wish to update an existing branch, this branch is, at the moment, having each container’s DN built over the container’s CN + path (ou,dc etc)

    What would be the best way (if possible) to update an entire tree branch in order to add the UID in the DN ?

    Thanks Bill for your advice !

    #13614
     Bill Nelson
    Participant

    If you already have existing entries and you want to change the RDN, then the operation you are performing is called the modrdn operation – essentially you are modifying the relative distinguished name (and therefore the entire DN).

    The LDAP protocol does not provide a method of performing a mass modification based on some container change. So you would need to either:

    a) write a script that performs a “walk” of you directory information tree (DIT) and perform the operation on those items you want to change

    b) export your database to LDIF, write a script that modifies the LDIF data, and then initialize your database based on the new LDIF data.

    Selecting the best DIT structure, choosing appropriate naming attributes, schemas design, etc. is an essential process for the proper design of your LDAP implementation. You should never simply take what comes “out of the box” from any vendor’s product as they provide that to you to help you understand, not as a starting point. Making mass changes afterwards can be a big pain, as you are seeing now.

    Having said that, however, I have had to modify existing data for many of our customers that did not follow appropriate design principals and the manner I have performed falls into one of these two methods. There are already some tools (like Softerra LDAP Administrator) that have some of these capabilities built in to assist you with modifying existing data and even perform recursion for some operations. But when I run into a more extensive issue, I typically export/massage/import the data into the LDAP server.

    What you are asking for doesn’t seem all that difficult to write with Perl (my tool of choice).

    bill

    #13618
     pier
    Participant

    Bill,

    Thanks for your valuable advice, and yes I confirm that my company DID NOT plans anything regarding our current LDAP implementation, quite sad but still I have to handle this now….

    So far I’ve found the modrdn keyword, and it looks like the export / mod / import ldif is the best choice as I am much more experienced with linux system tools (such as bash scripts) than I am with LDAP :)

    I’ll handle this from now on, thanks to your valuable posts Bill, thanks again !

    #13620
     Bill Nelson
    Participant

    Glad I could point you in the right direction.

    Good luck!

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.

©2021 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?