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.
Thank you for your analysis, it is much appreciated. I was having the
exact same problems (modulo some DNS-related fubar) and could not, for
the life of me, figure out why.
Very curiously, running a successful testsaslauthd against the LDAP
service and *then* running ldapwhoami from a client machine works. But
only after that successful testsaslauthd on the server. Restart
saslauthd on the server and the problem reoccurs, until the new
successful testsaslauthd run. O_o
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.
Andreas