Thomas -Balu- Walter writes: > > Ok - I agree with you here, I have to admit that I didn't think that > far. My setup is going to be an LDAP-Server on it's own where only > qmail-ldap is going to get access to. But you'll never now - if someday > it has to be extended I might have done something very bad.
Here's an example: initially our LDAP DB was just serving qmail-ldap and sqwebmail, but now it's serving the Cisco ACS RADIUS server. The server is an awful implementation as far as LDAP authentication is concerned. It can't rewrite User-Name RADIUS attribute depending on realm, it can't set its base DN for searches based on a realm, and the only way it can authenticate is to bind to the directory with the following scheme "naming_attr=$User-Name,ou=someorg,dc=example,dc=com". If the bind succeeds, the remote user is authenticated. "uid" is very often used as the naming attribute, so automatically you can't authenticate those users whose RDNs are not in the format the server expects if the "uid" was used as the naming attribute. If the user submits "username@realm" to the dial-up client, then the server has to bind with "uid=username@realm,ou=someorg,dc=example,dc=com" if the uid was chosen as the naming attribute for the initial design of the directory. Other services very often use "uid", and want it to contain a different value than that used by qmail-ldap, so that's another clash. Choose a specific attribute instead. If you can't modify those services, you'll have to modify the directory, and you don't want to do that.
