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
