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]
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]
[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]
ou=org
o=Organization1
o=Organization2
o=Organization3
ou=app
ou=mail
ou=domains
vd=foo.org [virtualDomain]
nextHop:
ou=aliases
alias:
--
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.
[ inet ] -> [ MX ] -> [ storage ]
\
\---> [ remote SMTP ]
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],
* 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?
* 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
Besides, any other criticism is more than welcome.
Regards,
maykel
---
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.
