Fedora directory users - Jun 2005 - Virtual DIT views vs hierarchical DIT

Hi,

I just read about the virtual DIT views in the Red Hat Directory
Server Deployment Guide.

I was wondering how well the virtual DIT views work compare to an
hierarchical DIT structure?

Generally speaking is it better to have a flat DIT and virtual DIT
views than an hierarchical DIT?

Any comments or experience would be much appreciated.

Thanks.
Sam

Sam Tran wrote:
> Hi,
> 
> I just read about the virtual DIT views in the Red Hat Directory
> Server Deployment Guide.
> 
> I was wondering how well the virtual DIT views work compare to an
> hierarchical DIT structure?
> 
> Generally speaking is it better to have a flat DIT and virtual DIT
> views than an hierarchical DIT?
Consider the following scenario:

  - 1 million user accounts
  - 100 user groups
  - 1000 authorization objects
  - 6000 configuration objects
  - 20 internal users for applications


Now, if you put them in seperate branches, then you can scope the 
queries accordingly, and the scoping actually has some effect on search 
response time.

If you put them all in the same branch, e.g. the root, then scoping your 
search to the virtual branches does not help to speed things up at all, 
afaik. Also, you can exceed the lookthrough limits easier, which can 
make things really slow.

The law of directory maintenance is that the deeper the hierarchy, the 
more likely it is to change. Because of this, I like to stay relatively 
flat, not more than 2 levels deep in most cases. However, I still would 
never design a flat DIT because I believe that it takes away flexibility 
of some management applications, mostly third-party. And with third 
party applications, you don''t have the possibility to modify them to be
"view compatible".


Mike

-- 
LDAP Directory Consulting - http://www.netauth.com

On 6/24/05, Mike Jackson <mj@sci.fi> wrote:
> Sam Tran wrote:
> > Hi,
> >
> > I just read about the virtual DIT views in the Red Hat Directory
> > Server Deployment Guide.
> >
> > I was wondering how well the virtual DIT views work compare to an
> > hierarchical DIT structure?
> >
> > Generally speaking is it better to have a flat DIT and virtual DIT
> > views than an hierarchical DIT?
> 
> Consider the following scenario:
> 
>   - 1 million user accounts
>   - 100 user groups
>   - 1000 authorization objects
>   - 6000 configuration objects
>   - 20 internal users for applications
> 
> 
> Now, if you put them in seperate branches, then you can scope the
> queries accordingly, and the scoping actually has some effect on search
> response time.
> 
> If you put them all in the same branch, e.g. the root, then scoping your
> search to the virtual branches does not help to speed things up at all,
> afaik. Also, you can exceed the lookthrough limits easier, which can
> make things really slow.
> 
> The law of directory maintenance is that the deeper the hierarchy, the
> more likely it is to change. Because of this, I like to stay relatively
> flat, not more than 2 levels deep in most cases. However, I still would
> never design a flat DIT because I believe that it takes away flexibility
> of some management applications, mostly third-party. And with third
> party applications, you don''t have the possibility to modify them
to be
> "view compatible".
> 
Mike,

Thanks for your insightful comment.

Any other thoughts, anyone?

Sam

> -----Original Message-----
> From: fedora-directory-users-bounces@redhat.com 
> [mailto:fedora-directory-users-bounces@redhat.com] On Behalf 
> Of Sam Tran
> Sent: Friday, June 24, 2005 11:34 AM
> To: General discussion list for the Fedora Directory server project.
> Subject: [Fedora-directory-users] Virtual DIT views vs 
> hierarchical DIT
> 
> Hi,
> 
> I just read about the virtual DIT views in the Red Hat 
> Directory Server Deployment Guide.
> 
> I was wondering how well the virtual DIT views work compare 
> to an hierarchical DIT structure?
> 
> Generally speaking is it better to have a flat DIT and 
> virtual DIT views than an hierarchical DIT?
> 
> Any comments or experience would be much appreciated.
In general, a flat(ish) DIT means less administrative overhead - if
everything is in one place, there is nowhere to move it to etc.  The issue
with DITs is that there are competing contenders for its structure, some
dictated by applications, some by your deployment topology.  Since your
deployment topology will (and should) win (design your dit around your
replication requirements), views can be used for your other dit structure
requirements.

