Geek Answers Handbook

What people use for CN with inetOrgPerson in LDAP directories

I am using givenName+" "+surname for the CN field and I woke up yesterday shouting "what about John Smith"? I can imagine any large organization in which several people with the same name work. So of course it won’t work. What do people use instead?

EDIT Note: In inetOrgPerson CN is part of the DN.

EDIT Note: in this situation, I expect to grow to hundreds of thousands of user records.

+5
source share
2 answers

In an LDAP directory, whether it is OpenLDAP or Active Directory, the rule is that the DistinguishName (DN) must be unique, regardless of the attribute (or attributes) used to compose the relative distinguished name (RDN).

How people make it unique:

  1. I would say that in a small business the guy who creates an entry in the catalog ensures that he is unique, first by knowledge, then by preliminary search. If a duplicate appears, he finds some solutions, such as "John E. Smith." Using this solution, if the name changes (marriage, divorce, etc.), the LDAP record must "move" from one DN to another. It is best to avoid changing the DN of the entry if possible, but in a small directory this is not important.

  2. In medium-sized businesses, uniqueness in most cases is determined by the identifier of an employee from the personnel department. For example FR12345678. I have seen that in large companies, people log in with their employee ID. For what I am describing here, it is more standard to use the uid attribute to name an object, despite cn (but some directories do not allow you to select a naming attribute, I think this is an X500 Function).

  3. In most directories (not in AD), you can use more than one attribute to create an RDN. For example, sn=Assin+TelephoneNumber=1234 is a valid RDN in openLDAP, and this may make sense in a PBX. One more thing

In some directories (intended for system administration), some attributes are checked by the server side as unique throughout the tree. This is a case of sAMAccountName or userPrincipalName in Active Directory, and they are used for registration purposes. Using the CN attribute with "Name-Name Name" requires administrators to guarantee uniqueness. You can use the unique attribute in OpenLDAP to do this in the database definition in slapd.conf , add:

 # index since the unique overlay will search for matching mail attributes index mail eq overlay unique unique_attributes mail

If the unique overlay is not compiled, you need to recompile with:

 ./configure ... --enable-unique
+12
source

Adding an answer to JPBlanc with some of my experiences. I have several ldap servers / trees where I work. Our AD server uses DisplayName as the CN value. Of the 4K + users, we had only a few instances where duplicates occurred. I believe that the default action is to commit the value to 1 if there is an error. This is surprisingly rare, even with high turning speeds in the largest part of this user base. We have two different electronic catalog trees that are linked to each other, and they use the username. The username first has an initial + last name. All duplicates have an incremental number attached to them. As you can imagine, this happens very often with Browns and Smiths and other common names. Another tree, the ADLDS directory (formerly ADAM), uses a uniquely generated number for each new record as CN. This is basically an auto-increment number that is controlled by an external boot process. Finally, we have a directory for external partners (I think independent agents) that uses a combination of email address + identifier number as CN.

I do a lot of user-based maintenance work, and my least favorite scheme is a number created from the outside. If I get a call for support about Joe Brown on all other systems, I can at least have an idea of ​​where I need to find him. Of course, a simple search filter will give me all the Browns, but I still have to write it and execute it. Therefore, my advice is to use some part of the name for CN and ensure uniqueness somehow. From an administrative point of view, this will be a little easier. In fact, CN is important, but you will deal with the rest of the user attributes much more, so don’t sweat too much.

+5
source

More articles:


All Articles