You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by op...@hit.com.hk on 2005/02/10 16:27:40 UTC

RE: DO NOT REPLY [Bug 33492] New: - When using LDAP realms Tomc at floods the LDAP server with searches instead of binding as a DN


Au Kin Leung
Barge Centre - Planner
Hongkong International Terminals 
Tel : (852) 2619 7932 
Fax : (852) 2615 9369 
E-mail : ops.bc@hit.com.hk 
Website : www.hit.com.hk <http://www.hit.com.hk> 

IMPORTANT NOTICE 
The above job number serves only as a reference number of your booking
request.  This DOES NOT confirm HIT's berth availability to provide barge
services to you at your requested booking time.  

Please note that HIT Berth Schedule Report will be email/fax to you at 14:00
for requests from 17:00 to 22:59 and at 20:00 for requests from 23:00 to
16:59 on the next day.  Kindly please forward the HIT Berth Schedule Report
to your barge agents/operators and remind them to berth at HIT at the
confirmed berthing time.

Should you have any queries, please feel free to contact us at 2619-7932. 



-----Original Message-----
From: ops.bc@hit.com.hk [mailto:ops.bc@hit.com.hk] 
Sent: Thursday, February 10, 2005 11:27 PM
To: tomcat-dev@jakarta.apache.org
Subject: RE: DO NOT REPLY [Bug 33492] New: - When using LDAP realms Tomc at
floods the LDAP server with searches instead of binding as a DN




Au Kin Leung
Barge Centre - Planner
Hongkong International Terminals 
Tel : (852) 2619 7932 
Fax : (852) 2615 9369 
E-mail : ops.bc@hit.com.hk 
Website : www.hit.com.hk <http://www.hit.com.hk> 

IMPORTANT NOTICE 
The above job number serves only as a reference number of your booking
request.  This DOES NOT confirm HIT's berth availability to provide barge
services to you at your requested booking time.  

Please note that HIT Berth Schedule Report will be email/fax to you at 14:00
for requests from 17:00 to 22:59 and at 20:00 for requests from 23:00 to
16:59 on the next day.  Kindly please forward the HIT Berth Schedule Report
to your barge agents/operators and remind them to berth at HIT at the
confirmed berthing time.

Should you have any queries, please feel free to contact us at 2619-7932. 



-----Original Message-----
From: bugzilla@apache.org [mailto:bugzilla@apache.org] 
Sent: Thursday, February 10, 2005 11:23 PM
To: tomcat-dev@jakarta.apache.org
Subject: DO NOT REPLY [Bug 33492] New: - When using LDAP realms Tomcat
floods the LDAP server with searches instead of binding as a DN


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG*
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=33492>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND* INSERTED IN THE
BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33492

           Summary: When using LDAP realms Tomcat floods the LDAP server
                    with searches instead of binding as a DN
           Product: Tomcat 5
           Version: 5.0.30
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: major
          Priority: P2
         Component: Catalina
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: aleksander.adamowski.apache@altkom.pl


I have the following Engine configuration in server.xml:

<Engine name="Catalina" defaultHost="localhost">
  <Logger className="org.apache.catalina.logger.FileLogger" />

  <Realm className="org.apache.catalina.realm.JNDIRealm" debug="99"
         connectionURL="ldap://localhost:388"
         authentication="simple"
         userBase="dc=altkom,dc=pl,o=Altkom" userSubtree="true"
         userSearch="uid={0}"
         userRoleName="ou"
         resourceName="LdapDatabase" />

  <Host name="localhost" appBase="webapps" />
</Engine>

The port 388 is used by a local stunnel proxy that forwards SSL-encapsulated
LDAP requests to a central LDAP authentication server (Tomcat stubbornly
uses plaintext communication even with ldaps:// URI's, but that's another
story...).

The Tomcat server starts up OK, and I can see it opening a connection to the
LDAP server. It's visible in OpenLDAP's logs:

Feb 10 16:08:30 ldap slapd[10446]: conn=36 fd=17 ACCEPT from
IP=xxx.xxx.xxx.xxx:49747 (IP=0.0.0.0:636) 
Feb 10 16:08:30 ldap slapd[10446]: conn=36 op=0 BIND dn="" method=128 
Feb 10 16:08:30 ldap slapd[10446]: conn=36 op=0 RESULT tag=97 err=0 text= 

Tomcat reports success in its logs too:

Feb 10, 2005 4:08:30 PM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/5.0
Feb 10, 2005 4:08:31 PM org.apache.catalina.core.StandardHost start
INFO: XML validation disabled
Feb 10, 2005 4:08:31 PM org.apache.catalina.core.StandardHost getDeployer
INFO: Create Host deployer for direct deployment ( non-jmx ) Feb 10, 2005
4:08:31 PM org.apache.catalina.core.StandardHostDeployer install
INFO: Processing Context configuration file URL
file:/etc/tomcat5/Catalina/localhost/balancer.xml
...

