Bug 813942 - Documentation for disabling anonymous access should allow RootDSE access
Documentation for disabling anonymous access should allow RootDSE access
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: doc-Identity_Management_Guide (Show other bugs)
6.3
Unspecified Linux
unspecified Severity medium
: rc
: ---
Assigned To: Deon Ballard
ecs-bugs
: Documentation
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-18 15:59 EDT by Stephen Gallagher
Modified: 2012-06-21 19:12 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-21 19:12:39 EDT
Type: Bug
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 2012-04-18 15:59:30 EDT
Description of problem:
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/disabling-anon-binds.html 

Version-Release number of selected component (if applicable):
2.1.4


The documentation should be changed from
nsslapd-allow-anonymous-access: off
to
nsslapd-allow-anonymous-access: rootdse


and should be updated to explain that the meaning of this option is that anonymous users will have access to the rootdse (for reading the capabilities of the server for clients). Aside from the rootdse, anonymous users will be unable to read any part of the server's data.

This is much preferred to the current recommendation to disable all anonymous access, as there are many clients (SSSD included) that behave better (or in some cases, "at all") with access to the rootdse.

There is no known security exposure inherent in allowing RootDSE access.
Comment 2 Dmitri Pal 2012-04-18 17:45:24 EDT
It is probably worth noting that with the latest planned fix for SSSD the SSSD will read rootDSE after bind to get the information about server capabilities however other clients might have difficulties using IPA in an efficient way.

My point is that this not is probably not needed if the client is 6.3 SSSD.
Comment 3 Stephen Gallagher 2012-04-18 18:05:10 EDT
(In reply to comment #2)
> It is probably worth noting that with the latest planned fix for SSSD the SSSD
> will read rootDSE after bind to get the information about server capabilities
> however other clients might have difficulties using IPA in an efficient way.
> 
> My point is that this not is probably not needed if the client is 6.3 SSSD.

This is incorrect. SSSD is not the only client of IPA. This will have implications on ANY LDAP client (not just those used for system logins). Anyone attempting to use IPA as the identity store for applications (such as web apps) may have issues with this. The availability of the RootDSE is required by the LDAP specification as it may be the only way that a client can learn what settings are available to negotiate a connection (for example, supportedSASLMechanisms).

We are going to work around this issue in SSSD partially because of the FreeIPA issue but also to avoid issues with other directory servers that do not behave properly with the RootDSE.

It is still strongly recommended that we change this document as described above. There is no downside to this change and a great deal of upside.
Comment 4 Dmitri Pal 2012-04-18 18:14:20 EDT
Please read my comment more closely. I said exactly what you said. For no SSSD clients this is needed however for SSSD 6.3 it would not be needed since the SSSD would work it around. Where do you see incorrectness?
Comment 5 Stephen Gallagher 2012-04-18 18:57:54 EDT
(In reply to comment #2)
> My point is that this not is probably not needed if the client is 6.3 SSSD.

This is the part of your statement I was disagreeing with. There will probably *never* be a situation where 100% of IPA's clients will be SSSD for the entire life of the deployment. Failing to set this properly will inevitably lead to hard-to-identify issues with other software down the line. So my view is that we need to encourage people to set this correctly right from the start.

It may be that we agree and it's just the phrasing that's tripping us up. I just want to be clear here, so that we don't confuse the issue when editing the documentation.
Comment 6 Dmitri Pal 2012-04-19 12:22:34 EDT
Yes I mean if ALL your clients are SSSD 6.3 or later you do not need it. But you might need it (or might not need it) for the third partly LDAP client as you do not know whether it looks at rootDSE or not if would work incorrectly or not optimally if the rootDSE is inaccessible.

So the do note should say you need this setting with old SSSD and clients that try to access rootDSE. If your environment consists entirely of the clients that do not need access to the rootDSE before bind or with SSSD 6.3 or later you do not need this setting.

Hope it is clear now.
Comment 9 John Skeoch 2012-04-23 22:22:07 EDT
Based on Comment#8 moved to verified
Comment 11 Sigbjorn Lie 2012-06-10 15:32:33 EDT
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6-Beta/html/Identity_Management_Guide/disabling-anon-binds.html

Is step 2 (Restart the directory server) required? 

This change has taken immedieate effect when I have changed the nsslapd-allow-anonymous-access setting using an LDAP editor.
Comment 12 Deon Ballard 2012-06-21 19:12:39 EDT
Closing.

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