Tony Stevenson schrieb:
Kamil,
Did you try anything I suggested in my last email? Wrapping the CN in "'s, i.e "Tony Stevenson" or in your case "U000001 "
Yes, without success.
Also, why dont you create a group per person, and use the group option, as my other mail suggested. Both of these should work.
Because that is not what I had in mind. If I'd have to have a weirdLDAP structure in order to get this to fly (and I consider creating numerous groups for everyone who actually is in the same ou=DAV (group)
very weird) I wouldn't want to use LDAP.Nevertheless, thanks for all the efforts but I managed to solve the matter after six more hours trial and error myself.
The "problem" was completely elsewhere and no hint in mod_auhnz_ldap's error messages could lead you there: LDAP Access restrictions! My OpenLDAP defaultaccess restriction was set to none and my access rule access to attr="userpassword" by self write by * compareobviously didn't work. As soon as I set defaultaccess to write it worked. No matter how hard I try I can't get THIS out of neither
mod_authnz_ldap's nor openldap's error/debug logs. I went mad as I set the defaultaccess restriction to write and it just worked right away.Well,I just have to dig deeper regarding LDAP access rules in order to get that right because I don't want the defaultaccess to be "write".
If anyone from the ldap list can tell me why this didn't work with the following rules in slapd.conf I would really appreciate it: defaultaccess none access to attr="userpassword" by self write by * compare access to * by self write by dn=".+" read by * none access to * by dn="^$$" none by * read My testing suggested that mod_authnz_ldap needs at least compare access in order to verify the user. READ alone does not work. I thought that my first access rule would permit that. Currently the passwords are stored in cleartext but I really don't consider that productive.Do I just have to set password-hash{MD5}in slapd.conf so that both the password storage is MD5 AND the comparison automatically use MD5 too ?
Well, I tried it anyway but to no avail.I ask because I saw mod_authnz_ldap sending the password to compare in cleartext (tcpdump) to openldap. How does one encrypt the passwords when the comparison string is delivered in cleartext ? Does openldap automatically generate the hash of the submitted cleartext password based on the {MD5} hash descriptor stored in userPassword and THEN compare the hashes (which I would consider the expected behaviour) because I cannot tell mod_authnz_ldap to submit it hashed (well yeah except for rewriting the module), can I ?
Apart from that you're out again openldap-list, thanks. Today I'll try to "backport" my config to the original DAV container config and check if it's working in conjunction with DAV too (currently I don't foresee any reasons why it shouldn't). Also it could have been easily avoided if one of the logs could have made more efforts to tell me that I hit access restrictions which failed my compare. Maybe there will be some time in the future to make verbose REALLY verbose (just my 2cents) Have a nice day, thanks a lot for all suggestions and sorry for cross-posting... Kamil -- Kamil Wencel RADION Imaginery Swakopmunder Str. 1 81827 Munich --------------------------------------------------------- voice office : +49 89 4522058-1 voice mobile : +49 174 3050550 fax-server : +49 89 4522058-9 ---------------------------------------------------------- browser : http://imaginery.radion.org/ --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|