Au Kin Leung Barge Centre - Planner Hongkong International Terminals Tel : (852) 2619 7932 Fax : (852) 2615 9369 E-mail : [EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
