The issue here is that the LDAP server in question has multiple entries for
'namingContexts' in the rootDSE, but does not have a 'defaultNamingContext'
attribute to identify which is the primary.

However, this should only be necessary if there are ldap_*_search_base
attributes that were not populated by the config file. In this particular
user's case, the ldap_search_base option is in use, which should be sufficient.

So the correct fix here is to identify why we're caring about the inability to
identify the default naming context, since we aren't using it for anything.

blockedby: =>
blocking: =>
coverity: =>
patch: => 0
tests: => 0
testsupdated: => 0
upgrade: => 0

Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=784870 (Red Hat Enterprise Linux 6)

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

Fields changed

blocking: => 1155

SSSD 1.7.0 added another option "ldap_sudo_search_base" (which wasn't
supposed to be exposed in the default build, since it's experimental).

This option would normally just inherit its value from the "ldap_search_base" option, but it wasn't specified in this user's config file, whereas all of the others were.

This caused the SSSD to attempt to autodetect it from the namingContexts attribute, but since there were two, it failed.

There are two possible options for how to solve this. One way is to fail at startup with a message about the missing options. The other is with the solution recommended in Ticket #1155

summary: sssd 1.7.0 does not authenticate against ldap/kerberos properly => Setting ldap_*_search_base options should be all-or-nothing at startup

Ok, a third and better option was proposed by Simo on IRC.

Instead of failing if we cannot auto-detect a search base, we will simply disable LDAP lookups for any feature (sudo, services, etc.) for which we do not have a search base set. We'll do this by leaving the {{{ldap_*_search_base}}} as NULL and carefully checking for it at the start of any relevant lookup requests (we'll just return ENOENT and log a warning message at level zero).

blocking: 1155 =>

Making this a blocker. This is going to burn a lot of people on upgrade.

milestone: NEEDS_TRIAGE => SSSD 1.7.91 (1.8.0 beta 1)
owner: somebody => sgallagh
priority: major => blocker
status: new => assigned

Fixed by 169fa5b

feature_milestone: =>
resolution: => fixed
status: assigned => 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/2194

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.