[
http://issues.apache.org/jira/browse/DIREVE-283?page=comments#action_12355894 ]
Stefan Zoerner commented on DIREVE-283:
---------------------------------------
I currently have several problems with the behavior of the LDAP provider since
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:
[EMAIL PROTECTED]:
org.apache.ldap.common.exception.LdapNoPermissionException: Anonymous binds
have been disabled!
at
org.apache.ldap.server.protocol.SessionRegistry.getLdapContext(SessionRegistry.java:190)
at
org.apache.ldap.server.protocol.support.SearchHandler.messageReceived(SearchHandler.java:108)
at
org.apache.mina.protocol.handler.DemuxingProtocolHandler.messageReceived(DemuxingProtocolHandler.java:94)
at
org.apache.mina.protocol.AbstractProtocolFilterChain$2.messageReceived(AbstractProtocolFilterChain.java:149)
at
org.apache.mina.protocol.AbstractProtocolFilterChain.callNextMessageReceived(AbstractProtocolFilterChain.java:365)
at
org.apache.mina.protocol.AbstractProtocolFilterChain.access$1000(AbstractProtocolFilterChain.java:50)
at
org.apache.mina.protocol.AbstractProtocolFilterChain$Entry$1.messageReceived(AbstractProtocolFilterChain.java:524)
at
org.apache.mina.protocol.AbstractProtocolFilterChain$1.messageReceived(AbstractProtocolFilterChain.java:99)
at
org.apache.mina.protocol.AbstractProtocolFilterChain.callNextMessageReceived(AbstractProtocolFilterChain.java:365)
at
org.apache.mina.protocol.AbstractProtocolFilterChain.messageReceived(AbstractProtocolFilterChain.java:356)
at
org.apache.mina.protocol.ProtocolSessionManagerFilterChain$1.messageReceived(ProtocolSessionManagerFilterChain.java:76)
at
org.apache.mina.protocol.AbstractProtocolFilterChain.callNextMessageReceived(AbstractProtocolFilterChain.java:365)
at
org.apache.mina.protocol.AbstractProtocolFilterChain.access$1000(AbstractProtocolFilterChain.java:50)
at
org.apache.mina.protocol.AbstractProtocolFilterChain$Entry$1.messageReceived(AbstractProtocolFilterChain.java:524)
at
org.apache.mina.protocol.filter.ProtocolThreadPoolFilter.processEvent(ProtocolThreadPoolFilter.java:108)
at
org.apache.mina.util.BaseThreadPool$Worker.processEvents(BaseThreadPool.java:410)
at
org.apache.mina.util.BaseThreadPool$Worker.run(BaseThreadPool.java:355)
$
because anonymous binds are enabled. The client should be allowed to see this
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
flavors) 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
> supportedSASLMechanisms if connected anonymously. This is because s/he can
> then decide 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, namingContexts), even if anonymous binds are not
> allowed (e.g. default configuration of Active Directory).
> But it seems to be up to us, which information we give anonymously bind users
> (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/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
