Claudio Jeker wrote: > Then your new app is broken. A few LDAP attributes have a special meaning > e.g mail, mailalternateaddress, uid, homedirectory (as per rfc ... don't > remember the number).
Not necessarily broken. There could be a requirement of POP3 logins being different from RADIUS logins per se. > In qmail-ldap we used the already defined attributes so it is simpler to > convert from Netscape as example. Where we thought it would be useful we > added new attributes (qmailUID, qmailGID). > > > There's nothing wrong with attributes which contain duplicate values if > > needed, and having the freedom to make them differ. You never know what > > kind of an LDAP-enabled application you could be running in a few > > months/years that will require storing _different_ values than what you > > already have. If an attribute is not from the standard schema, don't use > > it in the custom schema; make your custom object classes auxiliary to > > your standard object classes. This means uid, mail, homedirectory > > shouldn't even be in the qmailUser object class BECAUSE THEY CONFLICT > > WITH EXISTING SCHEMAS. > > > > mail, uid and homedirectory are not defined in the qmail.schema the are > imported from an other schema (core.schema, nis.schema). > AFAIK there is no standard for most mta specific attributes. I found only > some drafts. Also keep in mind that our attributes are named in a > non-ambigous way. mailQuotaSize, qmailDotMode or mailReplyText are quite I think qldapQuotaSize and qldapReplyText are better, however, the naming isn't as important as conflicts. Are we guaranteed there won't be any schemas with the mailQuotaSize attribute for example? What's the likelyhood of qldapQuotaSize popping up any time soon? > clear. The only not perfectly named fields are deliveryMode and > deliveryProgramPath. Better would be mailDeliveryMode and > mailDeliveryProgram. > > > Case in point: an organization has an existing directory service running > > where the uid attribute is populated with values such as "23415734". Uid > > is their naming attribute, and is not used as a username. What are you > > going to do? Exactly what should have been done in the first place: > > design qmail-ldap schema so it doesn't conflict. Convenient? > > > > Broken software as per RFC 1274 and the OpenLDAP core schema: > 9.3.1. Userid All right, so it's a bad example. Regardless, they may use "uid" values which are good for system logins but not POP3 logins, etc. Ever tried to use LDAP authentication with Cisco Secure ACS (the older version)?
