> process to switch our auth and mail stuff to LDAP. Below is a > preliminary DIT design. > We manage MXs for the sld.cu domain. Below sld.cu we have some domains > for which we also manage the mailboxes, and other domains we are only > relays for. > only [ MX ] and [ storage ] are managed by us. > The proposed layout is mainly based on remanks from a presentation about > tree design at LDAPCon2007. Nevertheless I have a lot of doubts: > * What about ou=sync? > Not reflected in this design but in the slides. The guy proposed > something like > ou=users > ou=sync > uid=foo > * What do you think about having an email like uid? > I'm very tempted to have [EMAIL PROTECTED],dc=users... mainly by > two things: > 1. Increasing adoption of services who uses email-like > id (jabber, sip) > 2. Makes easier to merge users from other domains, would be trivial > to merge a [EMAIL PROTECTED],
This seems allot to depend upon your user base and the kind of services user's use. Obviously this would be very awkward for NSS, Samba, etc... but if all your services are 'Internet services' then I don't see why it wouldn't work. > * The searchs 'give me all Organization3 members' or 'what organization > belongs uid=moya,... could be implemented via the 'o' of 'inetOrgPerson' > but it isn't a DN match attribute Yep, we just use "o" to match users to an organization. Works well enough. > * Is there any consensus about a layout/schema for handling mail: quota, > aliasing, routing, etc? Nope. We just have a "Subsystems" ou that contains a subtree for all each specific service that stores LDAP configuration/etc... Like "Mail", "XMPP", DNS", etc... For users we have ou=SAM,.... ou=Groups,ou=SAM,... ou=Entities,ou=SAM,... ou=People,ou=Entities,ou=SAM,... ou=System Accounts,ou=Entities,ou=SAM,... Has worked well for aiming services at just what they need to see, but what works for you depends in large part on what you need to do. > * How do you manage the overquota condition? That is the responsibility of the service and doesn't have much to do with LDAP. I don't see that as data so much as state, there is no reason to store it, the service knows if a uid is overquota or not. > * The neverending question: 'cn' or 'uid' for people RDN? > * How do you manage the 'locked' status? I'm been thinking in something > like: > dn: ... > objectClass: ... > capability: locked > capability: overquota > capability: hasServiceFoo > that would simplify the schema We have defined an attribute that simply stores active user state - Y/N. Every service so far can be configured with a filter to use when finding users, so inactive users just get filtered out and 'disappear'. You can doubly hide them with an ACL. > Besides, any other criticism is more than welcome. -- Adam Tauno Williams, Network & Systems Administrator Consultant - http://www.whitemiceconsulting.com Developer - http://www.opengroupware.org --- You are currently subscribed to ldap@umich.edu as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message.
