On Mon Jan 09 2012 at 19:38:05 CET, Andreas Ntaflos wrote:
On 2012-01-06 22:10, Jeff B wrote:
Upon more reflection It appears to be a row locking problem in BDB. In the example where I found the SASL pass though example their kerberos principal data was not stored in the user's ldap record. and the example where you could store your kerberos principal in the same record as the user wasn't using pass though auth. Combining the two options got me here.
For what it's worth, I can confirm that this problem only occurs whith the kdb5-ldap backend when the Kerberos principal is stored in the same DN as the user, i.e. using
addprinc -x dn="uid=foo,ou=people,dc=example,dc=com" foo
to create the principal. Separating the principal data from the user's DN makes SASL pass-through authentication work again.
I'm running OpenLDAP 2.4.31 in Multi-Master Replication mode with BDB 4.7.25.NC (with 4 patches) and am experiencing the same issue. (Have tried with BDB 5.1.29 which doesn't change anything.) I have one slapd running on Centos 6.2 (2.6.32-220.13.1.el6.x86_64 SMP x86_64) and the other on OS/X 10.6.8. Kerberos is MIT krb5-1.10.1 on both.
If I launch saslsauthd with a KRB5_CONFIG pointing to a second KDC which access a slapd mirror, all works fine.
When both KDC (with kldap back-end) and slapd run on the same machine, and krb5.conf points to that KDC, saslauthd fails if the Kerberos principal objects are in the user's DN:
# /usr/sbin/saslauthd -d -a kerberos5 -m /var/run/openldap
saslauthd[96294] :main : num_procs : 5 saslauthd[96294] :main : mech_option: NULL saslauthd[96294] :main : run_path : /var/run/openldap saslauthd[96294] :main : auth_mech : kerberos5 saslauthd[96294] :ipc_init : using accept lock file: /var/run/openldap/mux.accept saslauthd[96294] :detach_tty : master pid is: 0 saslauthd[96294] :ipc_init : listening on socket: /var/run/openldap/mux saslauthd[96294] :main : using process model saslauthd[96294] :have_baby : forked child: 96295 saslauthd[96294] :have_baby : forked child: 96296 saslauthd[96295] :get_accept_lock : acquired accept lock saslauthd[96294] :have_baby : forked child: 96297 saslauthd[96294] :have_baby : forked child: 96298
saslauthd[96295] :rel_accept_lock : released accept lock saslauthd[96297] :get_accept_lock : acquired accept lock saslauthd[96295] :do_auth : auth failure: [user=jpm] [service=ldap] [realm=MENS.DE] [mech=kerberos5] [reason=saslauthd internal error]
If, on the other hand, the kerberos principal data in LDAP is separate from the user's entry, authentication works:
saslauthd[96298] :rel_accept_lock : released accept lock saslauthd[96294] :get_accept_lock : acquired accept lock saslauthd[96298] :do_auth : auth success: [user=f5] [service=ldap] [realm=MENS.DE] [mech=kerberos5] saslauthd[96298] :do_request : response: OK
Has anybody found a solution? I want to keep Kerberos principal data in the users' entries.
-JP