12:38 p.m.
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?
Thanks in advance
Tim
5:22 p.m.
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
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
5:51 p.m.
I would add that if you are wanting your DIT to comply with actual LDAP standards then you
wouldn’t be using that objectClass since it is an MS specific item and not part of an RFC.
On Jan 25, 2023, at 5:22 PM, Howard Chu <hyc(a)symas.com> wrote:
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
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
4:17 a.m.
On Jan 25, 2023, at 2:38 PM, Timothy Stonis <tim(a)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
313
days inactive
314
days old
openldap-technical@openldap.org
3 comments
4 participants
participants (4)
-
Howard Chu -
Quanah Gibson-Mount -
Shawn McKinney -
Timothy Stonis