[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Regarding LDAP structure

On Thu, Mar 13, 2014 at 12:18 PM, Joshua Riffle <jriffle@apu.edu> wrote:
> I'm aware this may not be the best mailing list to discuss something as
> generalized as best practices for LDAP structuring within OpenLDAP, but
> would anyone be able to direct me to a mailing list that would be better
> suited for this kind of conversation?
>

I think it's an excellent discussion and I don't see why this list
cannot accommodate it. After all, OpenLDAP is currently a reference
model in the OSS world for LDAP so it could very well house discussion
around reference models for DITs.

> I'm looking for any or all of these kinds of communications within a mailing
> list:
>
> Designing a person, account, group LDAP tree directory that would be
> scalable and flexible enough to grow to large sizes (millions) and still
> have a grip on best practices for identity management on an enterprise
> level.

Usually you should aim towards a DDS (Distributed Directory Service)
and all nodes sharing some sort of agreement in the DIT structure
although it's not alway necessary.

> Specifically for an educational institution if I can share the aches and
> pains of other directory owners with similar problems.
> I also am trying to prove / disprove the use of having a person directory
> object with multiple child account objects as good or bad architecture and
> understand why. I've never seen this discussed in practice.

Most LDAP implementations are quite poor and revolve around Posix
and/or Windows AD management instead of using more elaborate DIT
modelling , aliasing, and the entryUUID operational attribute (RFC
4530). The DIT model is unique to every application but I do agree
with you that we should have some reference models that break the
traditional People, Computer Group paradigm.

RDN and DN are actually quite malleable and should never be used as
unique identifiers of any sort, but rather as temporary
addresses/names to locate entries, much the same way a person may have
different addresses throughout his life yet remain the same person
(aliases to a single entry/entryUUID). By the same token, two people
may have identical attributes, yet be two distinct individuals
(distinct entries/entryUUID). This can also happen in an LDAP DIT as
the LDAP specification purposely makes no effort in preventing or
controlling this. Moreover, the entryUUID is the perfect "key" to
integrate your LDAP technology to other data sources that may need to
"link" with the LDAP. So long as your tools actually use moddn and
modrdn (as opposed to deleting and re-creating the entry) then the
entryUUID should never change for the life of the entry regardless on
where it's located in the DIT.


> Good and bad ways to relate tree objects with each other. I only know of
> parent / child tree relationships or more "softly" by using DN's within an
> attribute like the group-member relationship.
>

There are two popular and generic reference models for LDAP DIT
hierarchies: (a) the more traditional X.500 form, and (b) the more
modern domain-based around the DNS model. Each one is just a general
guideline and they are by no means strict models for any LDAP
implementation. In fact, the whole idea behind X.500 and LDAP is
precisely that the model is flexible and adaptable over time, meaning
that you don't have to "get it right" from the start and should be
able to evolve your DIT over time, provided of course that your
toolset is adequate. Web-based tools such as LAM for example are
almost hard-wired into a People, Computer, Group paradigm whereas
tools like PHPLDAPAdmin are more flexible but less intuitive. The
latter provides a template mechanism which allows for easy
customization to a particular implementation, but I think both (as
almost all popular LDAP browsers/admin tools) are dumb in terms of
moddn and modrdn so you need to hack them to work correctly with more
complex implementations.

Anyway, the point is that your entries should be organized anyway you
want. I have done implementations where we can actually traverse the
DIT in a hierarchical manner (e.g. by units and departments with
people at different levels of the tree) but that can ALSO be queried
by means of a common attribute(s). So you can actually have it both
ways. I always prefer to model the DIT to reality and then group the
entries by attributes to simplify queries. This gives you the best of
both worlds as you can query at any level/branch and also allows to
implement a DDS more easily. Actually I encourage mixing the X.500
with the Domain-based

We have a very well documented reference implementation for an
educational institution and we would happily share in a Wiki
somewhere. Perhaps we can find a place where people can contribute
reference implementations for different implementations and that
allows for discussions, etc. Any idea where to post these??


Best,
Alejandro Imass
Yabarana Corporation