Just some history. When we went from using JNDI interfaces in the core to using our own well defined interfaces many things were a mess including this area. At one point I revamped this area of the code cleaning up a lot of the configuration which was still trying to use Properties a la the old JNDI way.
I remember paying close attention to allow search operations to occur without a previous bind on the RootDSE regardless of whether or not anonymous binds were enabled or not. This was done specifically to allow for client's to discover the various ways they could bind to the directory by reading the RootDSE's contents.
I've always thought the RootDSE was something that should be world readable but I may be wrong now with better clarification in the latest RFC revamp. Plus life has been hard and I cannot say I've been on top of these matters as I should.
It might be best to consolidate the behavior of anonymous access to the server into a single configuration parameter which is an enumerated type with the following values. Let's call it anonymousAccess:
o ANY - anonymous access to ANY entry is allowed
o ROOTDSE - anonymous access is only allowed on the RootDSE
o NONE - anonymous access is NOT allowed on any entry
All these modes are still subject to any ACI restrictions that may additionally be configured by administrators. This parameter only governs at a high level which operations the network protocol layer will allow to occur on entries. Of course the lower layers also need to adhere to this policy if for example calls are made directly to the core interfaces via embedded server configurations where the API is used.
On Tue, Jul 21, 2009 at 4:24 AM, Emmanuel Lecharny <firstname.lastname@example.org>
Stefan, all what we need is a way to send a SearchRequest targetting the RootDSE without a previous Bindrequest. Not sure that JNDI alllows such operation.
Stefan Zoerner wrote:
Quanah Gibson-Mount wrote:
--On Monday, July 20, 2009 9:50 PM -0400 Alex Karasulu <email@example.com> wrote:
Ahhh okie you're right on. My bad.
This is quite correct. There are even some (stupid) security programs that will say being able to read the rootDSE is a vulnerability. OTOH, I've always left it read to the world, most clients prefer it. :P
There are also tests within the Open Group LDAP certification suite which check whether the Root DSE is readable anonymously. But it is OK, if we are able to configure a server to behave like that for a test run. No need to make that the default.
As soon as we can read rootDSE without being bound, then we are golden, as the way we protect the rest of the entries is different.
Also, the RFC states that the rootDSE *may* be protected, which does not mean it should be. And I think, as Quanah, that it does not make a lot of sense to protect it, unless you want to get numerous mails on the users mailing list about the unavailable rootDSE ;)
Thanks Stefan !
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org