[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Pass-though Authentication with Saslauthd and Kerberos

To: openldap-technical@openldap.org
Subject: Re: Pass-though Authentication with Saslauthd and Kerberos
From: Jeff B <jeffb.list@gmail.com>
Date: Fri, 6 Jan 2012 16:10:38 -0500
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=GF6Q1Y1Z23L8DeML88sIbNhObibkDWP0/bnbBs07wuQ=; b=DII2yhzWaZPUQd4pzkghza3cloBgbRAohLenPb9BZwLCTu5WBlaBuS7gGxAXNCXn2P 94XMjb/2IbshVcKL3CAz6U+gjCcCJWB3S4yxxOmvF11f5RrS4dQV2kY0MwgKAcGnMkcH mJCcPNFX1OGJwoI6cJUlvHb7Mp2Bzme1LrhpM=
In-reply-to: <CANWKOdjgpoSD_pg_6HV3_jN-yM1WB8QHnyVVuXhLBVXrMXd5Ug@mail.gmail.com>
References: <CANWKOdhq6Ykjqz=N7OyT9EhCM_HzrZjDSBPpQBzKGgi9frq5LQ@mail.gmail.com> <CANWKOdjgpoSD_pg_6HV3_jN-yM1WB8QHnyVVuXhLBVXrMXd5Ug@mail.gmail.com>

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.

Now I need to find one of these options to move forward:

- Make BindRequest not lock the row.
- Make the kldap backend not modify the last login data.  or do it
after authenticating the user thus releasing the lock.

Any thoughts?

On Thu, Jan 5, 2012 at 5:33 PM, Jeff B <jeffb.list@gmail.com> wrote:
> I have narrowed this down the problem described below to what I think
> is a lock in the bdb database.
>
> Against the same slapd I have an ldapbind that is waiting from the
> client to complete but kerberos is trying to do an ldapmodify to the
> same slapd before sending the AS-REP back to LDAP Passthough kerberos
> client that will complete the bind.
>
> It seems  that a ldapbind in flight blocks ldapmodify, but not
> ldapsearches. And this configuration requires to complete an
> ldapmodify before it completes the bind.
>
> So how do I get the ldapbind to not block the modify, by using more
> threads, or finer grained locking?  I've done some searching but don't
> see a solution.
>
>
> On Mon, Dec 19, 2011 at 11:08 PM, Jeff B <jeffb.list@gmail.com> wrote:
>> I'm attempting to get pass-though auth to work against saslauthd and
>> kerberos and while the problem seems to be in sasl I think it's most
>> likely to be seen in this type of configuration with opendap which I
>> why I chose this mailing list.
>>
>> When I run testsaslauthd it works but when I run ldapsearch it fails.
>> But the curious thing is where it is failing.  in doing straces of
>> saslauthd and packet traces I've found that when ldapsearch calls
>> salsauthd, and not when I run saslauthd kerberos does not deliver the
>> AS-REP packets till just after saslauthd times out.
>>
>> I can't find any difference in how I'm invoking saslauthd with
>> testdaslauthd and how ldapsearch is invoking saslauthd. However the
>> packet traces are quite different as you will see below.
>>
>> I've seen these kind of errors here and there on google but no
>> resolutions that I can find.
>> (http://www.openldap.org/lists/openldap-software/200602/msg00278.html)
>>
>> Centos 6
>> openldap-2.4.23-15.el6_1.3.x86_64
>> openldap-clients-2.4.23-15.el6_1.3.x86_64
>> openldap-servers-2.4.23-15.el6_1.3.x86_64
>> openldap-devel-2.4.23-15.el6_1.3.x86_64
>> krb5-server-1.9-9.el6_1.2.x86_64
>> krb5-server-ldap-1.9-9.el6_1.2.x86_64
>> krb5-workstation-1.9-9.el6_1.2.x86_64
>> krb5-libs-1.9-9.el6_1.2.x86_64
>> cyrus-sasl-2.1.23-8.el6.x86_64
>> cyrus-sasl-lib-2.1.23-8.el6.x86_64
>> cyrus-sasl-gssapi-2.1.23-8.el6.x86_64
>> cyrus-sasl-plain-2.1.23-8.el6.x86_64
>> cyrus-sasl-devel-2.1.23-8.el6.x86_64
>>
>> My slapd.conf contains nothing regarding kerberos / sasl /
>> pass-through authentication.  I'm using a slapd.conf file for the time
>> being till i get it all worked out and plan on converting it to a
>> cn=config configuration.
>>
>> In my DIT the userPassword field contains:  {SASL}myuser@MYREALM where
>> myuser and my realm are replaced with the proper values.
>>
>> /etc/sasl2/slapd.conf:
>> mech_list: plain
>> pwcheck_method: saslauthd
>> saslauthd_path: /var/run/saslauthd/mux
>>
>> /etc/sysconfig/saslauthd
>> KRB5_KTNAME=/etc/krb5.keytab
>> SOCKETDIR=/var/run/saslauthd
>> MECH=kerberos5
>>
>> Which builds a daemon command line of:
>> /usr/sbin/saslauthd -m /var/run/saslauthd -a kerberos5
>>
>> My system keytab is:
>> /etc/krb5.keytab   (root.ldap 0640)
>> host/my.hostname@realm
>> ldap/my.hostname@realm
>>
>> My socket parent dir is:
>> /var/run/saslauthd  (root.ldap 0770)
>>
>> When I run testsaslauthd I get a packet trace between saslauthd and
>> kerberos is all UDP and works:
>>
>>> AS-REQ
>> < KRB5KDC_ERR_PREAUTH_REQUIRED (25)
>>> AS-REQ
>> < AS-REP
>>> TGS-REQ
>> < TGS-REP
>>
>> When I run ldapsearch the packet trace between saslauthd and kerberos
>> is UDP and TCP communication.  None of the kerberos replies come back
>> for 18 seconds, the time it takes saslauthd to time out.
>>
>>> AS-REQ
>> < KRB5KDC_ERR_PREAUTH_REQUIRED (25)
>>> AS-REQ
>>> TCP SYN
>> < TCP SYN, ACK
>>> TCP ACK
>>> TCP AS-REQ
>> < TCP ACK
>>> AS-REQ
>>> AS-REQ
>>> TCP FIN, ACK   <-- saslauthd times out and the AS-REPS all come back at once.
>> < AS-REP
>> < AS-REP
>> < AS-REP
>> < TCP AS-REP
>>> TCP RST
>>
>> an strace of saslauthd supports this timeout theory as it shows the
>> the timeouts and backoffs.
>>
>> I can't find any info regarding saslauthd and TCP or UDP or timeouts
>> like this.  Any ideas?

Follow-Ups:
- Re: Pass-though Authentication with Saslauthd and Kerberos
  - From: Andreas Ntaflos <daff@pseudoterminal.org>

References:
- Re: Pass-though Authentication with Saslauthd and Kerberos
  - From: Jeff B <jeffb.list@gmail.com>

Prev by Date: RE: Implementing password policy
Next by Date: OpenLDAP 2.4.28 RPMs for CentOS 5 and CentOS 6
Index(es):
- Chronological
- Thread