There are a few issues with views as they currently stand that you should
consider before deployment:

A) they currently have no internet draft or RFC, and to my knowledge no
other server impliments them - only you can tell if this matters

B) they do not work with access control - that is to say, an aci on a views
entry will not target the virtual view descendents, only entries that
actually exist in that part of the dit.  This is an obvious enhancement
waiting to happen ;)  They _do_ work with both cos and roles, so it is
possible to achieve the same functionality using role based aci''s
referring
to roles with views as parents - but that is a bit more ungainly than I
would like

C) they do not work across multiple backends i.e. if a view hiearchy crosses
a backend boundary, searches at the top most views will not return the
entries from the lower views.  Actually this is a bug which is a quirk of
the ordering of view search translation and backend selection, they are the
wrong way around (and if I recall correctly, should be able to be switched
without incident - the calls are even in the same function)

D) Entry DN''s are not disguised, that is views does not try to make the
entry DN of the returned entries look like they physically exist in the view
hiearchy.  It is possible that this might fool some clients that do DN
manipulation - most won''t care however.

Other than that, view look and work like a real DIT and since they work by
manipulating the search options they scale right along with directory
searches.  Setting up indexes for attributes used in views filters will
certainly speed those searches too.

> -----Original Message-----
> From: fedora-directory-users-bounces@redhat.com 
> [mailto:fedora-directory-users-bounces@redhat.com] On Behalf 
> Of Mike Jackson
> Sent: Friday, June 24, 2005 12:10 PM
> To: Sam Tran; General discussion list for the Fedora 
> Directory server project.
> Subject: Re: [Fedora-directory-users] Virtual DIT views vs 
> hierarchical DIT
> 
> Now, if you put them in seperate branches, then you can scope 
> the queries accordingly, and the scoping actually has some 
> effect on search response time.
Yes, I think most people mean this kind of thing when they talk to flat
dits.  We really mean flatish dits verses deep dits.
> 
> If you put them all in the same branch, e.g. the root, then 
> scoping your search to the virtual branches does not help to 
> speed things up at all, afaik. Also, you can exceed the 
> lookthrough limits easier, which can make things really slow.
Actually, I disagree with this.  When you search a view you are not merely
scoping the search, you are (inadvertantly) supplying a fuller search
filter.  If the attributes in the views are indexed, as they probably should
be for important views, the search should be very efficient.  In some cases
it may even make searches that would otherwise be an unindexed search, an
indexed search.
> 
> The law of directory maintenance is that the deeper the 
> hierarchy, the more likely it is to change. Because of this, 
> I like to stay relatively flat, not more than 2 levels deep 
> in most cases.
And that is why views exist :)  Don''t move the entries, move the dit
structure.
> However, I still would never design a flat DIT 
> because I believe that it takes away flexibility of some 
> management applications, mostly third-party. And with third 
> party applications, you don''t have the possibility to modify 
> them to be "view compatible".
Usually you give a third party application a base dn, that base dn can be a
view.  Views were designed such that the client need not know it is using a
view based dit so compatibility isn''t much of an issue for most
clients.

Pete Rowley wrote:
>A) they currently have no internet draft or RFC, and to my knowledge no
>other server impliments them - only you can tell if this matters
>  
>
Yep - if you are looking for portability, stay away from this.
>D) Entry DN''s are not disguised, that is views does not try to make
the
>entry DN of the returned entries look like they physically exist in the view
>hiearchy.  It is possible that this might fool some clients that do DN
>manipulation - most won''t care however.
>  
>
I think this matters most for apps that modify the directory - esp those 
that try to create entries.  If they try to modify it using the virtual 
view, things could get ugly.  FWIW, chaining and/or referrals can run 
into similar issues - if you have one hierarchy and use referrals or 
chaining to split that across servers, you''re generally ok, but if you 
use referrals/chaining to "remap" some branch/tree to some other 
structure or place in the tree (or another tree), you start getting into 
trouble.

