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 weird
LDAP 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 * compare
obviously 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: [EMAIL PROTECTED]
" from the digest: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
