On Jan 25, 2023, at 2:38 PM, Timothy Stonis <tim(a)stonis.com>
I’ve searched the internet, but can’t find any info, so sorry in advance if this is a
basic question… I’m trying to setup a “standard” DIT in an OpenLDAP 2.6.3 deployment. I
checked out my existing Active Directory deployment and also an old macOS Server
implementation, and they both make heavy use of the “container” structural class. For
example, users are in cn=users,dc=…,dc=… which is objectClass container. I see this class
is defined in the msuser schema, but in 2.6.3 it’s definition is commented out in the
Can anyone help shed some light on why this is the case and maybe a pointer to what a
modern best practices DIT might look like?
As others have pointed out, it’s not considered a best-practice to follow MS conventions
in LDAP, as its known to deviate from common standards.
Not knowing your req’s so it’s not possible for us to define which object classes you
If it a greenfield implementation, I’d probably use inetorgperson object class for user.
It contains all of the attributes commonly needed by web applications.
If there are additional attributes (a common req) simply override the user object class
that comes closest to matching what you need.
If your implementation has to interface with MS, e.g. AD, or is supporting its apps, well
then you might be stuck trying to figure out how to get that to work. Expect some
frustration, and you might need to get some help. There are certainly companies that earn
their living on that edge.
WRT to how to structure the DIT. That’s entirely up to you. Proper LDAP clients should
never expect a particular schema or DIT structure. Common naming conventions would be
#### Sample LDIF
# People tree
description: People container
# Group tree
description: Group container
Other things to I try to do:
- Store entries ‘flat’ under a container (e.g. ou=people).
There are of course many more things to think about as we start delving into requirements.
Thanks in advance