I see virtual views as a tool to support "bad" applications that have
a
heavy dependency on finding things under a specific hierarchy that is 
hard coded into the application.  I call these "bad" applications 
because all you need are two that don''t use the same hierarchy, and you
are screwed (unless you have something like virtual views).  It''s a
nice
feature of FDS to support these apps, but personally, I''d stay away
from
writing apps that depend on special views.

 - Jeff

On 6/24/05, Jeff Clowser <jclowser@unitedmessaging.com>
wrote:
> Pete Rowley wrote:
> 
> >A) they currently have no internet draft or RFC, and to my knowledge no
> >other server impliments them - only you can tell if this matters
> >
> >
> Yep - if you are looking for portability, stay away from this.
> 
> >D) Entry DN''s are not disguised, that is views does not try to
make the
> >entry DN of the returned entries look like they physically exist in the
view
> >hiearchy.  It is possible that this might fool some clients that do DN
> >manipulation - most won''t care however.
> >
> >
> I think this matters most for apps that modify the directory - esp those
> that try to create entries.  If they try to modify it using the virtual
> view, things could get ugly.  FWIW, chaining and/or referrals can run
> into similar issues - if you have one hierarchy and use referrals or
> chaining to split that across servers, you''re generally ok, but if
you
> use referrals/chaining to "remap" some branch/tree to some other
> structure or place in the tree (or another tree), you start getting into
> trouble.
> 
> I see virtual views as a tool to support "bad" applications that
have a
> heavy dependency on finding things under a specific hierarchy that is
> hard coded into the application.  I call these "bad" applications
> because all you need are two that don''t use the same hierarchy,
and you
> are screwed (unless you have something like virtual views).  It''s
a nice
> feature of FDS to support these apps, but personally, I''d stay
away from
> writing apps that depend on special views.
> 
Jeff, Pete,

So you would definitely go with hierarchical DIT and not flat DIT with views?

Thanks for you comments.

Sam

> -----Original Message-----
> From: fedora-directory-users-bounces@redhat.com 
> [mailto:fedora-directory-users-bounces@redhat.com] On Behalf 
> Of Jeff Clowser
> Sent: Friday, June 24, 2005 12:35 PM
> To: General discussion list for the Fedora Directory server project.
> Subject: Re: [Fedora-directory-users] Virtual DIT views vs 
> hierarchicalDIT
> 
>  It''s a nice 
> feature of FDS to support these apps, but personally, I''d 
> stay away from writing apps that depend on special views.
Yes, the only apps that should ever care about views are ds administrative
apps.

> -----Original Message-----
> From: fedora-directory-users-bounces@redhat.com 
> [mailto:fedora-directory-users-bounces@redhat.com] On Behalf 
> Of Sam Tran
> Sent: Friday, June 24, 2005 12:40 PM
> To: General discussion list for the Fedora Directory server project.
> Subject: Re: [Fedora-directory-users] Virtual DIT views vs 
> hierarchical DIT
> 
> On 6/24/05, Jeff Clowser <jclowser@unitedmessaging.com> wrote:
> > Pete Rowley wrote:
> > >D) Entry DN''s are not disguised, that is views does not 
> try to make 
> > >the entry DN of the returned entries look like they 
> physically exist 
> > >in the view hiearchy.  It is possible that this might fool some 
> > >clients that do DN manipulation - most won''t care
however.
> > >
> > >
> > I think this matters most for apps that modify the directory - esp 
> > those that try to create entries.  If they try to modify it 
> using the 
> > virtual view, things could get ugly.  FWIW, chaining and/or 
> referrals 
> > can run into similar issues - if you have one hierarchy and use 
> > referrals or chaining to split that across servers, you''re 
> generally 
> > ok, but if you use referrals/chaining to "remap" some 
> branch/tree to 
> > some other structure or place in the tree (or another 
> tree), you start 
> > getting into trouble.
Which sounds like a nice enhancement, redirect non-view entry creation to
some other part of the dit :)  I think it is only the creation case that
really matters - clients that just do modify ops are much more likely to use
the dn of the returned entry than to try to construct one (apps that do that
would be very broken in any case).

