Hi all,
I'm in my final steps with my testing server using rc23 in a x86 RHEL4 machine.
Everything is working quite well, but still are some LDAP related issues I'd like to clarify:
I'm using auth_bind and auth_bind_userdn. So pass_filter isn't used, and pass_attrs are never searched. Is this true or am I missing something?
Is there a choice for the userdb bind/queries to be done using the user supplied dn -the one used for passdb-? I would like to access some non-public attributes, but I've had no luck until now. If I use the same dovecot-ldap.conf for userdb and passdb, i have a single connection to the LDAP server, but once the auth bind is successful, an anonymous bind occurs. If I use two separate files for userdb and passdb, i have two connections to the LDAP server, the second one being always anonimous.
For me, the perfect state would be:
- bind using the user supplied dn
- if successfull, search for pass_attrs, where some user_attrs may be prefetched
- unbind
- userdb only binds if some needed attrs haven't been already fetched. If so, there's a choice to use the user supplied dn for the bind/search.
Is this possible now? Would it be in the future?
Thanks in advance.
Joseba Torre. CIDIR Bizkaia.
On Thu, 2007-02-22 at 12:19 +0100, Joseba Torre wrote:
That's true.
What if you just didn't use auth_bind_userdn, put all the attributes in pass_attrs and use userdb prefetch?
I think that should work as long as you're not using deliver, which requires userdb-only query (but then if you don't need the private fields use userdb prefetch and userdb ldap).
El Jueves, 22 de Febrero de 2007 13:02, Timo Sirainen escribió:
The ldap log is:
fd=18 ACCEPT from IP=10.0.2.22:38185 (IP=0.0.0.0:636) op=0 BIND dn="" method=128 op=0 RESULT tag=97 err=0 text= op=1 SRCH base="ou=People,dc=example,dc=com" scope=2 deref=0 filter="(uid=testuid)" op=1 SRCH attr=uid homeDirectory uidNumber gidNumber op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
So the ldap_attrs search is being doing anonimously -and it's the only way it makes sense-, so i'm back in the same problem.
op=2 BIND dn="uid=testuid,ou=people,dc=example,dc=com" method=128 op=2 BIND dn="uid=testuid,ou=people,dc=example,dc=com" mech=SIMPLE ssf=0 op=2 RESULT tag=97 err=0 text= deferring operation: binding
This is the auth bind
op=3 BIND anonymous mech=implicit ssf=0 op=3 BIND dn="" method=128 op=3 RESULT tag=97 err=0 text= op=4 SRCH base="ou=People,dc=ehu,dc=es" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=testuid))" op=4 SRCH attr=uid homeDirectory uidNumber gidNumber op=4 SEARCH RESULT tag=101 err=0 nentries=1 text=
So, even if the uid, gid and homeDirectory are being prefetched (my pass_attrs value is
pass_attrs = uid=user,userPassword=password,homeDirectory=userdb_home,uidNumber=userdb_uid,gidNumber=userdb_gid
and the line
op=1 SRCH attr=uid homeDirectory uidNumber gidNumber
in the begging of the log shows that they were )
they are being searched again?
I wanted to avoid creating a new dn for dovecot to use, but I also want to use deliver in the near future. I didn't thought about it before, but it's obvious that with my config deliver will need, at least, access to homeDirectory, uidNumber and gidNumber. So I'll create the dedicated dn and this problem will be gone.
Thanks again.
Joseba Torre. CIDIR Bizkaia.
On Thu, 2007-02-22 at 16:50 +0100, Joseba Torre wrote:
Oh, right. Making it work would require changing the LDAP code to do the user_query immediately after the LDAP bind. Also it'd practically mean then that there can always be only a single LDAP query going on.
Wonder if I should add support for multiple LDAP connections to the server, so if one connection is in a blocking wait state, another one could be used. Maybe for v2.0.
So I'll create the dedicated dn and this problem will be gone.
Ok :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 22 Feb 2007, Joseba Torre wrote:
Do you make these three attributes private? PAM will require an AdminDN, too, right?
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBRd6Tfy9SORjhbDpvAQJM0wf+Iy5pZajm5zDPmPNwXJP245zbNJ3r89HK Vw1H4AWXRQNJDiY4OQXATEHfHwDG+fKNPGFjWQZJHtfuuTwaL2pqeYFAXb8Po1N3 TbRVNh3koGpzpJta2Ogna2krPb5A68b/9aH7JkMjJYYhDcGC+3wd6mnuJFbOTW65 lYHSBDmGEJhASgLb9MXoUyWOguTqoehKQPbkD39kWodWwEB3zO3230RdhbQ4NMxD k127Yddun7Q/zXW5jMBgHelkePLgYHOnhXm0W3Nea0lzTREpI8Qu7TBpXSW3w90L so7Ub4qWl69FmVh81V0+WesWB5KGGiXEYcf/3XU5hNEoaZXYp6N5EA== =8UQR -----END PGP SIGNATURE-----
participants (3)
-
Joseba Torre
-
Steffen Kaiser
-
Timo Sirainen