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=39350>. 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=39350 Summary: No kerberos auth with JK1 in IIS (ticketsize) Product: Tomcat 5 Version: Unknown Platform: PC OS/Version: Windows Server 2003 Status: NEW Severity: major Priority: P2 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Hi, we use JK1 in IIS6 to connect to Tomcats. The IIS does the authentication. Our Organisation has grown and so has the group memberships of the users. The memberships are listed in the kerberos tickets needed for internal windows authentication in IIS. Now we already had to increase the max kerberos ticket size on our servers from 11k to 64k because of that. Problem: lately we recognized that internal authentication doesn't work any more on some accounts, if the web has a JK-component. The JK debug-log shows this: [Wed Apr 19 14:24:14 2006] [5976:3224] [debug] jk_isapi_plugin.c (845): check if [/nwm/menuaction.do] is points to the web-inf directory [Wed Apr 19 14:24:14 2006] [5976:3224] [debug] jk_isapi_plugin.c (863): [/nwm/menuaction.do] is a servlet url - should redirect to lb_ptomx [Wed Apr 19 14:24:14 2006] [5976:3224] [debug] jk_worker.c (301): Maintaining worker lb_ptomx [Wed Apr 19 14:24:14 2006] [5976:3224] [debug] jk_ajp_common.c (2203): recycled 0 sockets in 0 seconds [Wed Apr 19 14:24:14 2006] [5976:3224] [debug] jk_ajp_common.c (2203): recycled 0 sockets in 0 seconds [Wed Apr 19 14:24:14 2006] [5976:3224] [debug] jk_ajp_common.c (2203): recycled 0 sockets in 0 seconds [Wed Apr 19 14:24:14 2006] [5976:3224] [debug] jk_ajp_common.c (2203): recycled 0 sockets in 0 seconds [Wed Apr 19 14:24:14 2006] [5976:3224] [debug] jk_ajp_common.c (2203): recycled 0 sockets in 0 seconds [Wed Apr 19 14:24:14 2006] [5976:3224] [debug] jk_ajp_common.c (2203): recycled 0 sockets in 0 seconds [Wed Apr 19 14:24:14 2006] [5976:3224] [debug] jk_worker.c (111): found a worker lb_ptomx [Wed Apr 19 14:24:14 2006] [5976:3224] [debug] jk_isapi_plugin.c (1018): got a worker for name lb_ptomx [Wed Apr 19 14:24:14 2006] [5976:3224] [debug] jk_lb_worker.c (592): service sticky_session=1 [Wed Apr 19 14:24:14 2006] [5976:3224] [debug] jk_lb_worker.c (564): found best worker (p-hh-ptom1_I2) using by request method [Wed Apr 19 14:24:14 2006] [5976:3224] [debug] jk_ajp_common.c (2131): acquired connection cache slot=0 [Wed Apr 19 14:24:14 2006] [5976:3224] [debug] jk_lb_worker.c (612): service worker=p-hh-ptom1_I2 jvm_route=p-hh-ptom1_I2 [Wed Apr 19 14:24:14 2006] [5976:3224] [error] jk_ajp_common.c (430): failed appending the header value [Wed Apr 19 14:24:14 2006] [5976:3224] [info] jk_ajp_common.c (1662): Creating AJP message failed, without recovery [Wed Apr 19 14:24:14 2006] [5976:3224] [debug] jk_ajp_common.c (2074): recycling connection cache slot=0 for worker p-hh-ptom1_I2 [Wed Apr 19 14:24:14 2006] [5976:3224] [info] jk_lb_worker.c (711): unrecoverable error 413, request failed. Client failed in the middle of request, we can't recover to another instance. [Wed Apr 19 14:24:14 2006] [5976:3224] [debug] jk_isapi_plugin.c (1031): service() returned OK The "failed appending the header value" took the analysis into the jk-code. It seems to be related to the buffersize, but i'm not an expert in you code. The error occours here... if (msg->len + len + 2 > msg->maxlen) { return JK_ERR; ... ...and before you set... msg->maxlen = buffSize; ...and before that... buffSize = DEF_BUFFER_SZ; ...refering to the defrined static... #define DEF_BUFFER_SZ (8 * 1024) I think that means that you have a 8k buffer for the JK-Message. the Kerberos ticket is in the header so jk tries to add it to the message (allthough the auth is configured to take place on the IIS-side). And so the big header busts the buffer, we think. Hopefully you can find a way to cure this problem for us. Increasing the buffer would be a quick workaround (If our analysis is right). But maybe a dynamic buffer or an intelligent handling of header data (i.e. stripping of info the TC doesn't use anyway) would be a more complete solution. -- 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]
