Bug 805924

Summary:	SSSD should attempt to get the RootDSE after binding
Product:	Red Hat Enterprise Linux 6	Reporter:	Dmitri Pal <dpal>
Component:	sssd	Assignee:	Stephen Gallagher <sgallagh>
Status:	CLOSED ERRATA	QA Contact:	IDM QE LIST <seceng-idm-qe-list>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.3	CC:	apeetham, grajaiya, jgalipea, prc
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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 11:56:31 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Dmitri Pal 2012-03-22 13:14:52 UTC

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 08:45:04 UTC

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 13:50:59 UTC

    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 11:56:31 UTC

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