Is it possible to allocate one user (entry) below two different OU (Organizational Unit) in OpenLDAP?

Question

I'm planning the structure of a brand new OpenLDAP server to integrate it with Moodle.

I thought about the following structure:

• O=CompanyName
  • OU=ProjectName
    • uid=UserID001
    • uid=UserID002
    • uid=UserID003
  • OU=ProjectName
    • uid=UserID002

See that the same user 'uid=UserID002' can be allocated in one or more Projects. This would make synchronization between softwares and LDAP easier.

Is it possible to do that using OpenLDAP? I heard that IBM LDAP allow it, is it true? Is there any kind of 'symbolic link' to an entry?

Answer 1

You're best to use the memberOf overlay.

You use the groupOfNames object class (that's already there) to specify members that will belong to project entry using the member attribute. You can add as many member attributes as you want, where each member attribute is a (full) DN.

Personally I would create my own objectClass (e.g. called project) that extended the groupOfNames class so I could add extra project related attributes to it. But depends how complex you want to get.

You would then redefine your structure like the following...

• O=CompanyName
  • OU=People
    • uid=UserID001
    • uid=UserID002
    • uid=UserID003
  • OU=Projects
    • cn=ProjectName
    • cn=ProjectName...

This would make your structure a lot cleaner and with the Project items (eg. cn=ProjectName) being kept separate from your user entries. The project items would be your groupOfNames classes that contain member attributes to the people in the OU=People class (e.g. member: uid=UserID001,OU=People,O=CompanyName).

What the memberOf overlay will do, when installed into your olap, will add an additional attribute called member of to your ldap search results (it's dynamically generated).

This is quite a common overlay that's used, and is even used by AD servers, so this method is commonly used and you might find that Moodle will understand them.

A little thing to watch out for when testing your setup.... ldapsearch queries won't show the memberof attribute by default, so you will need to specifically ask for it. e.g.;

ldapsearch -Y EXTERNAL -H ldapi:/// "(objectClass=groupOfNames)" uid, memberof

That one stumped me when I first started using them. I think there is an 'all' option that will force the search to show the hidden attributes, but can't think what it is at the moment. Check out ldapsearch's man pages.

Anyway, hope that helps.. :)

Answer 2

You can do that using LDAP aliases easily enough, but the general idea in these cases is to use a schema such as organizationalRole for the project nodes. organizationalRole has multi-valued roleOccupant attribute, which are DNs of entries that occupy the role ... rather than creating an entire forest of subcontexts under each project. So you just search each project, or all of them, for (roleOccupant={0}) where {0} is supplied as the DN you're checking on.

Answer 3

Some directory servers support the notion of attribute uniqueness, going so far as to have a plugin for uid uniqueness. You should contact your directory server administrator to determine whether your local directory services support the notion of attribute uniqueness, and if it does, is the attribute uniqueness configured for the uid attribute.

As far as the general concept of naming attribute uniqueness is concerned, there is nothing about your idea that should not be supported by a professional-quality directory server that supports the group of LDAP standards. uid is just an attribute, and in your example there is nothing special about it except that it becomes a relative distinguished name component. The object that identifies an entry in the directory server is the distinguished name, the uid is an attribute like any other.

According to RFC4512, LDAP does support the notion of aliases, but that functionality should not be used in your case.