I just don't think topology should be used to define that kind of information, but that's just me. :)
-- 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 Giovanni Baruzzi wrote: > 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��r����칻 �&ޱ��zf���%u�kz���ۦ��^v�"�a{ > [EMAIL PROTECTED] --- 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.
