directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [jira] Created: (DIRSERVER-1383) There is a confusion between Anonymous access and Access to rootDSE
Date Tue, 21 Jul 2009 15:02:56 GMT
On Tue, Jul 21, 2009 at 10:50 AM, Emmanuel Lecharny <>wrote:

> 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
>> 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.
>> WDYT?
> I think we can do a little bit simpler.
> 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

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.

View raw message