You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alex Karasulu <ak...@gmail.com> on 2009/07/21 02:30:53 UTC
Re: [jira] Created: (DIRSERVER-1383) There is a confusion between
Anonymous access and Access to rootDSE
You're supposed to allow annonymous binds to the RootDSE even when anon
binds are disabled. This is because RootDSE access is required always to
discover how to auth in the first place.
Alex
On Mon, Jul 20, 2009 at 6:13 PM, Emmanuel Lecharny (JIRA)
<ji...@apache.org>wrote:
> There is a confusion between Anonymous access and Access to rootDSE
> -------------------------------------------------------------------
>
> Key: DIRSERVER-1383
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1383
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 1.5.4
> Reporter: Emmanuel Lecharny
> Priority: Critical
> Fix For: 1.5.5
>
>
> The way the Anonymous authenticator is written makes it possible to be
> bound and read the rootDSE even if anonymous access is disabled on the
> server :
>
> public LdapPrincipal authenticate( BindOperationContext opContext )
> throws NamingException
> {
> // We only allow Anonymous binds if the service allows them _or_
> // if the user wants to bind on the rootDSE
> if ( getDirectoryService().isAllowAnonymousAccess() ||
> opContext.getDn().isEmpty() ) <=== here !!
> {
> return LdapPrincipal.ANONYMOUS;
>
> So an anonymous bind will always be accepted, as it will be identified as a
> bind to the rootDSE (the DN is empty when doing an anonymous bind).
>
> So you *always* have access to the server even if the alowedAnonymousAccess
> flag is set to false !!!
>
> Bad ...
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
Re: [jira] Created: (DIRSERVER-1383) There is a confusion between
Anonymous access and Access to rootDSE
Posted by Alex Karasulu <ak...@gmail.com>.
On Tue, Jul 21, 2009 at 11:24 AM, Emmanuel Lecharny <el...@apache.org>wrote:
> Alex Karasulu wrote:
>
>> On Tue, Jul 21, 2009 at 10:50 AM, Emmanuel Lecharny <elecharny@apache.org
>> >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 remove).
>
> 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.
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
Re: [jira] Created: (DIRSERVER-1383) There is a confusion between
Anonymous access and Access to rootDSE
Posted by Emmanuel Lecharny <el...@apache.org>.
Alex Karasulu wrote:
> On Tue, Jul 21, 2009 at 10:50 AM, Emmanuel Lecharny <el...@apache.org>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
remove).
When we will have time (???), we can rethink the ACI stuff.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [jira] Created: (DIRSERVER-1383) There is a confusion between
Anonymous access and Access to rootDSE
Posted by Alex Karasulu <ak...@gmail.com>.
On Tue, Jul 21, 2009 at 10:50 AM, Emmanuel Lecharny <el...@apache.org>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.
Re: [jira] Created: (DIRSERVER-1383) There is a confusion between
Anonymous access and Access to rootDSE
Posted by Emmanuel Lecharny <el...@apache.org>.
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.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [jira] Created: (DIRSERVER-1383) There is a confusion between
Anonymous access and Access to rootDSE
Posted by Alex Karasulu <ak...@gmail.com>.
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?
On Tue, Jul 21, 2009 at 4:24 AM, Emmanuel Lecharny <el...@apache.org>wrote:
> Stefan Zoerner wrote:
>
>> Quanah Gibson-Mount wrote:
>>
>>> --On Monday, July 20, 2009 9:50 PM -0400 Alex Karasulu <
>>> akarasulu@gmail.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.
>>
>
> 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.
>
> 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 !
>
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
Re: [jira] Created: (DIRSERVER-1383) There is a confusion between
Anonymous access and Access to rootDSE
Posted by Emmanuel Lecharny <el...@apache.org>.
Stefan Zoerner wrote:
> Quanah Gibson-Mount wrote:
>> --On Monday, July 20, 2009 9:50 PM -0400 Alex Karasulu
>> <ak...@gmail.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.
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.
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 !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [jira] Created: (DIRSERVER-1383) There is a confusion between
Anonymous access and Access to rootDSE
Posted by Stefan Zoerner <st...@labeo.de>.
Quanah Gibson-Mount wrote:
> --On Monday, July 20, 2009 9:50 PM -0400 Alex Karasulu
> <ak...@gmail.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.
Greetings from Hamburg,
Stefan
Re: [jira] Created: (DIRSERVER-1383) There is a confusion between
Anonymous access and Access to rootDSE
Posted by Emmanuel Lecharny <el...@apache.org>.
Quanah Gibson-Mount wrote:
> --On Monday, July 20, 2009 9:50 PM -0400 Alex Karasulu
> <ak...@gmail.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
here, the problem is much more serious : it's the Bind operation which
is faulty, allowing an anonymous bind even if not allowed... Everything
else is pure theory, and if we stick to the RFC, even the rootDSE could
be read protected.
Anyway, the Bind issue must be fixed. We have tests which wrongly assume
that we *must* be able to read rootDSE as anonymous even if the
allowAnonymousAccess flag is set to 'false', just because we didn't do
the right thing : do a search on rootDSE entry *without* a previous
bind. I'm not sure you can do that using JDNI (doing a search without
issuing a BindRequest first).
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [jira] Created: (DIRSERVER-1383) There is a confusion between
Anonymous access and Access to rootDSE
Posted by Quanah Gibson-Mount <qu...@zimbra.com>.
--On Monday, July 20, 2009 9:50 PM -0400 Alex Karasulu
<ak...@gmail.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
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
Re: [jira] Created: (DIRSERVER-1383) There is a confusion between
Anonymous access and Access to rootDSE
Posted by Alex Karasulu <ak...@gmail.com>.
Ahhh okie you're right on. My bad.
On Mon, Jul 20, 2009 at 8:34 PM, Emmanuel Lecharny <el...@apache.org>wrote:
> Alex Karasulu wrote:
>
>> You're supposed to allow annonymous binds to the RootDSE even when anon
>> binds are disabled. This is because RootDSE access is required always to
>> discover how to auth in the first place.
>>
>>
> Not true, per RFC 4512 :
>
> 5.1. Server-Specific Data Requirements
>
> ...
>
> These attributes are retrievable, *subject to access control* and other
> restrictions, if a client performs a Search operation...
>
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
Re: [jira] Created: (DIRSERVER-1383) There is a confusion between
Anonymous access and Access to rootDSE
Posted by Emmanuel Lecharny <el...@apache.org>.
Alex Karasulu wrote:
> You're supposed to allow annonymous binds to the RootDSE even when anon
> binds are disabled. This is because RootDSE access is required always to
> discover how to auth in the first place.
>
Not true, per RFC 4512 :
5.1. Server-Specific Data Requirements
...
These attributes are retrievable, *subject to access control* and other
restrictions, if a client performs a Search operation...
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [jira] Created: (DIRSERVER-1383) There is a confusion between
Anonymous access and Access to rootDSE
Posted by Emmanuel Lecharny <el...@apache.org>.
Alex Karasulu wrote:
> You're supposed to allow annonymous binds to the RootDSE even when anon
> binds are disabled. This is because RootDSE access is required always to
> discover how to auth in the first place.
>
Also I don't think we need to be able to read the rootDSE when doing a
Bind. The way it works is that a client just send a BindRequest, and the
server do what it should with this request, with full access to the RootDSE.
So I don't think we should allow anonymoius access to the RootDSE for
the client, unless the admin specifically decide to do so.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org