Hallo! The idea is not peregrine. In fact a couple of directory vendors suggest the same (Novell with "tombstone" and Siemens), even in different ways.
Best regards, Giovanni > -----Ursprüngliche Nachricht----- > Von: Maykel Moya [mailto:[EMAIL PROTECTED] > Gesendet: Sonntag, 30. September 2007 00:30 > An: [EMAIL PROTECTED] > Betreff: [ldap] Re: Tree design review > > > El vie, 28-09-2007 a las 14:22 -0500, Dustin Puryear escribió: > > > 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. > > I had the subjective perception that security will be enhanced with > respect to those deleted accounts if they are outside the normal user > container, say, in case of a typo in a search filter. > > That was the only argument I had for the ou=deleted. I agree with your > and Quannah's points of not having user accounts hanging wherever in > the > DIT. > > The ideal solution would be and ACI expressing 'expose entries having > deleted:true only to admins DNs'. > > > > 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? > > It's a recommendation from Giovanni Baruzzi of having a separate ou for > stuff related to the administration of the directory. > > > > * 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? > > I decided to begin with a simple UID. That schema is compatible with > adding email-like uid in the future if it were necessary. uid field > will > be used only for authentication. > > > > * 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? > > Yes. I mean actually how do you manage having info about overquota > condition at the edge MTAs to avoid innecesary bounces. > > > > * 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? > > Yes. With respect to that I'll follow the approach used in schac > schema. > A multi-value attribute called schacUserStatus and a controlled > vocabulary for values. > > Regards, > maykel > > > > --- > You are currently subscribed to [EMAIL PROTECTED] as: > [EMAIL PROTECTED] > To unsubscribe send email to [EMAIL PROTECTED] with the word > UNSUBSCRIBE as the SUBJECT of the message. > b����.����\��� �&�v�%u�n�'!yۚ��܆+ޙ��j�!����d��{.n�+���zw^�����]j�ު笶��r�����^�PԔ � [EMAIL PROTECTED],j