> -----Original Message-----
> From: fedora-directory-users-bounces@redhat.com 
> [mailto:fedora-directory-users-bounces@redhat.com] On Behalf 
> Of Sam Tran
> Sent: Friday, June 24, 2005 12:40 PM
> To: General discussion list for the Fedora Directory server project.
> Subject: Re: [Fedora-directory-users] Virtual DIT views vs 
> hierarchical DIT
> 
> Jeff, Pete,
> 
> So you would definitely go with hierarchical DIT and not flat 
> DIT with views?
I will abstain from actually directing you one way or the other since I have
a bias. However, I would be interested in your final decision and the
reasons for it.  I am very interested in reasons to NOT deploy views,
perhaps so that I can contribute to making them go away.

Pete Rowley wrote:
> 
> Usually you give a third party application a base dn, that base dn can be a
> view.  Views were designed such that the client need not know it is using a
> view based dit so compatibility isn''t much of an issue for most
clients.
> 
And when the application needs to create it''s own arbitrarily named sub
branches? I''m talking about applications like Tivoli User Manager, etc.

--
mike

Sam Tran wrote:
> Jeff, Pete,
>
>So you would definitely go with hierarchical DIT and not flat DIT with
views?
>
>Thanks for you comments.
>  
>
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

> -----Original Message-----
> From: fedora-directory-users-bounces@redhat.com 
> [mailto:fedora-directory-users-bounces@redhat.com] On Behalf 
> Of Mike Jackson
> Sent: Friday, June 24, 2005 1:03 PM
> To: General discussion list for the Fedora Directory server project.
> Subject: Re: [Fedora-directory-users] Virtual DIT views vs 
> hierarchical DIT
> 
> Pete Rowley wrote:
> > 
> > Usually you give a third party application a base dn, that 
> base dn can 
> > be a view.  Views were designed such that the client need 
> not know it 
> > is using a view based dit so compatibility isn''t much of an 
> issue for most clients.
> > 
> 
> And when the application needs to create it''s own arbitrarily 
> named sub branches? I''m talking about applications like 
> Tivoli User Manager, etc.
You mean a sub-branch in the view?  That should work without issue.  Do you
have an example where compatibility like this is definitely broken?

Pete Rowley wrote:
> Which sounds like a nice enhancement, redirect non-view entry creation to
>
>some other part of the dit :)  I think it is only the creation case that
>really matters - clients that just do modify ops are much more likely to use
>the dn of the returned entry than to try to construct one (apps that do that
>would be very broken in any case).
>  
>
Well...  Personally, I think administrative apps that create entries 
need to know the "real" DIT.  I''m not sure how safe it would
be to try
to translate a view backwards (is it always safe/easy to translate back 
to the "right" place?)  If you write DN based attributes (owner, 
manager, uniquemember) based on a view instead of the real tree, seems 
like a lot of ugliness can happen.

 - Jeff

On 6/24/05, Jeff Clowser <jclowser@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

Sam Tran wrote:
> I am tempted to go for a DIT that models our organisational chart.
In this case, you definitely want to use views. Org charts change 
frequently.

--
mike

Pete Rowley wrote:
> 
> 
> You mean a sub-branch in the view?  That should work without issue.  Do you
> have an example where compatibility like this is definitely broken?
I haven''t tested it yet. I was just wondering if it''s possible
for an
application which knows nothing about view attributes to create branches 
under a virtual branch. Does the server alter the entry to be added, by 
adding view attributes to it, and storing it under the root, or what?

--
mike

