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

[Jeff Clowser <jclowser unitedmessaging com>]

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