Bug 808059 - [RFE] Authetication to AD using SASL with LDAP
[RFE] Authetication to AD using SASL with LDAP
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd (Show other bugs)
Unspecified Unspecified
medium Severity unspecified
: rc
: ---
Assigned To: SSSD Maintainers
Kaushik Banerjee
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2012-03-29 09:09 EDT by Dmitri Pal
Modified: 2015-04-24 07:22 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-04-24 07:22:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dmitri Pal 2012-03-29 09:09:50 EDT
This bug is created as a clone of upstream ticket:

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@REALM.NAME
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..."
Comment 1 RHEL Product and Program Management 2012-07-10 02:13:12 EDT
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.
Comment 2 RHEL Product and Program Management 2012-07-10 22:05:15 EDT
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.
Comment 5 Jakub Hrozek 2014-07-02 09:03:57 EDT
Upstream ticket is targeting 1.13, reproposing for 7.2
Comment 6 Martin Kosek 2015-04-24 07:22:56 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.