Bug 808059

This bug is created as a clone of upstream ticket:
https://fedorahosted.org/sssd/ticket/1277

I wish to use SASL as the authentication to the AD KDC.  I add the computer account to the domain and test it as described with
{{{
kinit -k -t /etc/krb5.keytab host/myhostname.domain.name
}}}
then
{{{
ldapsearch -h ad.kdc -b "dc=domainpart1,dc=domainpart2,dc=domainpart3" -Y GSSAPI cn=someuser
}}}
and that all works fine.

When I use this setup within sssd there are a two main issues.

Firstly the logs tell me that the principal is not found in the KDC database.  But when I inspect it using ADSI Edit I see the SPN and UPN values that I expect to see and that match the principal it says it cannot find.  Likewise these principals can be seen from klist -kte /etc/krb5/keytab  (though it doesn't complain about not finding anything in the key tab)

I can get round that issue temporarily by specifying the principal name using ldap_sasl_authid.  I'd still like to know what is wrong in that instance.


Secondly the ldap_search_base strangely affects the authentication and the user lookup.  I don't know if the searching is subtree or not.  I can't see a parameter to make this explicit.

If I set ldap_search_base (or ldap_user_search_base)  to dc=domainpart1,dc=domainpart2,dc=domainpart3  then I get errors about ldap_sasl_interactive_bind_s failing.
however if I set the ldap_search_base to cn=users,dc=domainpart1,dc=domainpart2,dc=domainpart3  then those errors go away and the lookup is done.

The problem is that the users do not live in cn=users,dc=domainpart1,dc=domainpart2,dc=domainpart3  they are in an OU elsewhere.  They can be found via a subtree search (as per the ldapsearch example above) if the search base is set to higher up the tree at just the domain components specification.

But if I set the search base that way, then the sasl bind fails.

Suggested by the SSD project devs to set debug_level= 6 in the domain section and relevant log entries are apparently:
{{{
(Thu Mar 22 09:05:54 2012) [sssd[be[my.fqdn.domain]]] [sdap_rebind_proc]
(1): ldap_sasl_interactive_bind_s failed (-2)[Local error]
(Thu Mar 22 09:05:54 2012) [sssd[be[my.fqdn.domain]]] [sdap_rebind_proc]
(1): ldap_sasl_interactive_bind_s failed (-2)[Local error]
(Thu Mar 22 09:05:54 2012) [sssd[be[my.fqdn.domain]]] [sdap_rebind_proc]
(1): ldap_sasl_interactive_bind_s failed (-2)[Local error]
(Thu Mar 22 09:06:00 2012) [sssd[be[my.fqdn.domain]]] [sdap_id_op_done]
(5): communication error on cached connection, moving to next server
}}}
Mailing list commentary reports this is when Active Directory is responding to the LDAP BIND
request with a referral, which is unsupported by the openldap client
libraries, and therefore by [us] as well.
and :

"It's probably a bug in our code for us to be attempting to track
referrals during a bind. Would you please open a bug on this..."