[Fedora-directory-users] Virtual DIT views vs hierarchical DIT

[Sam Tran]

On 6/24/05, Jeff Clowser <jclowser at unitedmessaging.com> wrote:

> Personally, yes, that is my preference.  But... sometimes the apps you
> deploy will overrule that.  For those apps, views may be the solution
> (personally, I've never used views).  In some cases, an application
> specifies a particular hierarchy, but if you look at what it actually
> does in the access logs, there may be flexibility.  I.e. the app may not
> _really_ care about the DIT, but the app's admin tool does - in these
> cases, you may be able to just replace the apps admin tool with
> something homegrown.  You may have to do that anyway if you are
> integrating a lot of apps and want one common admin tool.  Designing a
> "good" dit can be an art, though, and _can_ have a lot to do with the
> apps you are going to use with it.
> 
> For a "simple" DIT, have your suffix, then have ou=people, ou=groups,
> etc under that to split up different types of entries - that's a simple,
> generic DIT, and is the default FDS creates.  Definately don't go
> completely flat (i.e. _everything_ right under your suffix - I don't
> think I've _ever_ seen anyone do it _that_ flat :)  )  Define
> organizational hierarchy (departments, regions, etc) as attributes in
> entries rather than as branches in the tree, if you can.
> 
> A lot of the time I see "tall" DIT's because of limitations in the LDAP
> implementation (i.e. they have to do that to scale it across many boxes
> to handle the number of entries it has to handle), for administrative
> reasons (i.e. we have things like o=custdomain,o=isp with ou=people,
> ou=groups, etc under it to segregate customers - we can apply aci's and
> other administrative limitations based on that),  application
> requirements (unfortunately), inexperience (people try to define their
> entire organizational structure in the LDAP DIT - which is good until
> next month when there is a re-org), etc.
> 
> Personally, I'd say keep it as flat as possible, but don't be afraid to
> create branches where it makes sense (what makes sense is where the
> "art" comes in).  Basically stay away from creating branches based on
> things that are likely to change - i.e. a customers domain probably
> don't change very often, but a companies org chart is almost guaranteed to.
> 
> Also, remember that these are only guidelines, not hard and fast rules
> :)  Your specific situation will greatly affect what you do in the end.
> Do you have a list of apps you are integrating against LDAP, a list of
> requirements for administration, delegation, what can see what, etc?
> Maybe throw some of that info on the list and you'll get more concrete
> advice that applies to your particular situation :)
> 

Jeff,

Thanks again for your input.

We have about 1,300 employees grouped by departments (Finance, HR, IT,
...) and some contractors and volunteers.

Since we have the opportunity to redesign the DIT in a few months I
have been thinking on improving the DIT structure.

Most of the applications that use our Directory for information
retrieval or authentication are UNIX based: SMTP, IMAP, FTP, RADIUS,
web based applications, ... Of course we also have a web interface for
users to perform Directory Searches (email, phone numbers, location,
...).

As for the administration we have two set of Admins:
- the LDAP admins who have all rights on the Directory
- the Call Center who have limited rights: reset user passwords,
account creation, some attributes modification, ...

As of today our DIT is 'simple' with ou=people, ou=group, ... etc.

I am tempted to go for a DIT that models our organisational chart. I
am not sure yet if would be a significant improvement in our
situation.

Thanks.
Sam