The first part of this is actually Bug #1269, so we'll track that there.

For the second part (about the rebinds), there are two pieces that we should look into. My first assumption was that we were dealing with a referral-on-bind, which can't be handled by the openldap client library's built-in referral tracking. For this, we should ensure that we disable that option during the bind process.

However, I saw a similar behavior with another user today, where it appeared that what was actually happening was that searches against the specified LDAP server were working just fine with the primary server (the one specified by {{{ldap_uri = <server>}}} but when searches were following AD's internal referral chasing, the rebind on the new connection was failing with the Kerberos error "server not found in kerberos database".

It's unclear at the moment whether our {{{sdap_rebind_proc()}}} is broken or there's something strange about the way AD handles binds to the global catalog. We will look into it.

description: 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
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..." => 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
}}}
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..."

For the record, the recommended workaround at the moment is to set {{{ldap_referrals = false}}} in sssd.conf, which will disable referral chasing (and provide a sizeable performance boost in the process).

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.9.0

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=808059

rhbz: => [https://bugzilla.redhat.com/show_bug.cgi?id=808059 808059]

Fields changed

milestone: SSSD 1.9.0 => SSSD 1.9.1

Fields changed

milestone: SSSD 1.9.1 => SSSD 1.9.2

Fields changed

milestone: SSSD 1.9.2 => SSSD 1.10 beta

Fields changed

selected: => Not need

Moving tickets that are not a priority for SSSD 1.10 into the next release.

milestone: SSSD 1.10 beta => SSSD 1.11 beta

Fields changed

mark: => 0

Looks like this ticket predates the AD provider, I think we should just close it and let the reporter reopen if it's still an issue.

changelog: =>
design: =>
design_review: => 0
fedora_test_page: =>
milestone: SSSD 1.13 beta => SSSD 1.13 backlog
priority: minor => trivial
review: => 0

Mass-moving tickets not planned for any immediate release and re-setting priority.

milestone: SSSD 1.13 backlog => SSSD Deferred
priority: trivial => major

Looks like this ticket predates the AD provider, I think we should just close it and let the reporter reopen if it's still an issue.

review: 0 => 1
sensitive: => 0

Fields changed

resolution: => worksforme
status: new => closed

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2319

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.