Ticket #1152 (closed defect: fixed)

Opened 5 years ago

Last modified 5 years ago

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

Reported by: sgallagh Owned by: sgallagh
Priority: blocker Milestone: SSSD 1.8 beta
Component: LDAP Provider Version: 1.7.0
Keywords: Cc:
Blocked By: Blocking:
Sensitive: Tests Updated: no
Coverity Bug: Patch Submitted: no
Red Hat Bugzilla: 773706, 784870 Design link:
Feature Milestone:
Design review: Fedora test page:
Chosen: Candidate to push out:
Release Notes:
Temp mark:


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.

Change History

comment:1 Changed 5 years ago by sgallagh

  • tests set to 0
  • upgrade set to 0
  • Tests Updated unset
  • Patch Submitted unset

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.

comment:2 Changed 5 years ago by dpal

  • Red Hat Bugzilla changed from [https://bugzilla.redhat.com/show_bug.cgi?id=773706 773706] to [https://bugzilla.redhat.com/show_bug.cgi?id=773706 773706], [https://bugzilla.redhat.com/show_bug.cgi?id=784870 784870]

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

comment:3 Changed 5 years ago by sgallagh

  • Blocking set to 1155

comment:4 Changed 5 years ago by sgallagh

  • Summary changed from sssd 1.7.0 does not authenticate against ldap/kerberos properly to Setting ldap_*_search_base options should be all-or-nothing at startup

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

comment:5 Changed 5 years ago by sgallagh

  • Blocking 1155 deleted

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).

comment:6 Changed 5 years ago by sgallagh

  • Owner changed from somebody to sgallagh
  • Priority changed from major to blocker
  • Status changed from new to assigned
  • Milestone changed from NEEDS_TRIAGE to SSSD 1.7.91 (1.8.0 beta 1)

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

comment:7 Changed 5 years ago by sgallagh

  • Status changed from assigned to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.