> -----Original Message-----
> From: fedora-directory-users-bounces@redhat.com 
> [mailto:fedora-directory-users-bounces@redhat.com] On Behalf 
> Of Jeff Clowser
> Sent: Friday, June 24, 2005 1:17 PM
> To: General discussion list for the Fedora Directory server project.
> Subject: Re: [Fedora-directory-users] Virtual DIT views vs 
> hierarchicalDIT
> 
> Pete Rowley wrote:
> 
> > Which sounds like a nice enhancement, redirect non-view 
> entry creation 
> > to
> >
> >some other part of the dit :)  I think it is only the creation case 
> >that really matters - clients that just do modify ops are much more 
> >likely to use the dn of the returned entry than to try to 
> construct one 
> >(apps that do that would be very broken in any case).
> >  
> >
> Well...  Personally, I think administrative apps that create 
> entries need to know the "real" DIT.  I''m not sure how
safe
> it would be to try to translate a view backwards (is it 
> always safe/easy to translate back to the "right" place?)  If 
> you write DN based attributes (owner, manager, uniquemember) 
> based on a view instead of the real tree, seems like a lot of 
> ugliness can happen.
It certainly isn''t simple problem and many cases need to be factored
in.
Though much of this can be simplified by observing or predicting what
clients really do as opposed to what they might do.  Taking your example, it
is possible that an application might be fooled if it first creates an entry
in a view and then immediately uses the (view based) dn to populate
attributes in other entries.  Probably the more typical case is to retrieve
an existing entry from a view and then use the dn of that to populate the
attributes of other entries, which should just work (assuming we have the
currently absent create support).

It _should_ be relatively simple for the server to translate back and forth
between DN''s (the translation is always one way, from view based to
target),
so it would be possible even to correct for attribute values, but I have my
doubts about performance for such things - certainly for returned search
results anyway.  So, having said this, I am not convinced it is a good thing
to try either.

On the real dit versus view based: if a view based dit works and acts
exactly the same way (assuming no issues) as a real dit, does it really
matter whether the admin client knows about it?  After all, the "real"
dit
isn''t real either, it''s really a "view" of what we
store in the db.

> -----Original Message-----
> From: fedora-directory-users-bounces@redhat.com 
> [mailto:fedora-directory-users-bounces@redhat.com] On Behalf 
> Of Mike Jackson
> Sent: Friday, June 24, 2005 1:38 PM
> To: General discussion list for the Fedora Directory server project.
> Subject: Re: [Fedora-directory-users] Virtual DIT views vs 
> hierarchical DIT
> 
> Pete Rowley wrote:
> > 
> > 
> > You mean a sub-branch in the view?  That should work 
> without issue.  
> > Do you have an example where compatibility like this is 
> definitely broken?
> 
> I haven''t tested it yet. I was just wondering if it''s 
> possible for an application which knows nothing about view 
> attributes to create branches under a virtual branch. Does 
> the server alter the entry to be added, by adding view 
> attributes to it, and storing it under the root, or what?
Views are a search based thing currently, so nothing happens to the entry
when it is created, or afterwards - mods and adds work on the hierarchy
itself and the entries end up where you actually put them.  Views constructs
its filter such that entries that actually exist in the view hiearchy are
returned by searches along with the views based results.  I had never
thought of this before, but this is actually a nice way to contain apps like
this that litter the dit.

So, in theory, the client should be none the wiser.  If you ever do come
across an incompatibility like this, I would really like to hear about it.

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

On 6/24/05, Jeff Clowser <jclowser@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

> -----Original Message-----
> From: fedora-directory-users-bounces@redhat.com 
> [mailto:fedora-directory-users-bounces@redhat.com] On Behalf 
> Of Sam Tran
> Sent: Sunday, June 26, 2005 9:35 AM
> To: Jeff Clowser
> Cc: General discussion list for the Fedora Directory server project.
> Subject: Re: [Fedora-directory-users] Virtual DIT views vs 
> hierarchical DIT
> 
> 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.
>From the sound of it, it will be easy for you to create organizational views
from your existing entry data - the ou attribute can be used by views for
that.