Hide Forgot
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..."
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development. This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.
Upstream ticket is targeting 1.13, reproposing for 7.2
Thank you taking your time and submitting this request for Red Hat Enterprise Linux. Unfortunately, this bug was not given a priority and was deferred both in the upstream project and in Red Hat Enterprise Linux. Given that we are unable to fulfill this request in following Red Hat Enterprise Linux releases, I am closing the Bugzilla as DEFERRED. To request that Red Hat re-considers the decision, please re-open the Bugzilla via appropriate support channels and provide additional business and/or technical details about its importance to you. Note that you can still track this request or even contribute patches in the referred upstream Trac ticket.