Bug 805924 - SSSD should attempt to get the RootDSE after binding
SSSD should attempt to get the RootDSE after binding
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd (Show other bugs)
6.3
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Stephen Gallagher
IDM QE LIST
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-22 09:14 EDT by Dmitri Pal
Modified: 2013-05-28 16:41 EDT (History)
4 users (show)

See Also:
Fixed In Version: sssd-1.8.0-23.el6
Doc Type: Bug Fix
Doc Text:
Cause: SSSD relies on some information it can retrieve from the RootDSE in order to determine the capabilities of the server. Some servers do not make the RootDSE available via unencrypted, non-authenticated LDAP bind (in violation of the LDAP standard) Consequence: On such servers, SSSD operates in a slightly degraded mode, being unable to take advantage of any enhanced features of the LDAP server. Change: SSSD will now make a second attempt to retrieve the RootDSE after it completes a successful bind attempt. Result: SSSD is now able to take advantage of enhanced features on servers that do not expose the RootDSE to non-authenticated users.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-20 07:56:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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-22 09:14:52 EDT
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/sssd/ticket/1258

In some situations, a server will disallow retrieving the RootDSE to an anonymous user (or one who is not using a sufficiently high SSF).

In those situations, we should continue as we do currently, binding with reasonable defaults, and then attempt again to retrieve the RootDSE, which may now be available to the properly-bound user.
Comment 3 Amith 2012-05-30 04:45:04 EDT
Verified the bug using sssd-1.8.0-32.el6. 

Tested by disabling anonymous bind in the LDAP server. The DOMAIN section of sssd.conf was configured with default bind values as given below.

[domain/LDAP]
debug_level = 9
id_provider = ldap
ldap_uri = ldap://SERVER
ldap_search_base = dc=example,dc=com
ldap_schema = rfc2307bis
ldap_group_object_class = groupOfNames

ldap_default_bind_dn = <BIND_DN>
ldap_default_authtok = <PASSWORD>

The user lookup was successful.
Comment 4 Stephen Gallagher 2012-06-12 09:50:59 EDT
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: SSSD relies on some information it can retrieve from the RootDSE in order to determine the capabilities of the server. Some servers do not make the RootDSE available via unencrypted, non-authenticated LDAP bind (in violation of the LDAP standard)

Consequence: On such servers, SSSD operates in a slightly degraded mode, being unable to take advantage of any enhanced features of the LDAP server.

Change: SSSD will now make a second attempt to retrieve the RootDSE after it completes a successful bind attempt.

Result: SSSD is now able to take advantage of enhanced features on servers that do not expose the RootDSE to non-authenticated users.
Comment 6 errata-xmlrpc 2012-06-20 07:56:31 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0747.html

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