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.

(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.

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?

(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.

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.

Based on Comment#8 moved to verified

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.

Closing.