[ http://issues.apache.org/jira/brows...235589
4 ]

Stefan Zoerner commented on DIREVE-283:
---------------------------------------

I currently have several problems with the behavior of the LDAP provider sin
ce this fix. At least this one is easy to demonstrate:

First I configure anonymous access for my server within server.xml like this
:

<property name="allowAnonymousAccess"><value>true</value></property>

Then I do the following via command line:

$ ldapsearch -b "" -s base -h localhost -p 10389 "(objectclass=*)"

supportedFeatures=1.3.6.1.4.1.4203.1.5.1
objectClass=extensibleObject
objectClass=top
$

This is fine. But the following is an error:

$ ldapsearch -b "dc=apache,dc=org" -s base -p 10389 "(objectclass=*)"
ldap_search: Insufficient access
ldap_search: additional info: failed on search operation:
org.apache.ldap.common.message.SearchRequestImpl@5646a5:
org.apache.ldap.common.exception.LdapNoPermissionException: Anonymous binds 
have been disabled!
at org.apache.ldap.server.protocol.SessionRegistry.getLdapContext(SessionReg
istry.java:190)
at org.apache.ldap.server.protocol.support.SearchHandler.messageReceived(Sea
rchHandler.java:108)
at org.apache.mina.protocol.handler.DemuxingProtocolHandler.messageReceived(
DemuxingProtocolHandler.java:94)
at org.apache.mina.protocol.AbstractProtocolFilterChain$2.messageReceived(Ab
stractProtocolFilterChain.java:149)
at org.apache.mina.protocol.AbstractProtocolFilterChain.callNextMessageRecei
ved(AbstractProtocolFilterChain.java:365)
at org.apache.mina.protocol.AbstractProtocolFilterChain.access$1000(Abstract
ProtocolFilterChain.java:50)
at org.apache.mina.protocol.AbstractProtocolFilterChain$Entry$1.messageRecei
ved(AbstractProtocolFilterChain.java:524)
at org.apache.mina.protocol.AbstractProtocolFilterChain$1.messageReceived(Ab
stractProtocolFilterChain.java:99)
at org.apache.mina.protocol.AbstractProtocolFilterChain.callNextMessageRecei
ved(AbstractProtocolFilterChain.java:365)
at org.apache.mina.protocol.AbstractProtocolFilterChain.messageReceived(Abst
ractProtocolFilterChain.java:356)
at org.apache.mina.protocol.ProtocolSessionManagerFilterChain$1.messageRecei
ved(ProtocolSessionManagerFilterChain.java:76)
at org.apache.mina.protocol.AbstractProtocolFilterChain.callNextMessageRecei
ved(AbstractProtocolFilterChain.java:365)
at org.apache.mina.protocol.AbstractProtocolFilterChain.access$1000(Abstract
ProtocolFilterChain.java:50)
at org.apache.mina.protocol.AbstractProtocolFilterChain$Entry$1.messageRecei
ved(AbstractProtocolFilterChain.java:524)
at org.apache.mina.protocol.filter.ProtocolThreadPoolFilter.processEvent(Pro
tocolThreadPoolFilter.java:108)
at org.apache.mina.util.BaseThreadPool$Worker.processEvents(BaseThreadPool.j
ava:410)
at org.apache.mina.util.BaseThreadPool$Worker.run(BaseThreadPool.java:355)

$

because anonymous binds are enabled. The client should be allowed to see thi
s entry, like the admin for instance is:

$ ldapsearch -D "uid=admin,ou=system" -w ***** -b "dc=apache,dc=org" -s base
 -h localhost -p 10389 "(objectclass=*)"
dc=apache,dc=org
dc=apache
objectClass=extensibleObject
objectClass=domain
objectClass=top
$

I'll try to file the other problem(s) (I hope it is only one in different fl
avors) soon -- difficult to reduce, unfortunately.

> If anonymous access is disabled, reading the Root DSE is forbidden by the 
server
> --------------------------------------------------------------------------
------
>
>          Key: DIREVE-283
>          URL: http://issues.apache.org/jira/browse/DIREVE-283
>      Project: Directory Server
>         Type: Bug
>     Reporter: Stefan Zoerner
>     Assignee: Alex Karasulu
>      Fix For: 0.9.3

>
> If anonymous access is disabled, i.e. configuration is
>  <property name="allowAnonymousAccess"><value>false</value></property>
> a client which binds anonymously is not allowed to fetch any Root DSE data
.
> $ ldapsearch -b "" -s base -p 10389 "(objectclass=*)"
> ldap_simple_bind: Insufficient access
> It is expected that a client is at least able to read the attribute suppor
tedSASLMechanisms if connected anonymously. This is because s/he can then de
cide which mechanism fits his/her needs best, before authentication. Here is
 what RFC 2829 says:
> 5. Anonymous authentication
>    ...
>    LDAP implementations MUST support anonymous authentication, as
>    defined in section 5.1.
>    ...
>    While there MAY be access control restrictions to prevent access to
>    directory entries, an LDAP server SHOULD allow an anonymously-bound
>    client to retrieve the supportedSASLMechanisms attribute of the root
>    DSE.
>    ...
> It is quite normal, that LDAP servers present the other information advertised in 
the Root DSE to anonymously connected clients as well (e.g. supportedLDAPVersion, na
mingContexts), even if anonymous binds are not allowed (e.g. default configuration o
f A
ctive Directory).
> But it seems to be up to us, which information we give anonymously bind us
ers (except supportedSASLMechanisms), this is what RFC 2251 says:
> 3.4. Server-specific Data Requirements
>    An LDAP server MUST provide information about itself and other
>    information that is specific to each server.  This is represented as
>    a group of attributes located in the root DSE (DSA-Specific Entry),
>    which is named with the zero-length LDAPDN.  These attributes are
>    retrievable if a client performs a base object search of the root
>    with filter "(objectClass=*)", however they are subject to access
>    control restrictions.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secur...nistrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

[ Post a follow-up to this message ]