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
