directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: [jira] Created: (DIRSERVER-1383) There is a confusion between Anonymous access and Access to rootDSE
Date Tue, 21 Jul 2009 15:24:37 GMT
Alex Karasulu wrote:
> 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
>>> 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.
>>> 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
> 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.

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 

When we will have time (???), we can rethink the ACI stuff.

cordialement, regards,
Emmanuel L├ęcharny

View raw message