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

[Sam Tran]

On 6/24/05, Jeff Clowser <jclowser at unitedmessaging.com> wrote:
> Sam Tran wrote:
> 
> >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.
> >
> >
> I would strongly recommend against this - what you already have is
> probably better.  If you build based on your org chart, any change in
> that organization will break your DIT, and/or cause you to do a LOT of
> work to move things around, especially since you are not delegating
> administration beyond 2 global administrative levels (i.e. both your
> types of admins administer all users in some way).  Even if your
> organizational chart does not change, if users move from one part of the
> org to another you have to move them, which is a pain, and may break a
> lot - consider the following:
> 
> - You want to move a user from HR to marketing.  I don't think FDS
> supports changing the DN (other than the rdn - i.e the left most DN
> component).
> - You try to create the user under marketing, then delete them under
> HR.  But, you can't create it because of uid uniqueness.
> - Instead you delete the old entry then create the new entry.  But...
> something happens between deleting and creating, and you could loose the
> entry (depends on how you do this - but if it's a web app that does
> this, recovering could be a pain).
> - When you delete a user, referential integrity removes them from all
> groups they are static members of.  So, you have to figure out what
> groups they were part of first, then be sure to add the "new" user to
> the same groups.
> 
> 
> What I like to do is the following:
> 1.  Have an objectclass (maybe more) for each application.  i.e. you
> might have a mailuser objectclass, radiususer obejctclass, etc.  Some
> apps might have multiple oc's (i.e. mail might have mailuser mailgroup,
> etc).
> 2.  Each of these objectclasses may have additional attributes - for
> example, mailuser might define a mailhost, email address, delivery type,
> forwarding attributes, etc.  Some (like radiususer) may
> define/require/allow no additional attributes.
> 3.  Either via a filter (if at all possible) or an aci, set each app to
> only see resources it is supposed to see.  For example, in your radius
> server, if you can add (objectclass=radiususer) to the filter the radius
> server uses to find users, you can limit who gets radius and who
> doesn't.  Or, you can use aci's (or maybe views?) to limit the radius
> server to only see entries with objectclass=radiususer in ldap if you
> can't set the filter for finding users.  Same for other apps.  Depending
> on what you are using for mail, ftp, etc, the app may have already
> defined schema extensions for you to use.
> 4.  For organizational hierarchy, define that in attributes -
> department, region, country, org unit, whatever, put these as attributes
> in the users entry (you may want to look at CoS if you want to populate
> a lot of info based on what department, region, etc they are in).  You
> can filter searches on these attributes instead of by using a different
> basedn.  Moving users between departments, regions, etc is simple.
> Also, users can be in multiple departments/regions/whatever, which they
> can't be in if your dit is how you define what groups/regions/whatever
> they are in.
> 
> That's maybe an onversimplification of things and probably leaves a lot
> out, but it's sorta the basic idea.

Jeff,

For 1., 2. and 3. we currently have the setup you described: we use
Courier and FreeRadius schema files.

For 4., we use the attribute 'ou' in each user entry to specify the department.

I am glad that our current OpenLDAP Directory is properly designed to
suit our environment.

I guess I may want to try the virtual views.

Thanks to all for your help.

Regards,
Sam