If anonymous access is disabled, reading the Root DSE is forbidden by the server

• Key: DIRSERVER-360
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Alex Karasulu
• Reporter: Stefan Zoerner

Description

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.

Comments

[Alex Karasulu]

Resolved this on commit # 328138 here:

http://svn.apache.org/viewcvs.cgi?view=rev&rev=328138

Stephan please do me a favor and test these changes out for me. I did write a test case but these fixes are less than optimal. They're more a hack. The p-p for LDAP needs to be refactored heavily ... its a mess right now so I don't trust the fixes.

[Stefan Zoerner]

Alex, I still face some problems with this one. Unfortunately I was not able to create a piece of Java code to reproduce them in a good way yet. I found them by connecting to a server with Softerra LDAP Browser/Administrator. With it I am currently not able to browse the directory at all, if anonymous access is allowed and I act as an admin.

I assume that the tool binds anonymously first to analyze the Root DSE, and performs a bind with UID and password afterwards on the same connection. I will continue to create a better issue description tonight, and will hopefully present a piece of code which reproduces to problem.

[Stefan Zoerner]

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:
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(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.

[Stefan Zoerner]

I was wrong. The other problem mentioned above has nothing to do with this issue here. It is related to resolving DIREVE-274. I have filed it in new DIREVE-294 ("Search filters with wrong case in attribute names lead to wrong result").

[Stefan Zoerner]

My last comment was unclear. The problem described above which causes an LdapNoPermissionException although anonymously binds are allowed still exists, unfortunately. Only the "other problems" mentioned in the comment are described in DIREVE-294 (and fixed, thanks to Alex!).

In order to demonstrate this remaining one I have added a test to an existing testcase here
http://svn.apache.org/viewcvs.cgi?rev=328742&view=rev
which tries to do the same thing in Java which I have performed with command line tools as described above. The method ("testAnonymousBindsEnabledBaseSearch") is currently commented out because it fails.

Committed revision 328979 here:

http://svn.apache.org/viewcvs.cgi?rev=328979&view=rev

[Stefan Zoerner]

This has been fixed a long time ago, I have just retested it with the current 1.0 build. Thus I close the issue.