On Tue, Jul 21, 2009 at 11:24 AM, Emmanuel Lecharny <email@example.com>
Right now, I would suggest we simply allow anonymous search on the rootDSE. It's easy to do, we just have to fix the tests which are broken. The core code won't be changed a lot (just a test in a method to remove).
Alex Karasulu wrote:
On Tue, Jul 21, 2009 at 10:50 AM, Emmanuel Lecharny <firstname.lastname@example.org>wrote:
Alex Karasulu wrote:
Yeah I guess this is much easier to implement but I see one main issue that
Just some history. When we went from using JNDI interfaces in the core to
I think we can do a little bit simpler.
using our own well defined interfaces many things were a mess including
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
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
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
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.
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
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.
When we will have time (???), we can rethink the ACI stuff.
Sounds good to me. But let me note that there are many things including this issue that are awaiting a more wholesome solution regarding the way we handle partition and partition nesting.