#1152 Setting ldap_*_search_base options should be all-or-nothing at startup

Created 5 years ago by sgallagh
Modified a month ago

https://bugzilla.redhat.com/show_bug.cgi?id=773706 (Fedora)

Description of problem:

With sssd-1.7.0-1.fc16.i686 I'm getting expired kerberos tickets on login.

It appears to not setup the ldap server properly.

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

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 169fa5bd3edd34aa0db35681832bd7406e423c1b

feature_milestone: =>
resolution: => fixed
status: assigned => closed

a month ago

Metadata Update from @sgallagh:
- Issue assigned to sgallagh
- Issue set to the milestone: SSSD 1.8 beta

Login to comment on this ticket.

defect

LDAP Provider

1.7.0

0

0

https://bugzilla.redhat.com/show_bug.cgi?id=773706, https://bugzilla.redhat.com/show_bug.cgi?id=784870

cancel