On Tue, Jul 21, 2009 at 10:50 AM, Emmanuel Lecharny <firstname.lastname@example.org>
I think we can do a little bit simpler.
Alex Karasulu wrote:
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
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.
What about having the current flag (allowAnonymousAccess) which when set to false forbid any access to any entry *except* for rootDSE (ie anonymous search on rootDSE is allowed), plus an ACIItem to control the rootDSE access if really needed ?
Doing so will not change a lot of things in the server, and will leverage the ACI subsystem only if really necessary.
Yeah I guess this is much easier to implement but I see one main issue that will come up when trying to implement this. All ACI are subentries that must subordinate to a administrative point in the administrative area. We really do not have a centrally rooted system with a physical RootDSE where the RootDSE itself can be an administrative point. So we cannot subordinate ACI subentries underneath it in the way we can with the root entries of partitions.
I really wanted to fix this problem by making a special root partition which would allow the RootDSE to act like an administrative point and possibly also hold the system information with the configuration etc. However a few premises have to change in the design to allow this. Not major but it can be done. Then your means to implementing the solution would be trivial.