However, if I try to authenticate a user by trying to log in to the standard
admin webapp, Tomcat floods the LDAP server with redundant search requests:

Feb 10 16:11:03 ldap slapd[10446]: conn=36 op=1 SRCH
base="dc=altkom,dc=pl,o=Altkom" scope=2 filter="(uid=someuser)" Feb 10
16:11:03 ldap slapd[10446]: conn=36 op=1 SRCH attr=ou Feb 10 16:11:03 ldap
slapd[10446]: conn=37 fd=19 ACCEPT from IP=127.0.0.1:40390
(IP=0.0.0.0:389)
Feb 10 16:11:03 ldap slapd[10446]: conn=37 op=0 BIND dn="" method=128 Feb 10
16:11:03 ldap slapd[10446]: conn=37 op=0 RESULT tag=97 err=0 text= Feb 10
16:11:03 ldap slapd[10446]: conn=37 op=1 SRCH
base="dc=altkom,dc=pl,o=Altkom" scope=2 filter="(uid=someuser)" Feb 10
16:11:03 ldap slapd[10446]: conn=37 op=1 SRCH attr=ou Feb 10 16:11:03 ldap
slapd[10446]: conn=38 fd=21 ACCEPT from IP=127.0.0.1:40391
(IP=0.0.0.0:389)
Feb 10 16:11:03 ldap slapd[10446]: conn=38 op=0 BIND dn="" method=128 Feb 10
16:11:03 ldap slapd[10446]: conn=38 op=0 RESULT tag=97 err=0 text= Feb 10
16:11:03 ldap slapd[10446]: conn=38 op=1 SRCH
base="dc=altkom,dc=pl,o=Altkom" scope=2 filter="(uid=someuser)" Feb 10
16:11:03 ldap slapd[10446]: conn=38 op=1 SRCH attr=ou Feb 10 16:11:03 ldap
slapd[10446]: conn=39 fd=23 ACCEPT from IP=127.0.0.1:40392
(IP=0.0.0.0:389)
Feb 10 16:11:03 ldap slapd[10446]: conn=39 op=0 BIND dn="" method=128 Feb 10
16:11:03 ldap slapd[10446]: conn=39 op=0 RESULT tag=97 err=0 text=

Tomcat opens many parallel connections until it clogs the LDAP server.

Looks like it tries to do an asynchronous search (why not a synchronous
one?), and instead of checking back for results later, opens new connections
and does new searches in an infinite loop.

Expected behaviour: Tomcat should receive search results, and if an entry is
found, it should try to bind using that entry's DN. If bind operation
succeeds, it should assume that the user/password is correct and the user
has the roles corresponding to values of the "ou" attribute (if present).

In my case the search for ou would return the following results:
dn: uid=someuser,dc=warszawa,dc=altkom,dc=pl,o=altkom
ou: tk
ou: edu
ou: tomcat

So after authentication successfully, someuser should have the roles "tk",
"edu" and "tomcat" in the webapp.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


The message represents the personal views and opinion of the individual
sender and under no circumstances represents those of Hutchison Port
Holdings Limited ("HPH") or its Group Companies. The shareholders, directors
and management of HPH and any of its Group Companies accept no
responsibility and accordingly shall have no liability to any party
whatsoever with respect to the contents of this message.

This message (including any attachments) is intended only for the use of the
addressee(s) named above. It may contain information that is PRIVILEGED and
CONFIDENTIAL and should not be read, copied or otherwise used by any other
person.

If you are not the intended recipient, you are hereby notified that any use,
retention, disclosure, copying, printing, forwarding or dissemination of
this communication is strictly prohibited. If you have received this
communication in error, please erase all copies of the message and its
attachments and notify us immediately.

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


The message represents the personal views and opinion of the individual
sender and under no circumstances represents those of Hutchison Port
Holdings Limited ("HPH") or its Group Companies. The shareholders, directors
and management of HPH and any of its Group Companies accept no
responsibility and accordingly shall have no liability to any party
whatsoever with respect to the contents of this message.

This message (including any attachments) is intended only for the use of the
addressee(s) named above. It may contain information that is PRIVILEGED and
CONFIDENTIAL and should not be read, copied or otherwise used by any other
person.

If you are not the intended recipient, you are hereby notified that any use,
retention, disclosure, copying, printing, forwarding or dissemination of
this communication is strictly prohibited. If you have received this
communication in error, please erase all copies of the message and its
attachments and notify us immediately.

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org