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]
