On 09.01.2012 19:38, 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.
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
Yes thanks!, that's also my problem I wrote one/two months ago...
Is this a known bug or is there no other way to fix it?