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
Attachment:
signature.asc
Description: OpenPGP digital signature