Bug 608688 - SSSD doesn't properly request RootDSE attributes
SSSD doesn't properly request RootDSE attributes
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: Stephen Gallagher
Chandrasekar Kannan
:
Depends On:
Blocks: 579775
  Show dependency treegraph
 
Reported: 2010-06-28 09:41 EDT by Stephen Gallagher
Modified: 2015-01-04 18:43 EST (History)
5 users (show)

See Also:
Fixed In Version: sssd-1.2.1-19.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-10 16:40:03 EST
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 Stephen Gallagher 2010-06-28 09:41:29 EDT
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 10:29:46 EDT
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 10:53:18 EDT
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, EXAMPLE.COM, 86400)
</snip>

Verified on sssd-1.2.1-26.el6.
Comment 5 releng-rhel@redhat.com 2010-11-10 16:40:03 EST
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.