October 10, 2016 at 11:51 am #13573
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 youOctober 10, 2016 at 1:43 pm #13575
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.
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.
billOctober 11, 2016 at 2:53 pm #13608
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 !October 11, 2016 at 3:18 pm #13614
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).
billOctober 11, 2016 at 3:46 pm #13618
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 !October 11, 2016 at 4:08 pm #13620
Glad I could point you in the right direction.
You must be logged in to reply to this topic.