Re: Pass-though Authentication with Saslauthd and Kerberos

[Jan-Piet Mens <jpmens.dns@gmail.com>]

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