Bug 813942

Summary: Documentation for disabling anonymous access should allow RootDSE access
Product: Red Hat Enterprise Linux 6 Reporter: Stephen Gallagher <sgallagh>
Component: doc-Identity_Management_GuideAssignee: Deon Ballard <dlackey>
Status: CLOSED CURRENTRELEASE QA Contact: ecs-bugs
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.3CC: dpal, jskeoch, sigbjorn
Target Milestone: rcKeywords: Documentation
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-21 23:12:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Stephen Gallagher 2012-04-18 19:59:30 UTC
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 21:45:24 UTC
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 22:05:10 UTC
(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 22:14:20 UTC
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 22:57:54 UTC
(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 16:22:34 UTC
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-24 02:22:07 UTC
Based on Comment#8 moved to verified

Comment 11 Sigbjorn Lie 2012-06-10 19:32:33 UTC
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 23:12:39 UTC
Closing.