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
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
