Timothy Stonis wrote:

Hi All,

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 msuser.schema file.

Can anyone help shed some light on why this is the case

Read the msuser.schema comments more carefully.

# Only the subset of Windows 2012 attributes needed to make the # user and group objectclasses work has been added to the previously # retrieved definitions.

It may or may not work for you to uncomment other schema elements. Certainly has not been tested by us.

and maybe a pointer to what a modern best practices DIT might look like?

Thanks in advance

Tim

On Jan 25, 2023, at 2:38 PM, Timothy Stonis tim@stonis.com wrote:

Hi All,

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 msuser.schema file.

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 should use.

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

For example:

``` # Suffix dn: dc=example,dc=com objectClass: organization objectClass: dcobject dc: example o: example

# People tree dn: ou=People,dc=example,dc=com objectClass: organizationalUnit ou: People description: People container

# Group tree dn: ou=Groups,dc=example,dc=com objectClass: organizationalUnit ou: Groups 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.

HTH

— Shawn

Thanks in advance

Tim