> On Jan 25, 2023, at 2:38 PM, Timothy Stonis <[email protected]> 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
