Maykel Moya (lists) wrote: > I'm in process to switch our auth and mail stuff to LDAP. Below is a > preliminary DIT design. > > -- > sld.cu > ou=deleted > uid=deleteduser [inetOrgPerson]
But.. why? I wouldn't use topology to encode this kind of information. An alternative would be to use an attribute along with an ACL to exclude a 'deleted/deactivated' record from general searches. > ou=users > uid=moya [inetOrgPerson] > quota: (if not default quota) > hasService: serviceFoo > mailbox: /m/o/y/a/moya (needs custom auxiliary/class) > overquota: false > memberOf: (easy for authz) > mail: [EMAIL PROTECTED] Speaking of your quota attribute, does OpenLDAP support Class of Service yet? I *should* look that up, but.. Plus, I've been using a good bit of non-OpenLDAP software recently. I have to admit, I miss some of the clarity of OpenLDAP configurations. :) > [EMAIL PROTECTED] [inetOrgPerson] > quota (if not default quota) > hasService: serviceFoo > mailbox: /m/o/y/a/[EMAIL PROTECTED] > overquota: true > mail: [EMAIL PROTECTED] > ou=groups > ou=admin > ou=users > uid=moya [inetOrgPerson + posixAccount] > ou=securityGroups > cn=mailAdmins [groupOfUniqueNames + posixGroup] > ou=serviceAccounts > cn=admin [organizationalRole + uidObject + > simpleSecurityObject] Why ou=admin? > ou=org > o=Organization1 > o=Organization2 > o=Organization3 Okay. > ou=app > ou=mail > ou=domains > vd=foo.org [virtualDomain] > nextHop: > ou=aliases > alias: Okay. > * 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], You could use that for the dn, but then you are using something that could conceivably change over time in the dn. Sure, LDAP and related apps should be able to handle change easily, but.. ;) Is there a user ID that will never change? > * 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 > > * Is there any consensus about a layout/schema for handling mail: quota, > aliasing, routing, etc? > > * How do you manage the overquota condition? Do you mean in the mail software? > * The neverending question: 'cn' or 'uid' for people RDN? Up to you. The other trick is to use something seemingly random, or at least not memorable, for dn: cn=X. > * How do you manage the 'locked' status? I'm been thinking in something > like: > dn: ... > objectClass: ... > capability: locked > capability: overquota > capability: hasServiceFoo As in, the account is locked out? -- Puryear Information Technology, LLC Baton Rouge, LA * 225-706-8414 http://www.puryear-it.com Author, "Best Practices for Managing Linux and UNIX Servers" http://www.puryear-it.com/pubs/linux-unix-best-practices Identity Management, LDAP, and Linux Integration --- 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.
