RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 608688 - SSSD doesn't properly request RootDSE attributes
Summary: SSSD doesn't properly request RootDSE attributes
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Stephen Gallagher
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks: 579775
TreeView+ depends on / blocked
 
Reported: 2010-06-28 13:41 UTC by Stephen Gallagher
Modified: 2015-01-04 23:43 UTC (History)
5 users (show)

Fixed In Version: sssd-1.2.1-19.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-11-10 21:40:03 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Stephen Gallagher 2010-06-28 13:41:29 UTC 
Description of problem:
There are two issues with SSSDs handling of RootDSEs.

1) Not all servers make the RootDSE available before bind. While this is technically a violation of the standard, many deployments do this anyway to reduce attack surface. SSSD must not treat this as an error.

2) SSSD only requests the default attributes from the RootDSE, however different LDAP servers have a different set of default attributes. It is necessary to request the specific attributes that we require.

Version-Release number of selected component (if applicable):
sssd-1.2.1-15.el6

How reproducible:
Every time

Steps to Reproduce:
First issue
1. Set an ACI on the RootDSE preventing access to unbound users
2. Attempt to request user data through the SSSD (getent passwd <username>)
3. Examine debug log (connection to the server was denied because the RootDSE was unavailable)

Second issue:
1. Set up an OpenLDAP server (which does not make the supportedSASLMechanisms attribute available by default - it must be explicitly requested)
2. Attempt to request user data through the SSSD (getent passwd <username>)
3. Examine debug log (connection to the server was denied because the RootDSE was missing the supportedSASLMechanisms option)

Actual results:
No user data is returned.

Expected results:
The system should make resonable assumptions and return the requested data.

Additional info:
Testing of the second issue should be performed both with and without GSSAPI bind.
Comment 3 Gowrishankar Rajaiyan 2010-08-26 14:29:46 UTC 
Verified first issue on sssd-1.2.1-26.el6.

<snip>
(Thu Aug 26 14:59:12 2010) [sssd[be[LDAP]]] [sdap_get_generic_done] (6): Search result: Inappropriate authentication(48), Anonymous access is not allowed.
(Thu Aug 26 14:59:12 2010) [sssd[be[LDAP]]] [sdap_get_generic_done] (2): Unexpected result from ldap: Inappropriate authentication(48), Anonymous access is not allowed.
(Thu Aug 26 14:59:12 2010) [sssd[be[LDAP]]] [sdap_get_rootdse_done] (2): RootDSE could not be retrieved. Please check that anonymous access to RootDSE is allowed
</snip>
Comment 4 Gowrishankar Rajaiyan 2010-08-27 14:53:18 UTC 
First issue:

1. Added the following aci to RHDS:

aci: (target = ldap:///"")(version 3.0; aci "rootDSE deny for anonymous"; deny
(read,search,compare) userdn="ldap:///anyone";)
to deny the complete rootDSE access

2. Attempt to request user data through the SSSD - Success.

3.Snipped from sssd_LDAP.log:
<snip>
(Fri Aug 27 14:35:43 2010) [sssd[be[LDAP]]] [sdap_get_generic_done] (6): Search result: Success(0), (null)
(Fri Aug 27 14:35:43 2010) [sssd[be[LDAP]]] [sdap_get_rootdse_done] (2): RootDSE could not be retrieved. Please check that anonymous access to RootDSE is allowed
(Fri Aug 27 14:35:43 2010) [sssd[be[LDAP]]] [simple_bind_send] (4): Executing simple bind as: (null)
</snip>

Second issue:

With RHDS:
1. Added the following aci to RHDS:

aci: (targetattr != "aci")(version 3.0; aci "rootdse anon read access"; allow(
read,search,compare) userdn="ldap:///anyone";)
aci: (targetattr = "supportedSASLMechanisms")(version 3.0; aci "rootDSE deny f
or anonymous"; deny(read,search,compare) userdn="ldap:///anyone";)

2. Attempt to request user data through the SSSD - Success.

3. Snipped from sssd_LDAP.log:
<snip>
(Fri Aug 27 16:37:42 2010) [sssd[be[LDAP]]] [sdap_get_generic_done] (6): Search result: Success(0), (null)
(Fri Aug 27 16:37:42 2010) [sssd[be[LDAP]]] [sdap_get_rootdse_done] (2): RootDSE could not be retrieved. Please check that anonymous access to RootDSE is allowed
(Fri Aug 27 16:37:42 2010) [sssd[be[LDAP]]] [simple_bind_send] (4): Executing simple bind as: (null)
</snip>

With OpenLDAP:

1. Set up of an OpenLDAP server.
2. Added the following acl's:

access to dn.sub="dc=example,dc=com"
	by anonymous read
	by * read

access to dn.base=""
	by anonymous none
	by * read

3. Attempt to request user data through the SSSD - success.

Case 1: without GSSAPI - users enumerated successfully.

Snippet from sssd_LDAP.log:
<snip>
(Fri Aug 27 20:25:42 2010) [sssd[be[LDAP]]] [sdap_get_generic_done] (6): Search result: Success(0), (null)
(Fri Aug 27 20:25:42 2010) [sssd[be[LDAP]]] [sdap_get_rootdse_done] (2): RootDSE could not be retrieved. Please check that anonymous access to RootDSE is allowed
(Fri Aug 27 20:25:42 2010) [sssd[be[LDAP]]] [simple_bind_send] (4): Executing simple bind as: (null)
</snip>

Case 2: with GSSAPI:

Snippet from sssd_LDAP.log - users enumerated successfully.
<snip>
(Fri Aug 27 20:06:04 2010) [sssd[be[LDAP]]] [sdap_get_rootdse_done] (2): RootDSE could not be retrieved. Please check that anonymous access to RootDSE is allowed
(Fri Aug 27 20:06:04 2010) [sssd[be[LDAP]]] [sdap_kinit_send] (6): Attempting kinit (/opt/ldap.keytab, ldap/gsr64bit-fed12dirsrv.pnq.redhat.com, EXAMPLE.COM, 86400)
</snip>

Verified on sssd-1.2.1-26.el6.
Comment 5 releng-rhel@redhat.com 2010-11-10 21:40:03 UTC 
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.
Note You need to log in before you can comment on or make changes to this bug.