Java Mailing List Archive

http://www.junlu.com/

Home » users-digest.tomcat »

users Digest 1 Aug 2013 15:00:41 -0000 Issue 11461

users-digest-help

2013-08-01


Author LoginPost Reply

users Digest 1 Aug 2013 15:00:41 -0000 Issue 11461

Topics (messages 242934 through 242941)

Re: java.net.UnknownHostException: Failed to negotiate with a suitable domain controller for xxx
 242934 by: Caldarale, Charles R
 242937 by: Christopher Schultz
 242938 by: Martin Gainty
 242940 by: André Warnier
 242941 by: Seema Patel

Re: Tomcat and IP transparency
 242935 by: Christopher Schultz

Re: SSL and 408 error code (incomplete request)
 242936 by: Christopher Schultz

Re: Cannot start apache tomcat 7.0 if server path contains two consecutive spaces.
 242939 by: Jeffrey Janner

Administrivia:

---------------------------------------------------------------------
To post to the list, e-mail: users@(protected)
To unsubscribe, e-mail: users-digest-unsubscribe@(protected)
For additional commands, e-mail: users-digest-help@(protected)

----------------------------------------------------------------------


Attachment: users_242934.eml (zipped)
> From: Seema Patel [mailto:seema165@(protected)]
> Subject: java.net.UnknownHostException: Failed to negotiate with a suitable domain controller for xxx

> I am not sure if this is the right List to post this on

This is the correct list, but...

> jcifs.http.NtlmHttpFilter

Not supported: http://jcifs.samba.org/src/docs/ntlmhttpauth.html

> We are running Tomcat 5.5.29.

Not supported.

> java version "1.5.0_22"

Not supported.

You really, really need to upgrade your environment. Using unsupported versions of the JVM and Tomcat leaves you open to numerous attacks and other bugs that will never be addressed in those versions.

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.



Attachment: users_242937.eml (zipped)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Chuck,

On 8/1/13 7:50 AM, Caldarale, Charles R wrote:
>> From: Seema Patel [mailto:seema165@(protected):
>> java.net.UnknownHostException: Failed to negotiate with a
>> suitable domain controller for xxx
>
>> I am not sure if this is the right List to post this on
>
> This is the correct list, but...
>
>> jcifs.http.NtlmHttpFilter
>
> Not supported: http://jcifs.samba.org/src/docs/ntlmhttpauth.html
>
>> We are running Tomcat 5.5.29.
>
> Not supported.
>
>> java version "1.5.0_22"
>
> Not supported.
>
> You really, really need to upgrade your environment. Using
> unsupported versions of the JVM and Tomcat leaves you open to
> numerous attacks and other bugs that will never be addressed in
> those versions.

+1

For what it's worth, upgrading the JVM is usually painless (with a few
exceptions, but it's easy to try!).

Since you were already on Tomcat 5.5, the transition from 5.5 -> 7.0
(latest) is pretty much a drop-in replacement (you'll need to re-write
your server.xml from scratch, but it shouldn't be a big deal to
re-configure your <Connector>s).

http://tomcat.apache.org/migration-6.html
http://tomcat.apache.org/migration-7.html

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJR+mFbAAoJEBzwKT+lPKRYyZ4QAMpa71PhxVktGiTwX0W49H2D
Irbt9EQ88BYjwawl0vgpcrt48ofMBOwErhsyFyYhk/zaaKRQOkP9Yf+lhq2sHkOQ
FNMzF52ZyYPcaPhlN7DsGMbEZtYqq07SkTPXYQ9bY7+CAbWUF/4CZ4vG3q0q7MiY
h48SIUs4EKF0UBmDFBcLdJj0xo+Lbnd6mx4WmasjJTDuniZsK6qZtxnn66UQBw2P
7n8hLCOBXvsjol9m5z/bJt1SifjQVNSfyoxlL7A7Pf1QP9zh1bAYen9efPKoa2Za
TM0KGYa9Vb8hNRGPGZH7/Rs0ZfIdpFrPqJtWTVeZBbt7EtABZbvDW3bsh5WYgzv1
G0pyJQl8tnVpem9QvniX4POHEuboSfco53k3SBe8dp6M+798zLAr4DcamRsvxR0d
2nJxLkl3XZiF3IaxyfeIjIz00gqU3AXj4T+yOtMb2g6ok3eRJlaTqraHyeMSPFQ0
IEzcHEUwuYlRfm4+IBqwlQUjRpKTkkM7rjqGQIQz1BqCrZ4amcjM7QlW9/3wj+p+
I803eFy+XfNJ5EwE2t/s1H+zzMM7uzsvR4dMkak4IMcV8r1TRYF+8ddR6AKYNuzX
pKwuFEXRaDycPkxaWoh9OO2UZ5OXk6VPU9QCuEcaLgDLjH3UHpAAFvM27dkmi/5P
tlQKaspmVeRFL8u+i8a3
=udXh
-----END PGP SIGNATURE-----


Attachment: users_242938.eml (zipped)
nslookup DomainName

if you still call no joy there is nothing we can do (without contacting your Domain Admin and asking if DomainName is live)

Martin
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.


> From: seema165@(protected)
> To: users@(protected)
> Subject: RE: java.net.UnknownHostException: Failed to negotiate with a suitable domain controller for xxx
> Date: Thu, 1 Aug 2013 12:02:34 +0100
>
>
>
> > Date: Thu, 1 Aug 2013 12:06:39 +0200
> > From: aw@(protected)
> > To: users@(protected)
> > Subject: Re: java.net.UnknownHostException: Failed to negotiate with a suitable domain controller for xxx
> >
> > Seema Patel wrote:
> > > Hi,
> > >
> > > I am not sure if this is the right List to post this on, please advise if it isn't and let me know where is best to post.
> > >
> > > I am getting the following error on one of our applications running on our intranet:
> > >
> > > 2013-07-31 17:15:11,180 [http-xxx.xxx.x.xxx-xx-x] ERROR org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/forms].[action] - Servlet.service() for servlet action threw exception
> > > java.net.UnknownHostException: Failed to negotiate with a suitable domain controller for xxx.LOCAL
> > > at jcifs.smb.SmbSession.getChallengeForDomain(SmbSession.java:187)
> > > at jcifs.http.NtlmHttpFilter.negotiate(NtlmHttpFilter.java:150)
> > > at jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:114)
> > > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:215)
> > > at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:188)
> > > at org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:213)
> > > at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:172)
> > > at org.apache.catalina.authenticator.AuthenticatorBase.invoke (AuthenticatorBase.java:465)
> > > at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:127)
> > > at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:117)
> > > at org.apache.catalina.authenticator.SingleSignOn.invoke (SingleSignOn.java:393)
> > > at org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:108)
> > > at org.apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.java:174)
> > > at org.apache.coyote.http11.Http11AprProcessor.process (Http11AprProcessor.java:837)
> > > at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:640)
> > > at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1287)
> > > at java.lang.Thread.run(Unknown Source)
> > >
> >
> > I believe that you should read this page carefully, in particular the blue text at the
> > beginning : http://jcifs.samba.org/src/docs/ntlmhttpauth.html
> >
> > Can you have a look at the WEB-INF/web.xml file *of your application*, and check if there
> > is a servlet filter configured there, which matches the name above ?
> >
> > If so, make a backup copy of that web.xml file, and then edit it to remove that filter
> > from it, and try again.
> > I am not quite sure, but it looks possible to me that you have a duplicate authentication
> > mechanism in use : one at the container (Tomcat) level, and one at the application level.
> > And the one used at the application level is obsolete, unsupported, unmaintained etc..
> >
>
> I have found out that JCIFS is no longer supported, but it will take a lot of time, development and resources to update it to the recommended Jespa. In my web.xml file I have the following:
>
> <filter>
>      <filter-name>NtlmHttpFilter</filter-name>
>      <filter-class>jcifs.http.NtlmHttpFilter</filter-class>
>        
>      <!--
>         always needed for preauthentication / SMB signatures
>      -->
>      <init-param>
>         <param-name>jcifs.smb.client.domain</param-name>
>         <param-value>xxx</param-value>
>      </init-param>
>      <!-- SMB message signing requires a valid existing login -->
>      <init-param>
>         <param-name>jcifs.smb.client.username</param-name>
>         <param-value>xxx</param-value>
>      </init-param>
>      <init-param>
>         <param-name>jcifs.smb.client.password</param-name>
>         <param-value>xxx</param-value>
>      </init-param>
>      <!-- Set the logging level -->
>      <init-param>
>         <param-name>jcifs.util.loglevel</param-name>
>         <param-value>3</param-value>
>      </init-param>
>      <!-- allow non-IE browsers to use basic auth -->
>      <init-param>
>         <param-name>jcifs.http.insecureBasic</param-name>
>         <param-value>true</param-value>
>      </init-param>
>   </filter>
>   <filter>
>      <filter-name>HRADGroupFilter</filter-name>
>      <filter-class>xxx.ADGroupFilter</filter-class>
>      <init-param>
>         <param-name>AllowedGroups</param-name>
>         <param-value>G-HR,G-MIS</param-value>
>      </init-param>
>   </filter>
>      <filter>
>      <filter-name>SuggestionsGroupFilter</filter-name>
>      <filter-class>xxx.ADGroupFilter</filter-class>
>      <init-param>
>         <param-name>AllowedGroups</param-name>
>         <param-value>xxx, xxx</param-value>
>      </init-param>
>   </filter>
>  
>   <filter-mapping>
>      <filter-name>NtlmHttpFilter</filter-name>
>      <url-pattern>/suggestions/*</url-pattern>
>   </filter-mapping>
>   <filter-mapping>
>      <filter-name>SuggestionsGroupFilter</filter-name>
>      <url-pattern>/suggestions/*</url-pattern>
>   </filter-mapping>
>   <filter-mapping>
>      <filter-name>NtlmHttpFilter</filter-name>
>      <url-pattern>/xxx/*</url-pattern>
>   </filter-mapping>
>   <filter-mapping>
>      <filter-name>HRADGroupFilter</filter-name>
>      <url-pattern>/xxx/xxx.do</url-pattern>
>   </filter-mapping>
>
>
> So, are you saying to just remove the following from the above?:
>     <filter-name>NtlmHttpFilter</filter-name>
>     <filter-class>jcifs.http.NtlmHttpFilter</filter-class>
>
> Is there anything else in there that needs to be removed? Sorry for my lack of understanding, but this was all developed by previous developers, who are no longer working here and have left no documentation.
>
> Thanks
>
> >
> > > In my tomcat/conf/server.xml file I have:
> > >
> > > <Realm className="com.viatel.tomcatrealms.ADJNDIRealm"
> > > debug="01" resourceName="ActiveDirectory"
> > > connectionURL="ldap://xxx:xxx"
> > > alternativeURL="ldap://xxx:xxx"
> > > connectionName="LDAP@(protected)"
> > > referrals="follow" userBase="dc=vtlwavenet,dc=local"
> > > userSearch="(sAMAccountName={0})" userSubtree="true"
> > > roleBase="dc=xxx,dc=local" roleSearch="(member={0})"
> > > roleName="cn" roleSubtree="true" />
> > >
> > > I have 2 .war files running from this tomcat - 1) intranet portal A, 2) intranet helpdesk page and also another intranet portal B (both run from slightly different URLs).
> > > When tomcat was restarted the intranet portal A runs, intranet portal B runs but the intranet helpdesk portal doesn't run. For this we get the error message shown above.
> > >
> > > I don't know if it is the java code, some setting in the tomcat catalina base or if it is a tomcat network issue.
> > >
> > > We are running Tomcat 5.5.29.
> > > java version "1.5.0_22"
> > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_22-b03)
> > > Java HotSpot(TM) Client VM (build 1.5.0_22-b03, mixed mode, sharing)
> > > It is on a Windows Server 2003 R2 SP2 VM box.
> > >
> > > Any help on this is appreciated.
> > > Thanks in advance
> > >
> > > Seema
> > >
> > >
> > >
> > >            
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@(protected)
> > For additional commands, e-mail: users-help@(protected)
> >
>            
           

Attachment: users_242940.eml (zipped)
Seema Patel wrote:
>
>> Date: Thu, 1 Aug 2013 12:06:39 +0200
>> From: aw@(protected)
>> To: users@(protected)
>> Subject: Re: java.net.UnknownHostException: Failed to negotiate with a suitable domain controller for xxx
>>
>> Seema Patel wrote:
>>> Hi,
>>>
>>> I am not sure if this is the right List to post this on, please advise if it isn't and let me know where is best to post.
>>>
>>> I am getting the following error on one of our applications running on our intranet:
>>>
>>> 2013-07-31 17:15:11,180 [http-xxx.xxx.x.xxx-xx-x] ERROR org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/forms].[action] - Servlet.service() for servlet action threw exception
>>> java.net.UnknownHostException: Failed to negotiate with a suitable domain controller for xxx.LOCAL
>>> at jcifs.smb.SmbSession.getChallengeForDomain(SmbSession.java:187)
>>> at jcifs.http.NtlmHttpFilter.negotiate(NtlmHttpFilter.java:150)
>>> at jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:114)
>>> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:215)
>>> at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:188)
>>> at org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:213)
>>> at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:172)
>>> at org.apache.catalina.authenticator.AuthenticatorBase.invoke (AuthenticatorBase.java:465)
>>> at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:127)
>>> at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:117)
>>> at org.apache.catalina.authenticator.SingleSignOn.invoke (SingleSignOn.java:393)
>>> at org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:108)
>>> at org.apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.java:174)
>>> at org.apache.coyote.http11.Http11AprProcessor.process (Http11AprProcessor.java:837)
>>> at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:640)
>>> at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1287)
>>> at java.lang.Thread.run(Unknown Source)
>>>
>> I believe that you should read this page carefully, in particular the blue text at the
>> beginning : http://jcifs.samba.org/src/docs/ntlmhttpauth.html
>>
>> Can you have a look at the WEB-INF/web.xml file *of your application*, and check if there
>> is a servlet filter configured there, which matches the name above ?
>>
>> If so, make a backup copy of that web.xml file, and then edit it to remove that filter
>> from it, and try again.
>> I am not quite sure, but it looks possible to me that you have a duplicate authentication
>> mechanism in use : one at the container (Tomcat) level, and one at the application level.
>> And the one used at the application level is obsolete, unsupported, unmaintained etc..
>>
>
> I have found out that JCIFS is no longer supported, but it will take a lot of time, development and resources to update it to the recommended Jespa. In my web.xml file I have the following:
>
> <filter>
>      <filter-name>NtlmHttpFilter</filter-name>
>      <filter-class>jcifs.http.NtlmHttpFilter</filter-class>
>        
>      <!--
>         always needed for preauthentication / SMB signatures
>      -->
>      <init-param>
>         <param-name>jcifs.smb.client.domain</param-name>
>         <param-value>xxx</param-value>
>      </init-param>
>      <!-- SMB message signing requires a valid existing login -->
>      <init-param>
>         <param-name>jcifs.smb.client.username</param-name>
>         <param-value>xxx</param-value>
>      </init-param>
>      <init-param>
>         <param-name>jcifs.smb.client.password</param-name>
>         <param-value>xxx</param-value>
>      </init-param>
>      <!-- Set the logging level -->
>      <init-param>
>         <param-name>jcifs.util.loglevel</param-name>
>         <param-value>3</param-value>
>      </init-param>
>      <!-- allow non-IE browsers to use basic auth -->
>      <init-param>
>         <param-name>jcifs.http.insecureBasic</param-name>
>         <param-value>true</param-value>
>      </init-param>
>   </filter>
>   <filter>
>      <filter-name>HRADGroupFilter</filter-name>
>      <filter-class>xxx.ADGroupFilter</filter-class>
>      <init-param>
>         <param-name>AllowedGroups</param-name>
>         <param-value>G-HR,G-MIS</param-value>
>      </init-param>
>   </filter>
>      <filter>
>      <filter-name>SuggestionsGroupFilter</filter-name>
>      <filter-class>xxx.ADGroupFilter</filter-class>
>      <init-param>
>         <param-name>AllowedGroups</param-name>
>         <param-value>xxx, xxx</param-value>
>      </init-param>
>   </filter>
>  
>   <filter-mapping>
>      <filter-name>NtlmHttpFilter</filter-name>
>      <url-pattern>/suggestions/*</url-pattern>
>   </filter-mapping>
>   <filter-mapping>
>      <filter-name>SuggestionsGroupFilter</filter-name>
>      <url-pattern>/suggestions/*</url-pattern>
>   </filter-mapping>
>   <filter-mapping>
>      <filter-name>NtlmHttpFilter</filter-name>
>      <url-pattern>/xxx/*</url-pattern>
>   </filter-mapping>
>   <filter-mapping>
>      <filter-name>HRADGroupFilter</filter-name>
>      <url-pattern>/xxx/xxx.do</url-pattern>
>   </filter-mapping>
>
>
> So, are you saying to just remove the following from the above?:
>     <filter-name>NtlmHttpFilter</filter-name>
>     <filter-class>jcifs.http.NtlmHttpFilter</filter-class>
>
> Is there anything else in there that needs to be removed? Sorry for my lack of understanding, but this was all developed by previous developers, who are no longer working here and have left no documentation.
>

Neither I nor the other contributors on this list knows what your application(s) really
do, nor how your whole system really fits together.
In addition, this list is for the support of Tomcat, and your issue is not really with
Tomcat, but seems to be really at the application level and how this application
a) performs user authentication
b) later uses the results of the user authentication
The fact that there is no documentation and that the relevant delevelopers have left is a
pity, but not really something we can do anything about.

What I really suggest, if this application is important for you (and apart from what Chuck
already mentioned) is this : get in touch with the Jespa authors, at www.ioplex.com (email
: support@(protected).

Maybe first though : download the Jespa Operator's Guide from their website, and read it.
That will already tell you a lot of what you need to know.

Replacing the jCIFS HTTP filter by Jespa is not very hard, and mostly consists of
installing Jespa and modifying the web.xml to use the Jespa filter instead of the jCIFS
filter. That would be the following sections of your current web.xml :

> <filter>
>      <filter-name>NtlmHttpFilter</filter-name>
>      <filter-class>jcifs.http.NtlmHttpFilter</filter-class>
>
>      <!--
>         always needed for preauthentication / SMB signatures
>      -->
>      <init-param>
>         <param-name>jcifs.smb.client.domain</param-name>
>         <param-value>xxx</param-value>
>      </init-param>
>      <!-- SMB message signing requires a valid existing login -->
>      <init-param>
>         <param-name>jcifs.smb.client.username</param-name>
>         <param-value>xxx</param-value>
>      </init-param>
>      <init-param>
>         <param-name>jcifs.smb.client.password</param-name>
>         <param-value>xxx</param-value>
>      </init-param>
>      <!-- Set the logging level -->
>      <init-param>
>         <param-name>jcifs.util.loglevel</param-name>
>         <param-value>3</param-value>
>      </init-param>
>      <!-- allow non-IE browsers to use basic auth -->
>      <init-param>
>         <param-name>jcifs.http.insecureBasic</param-name>
>         <param-value>true</param-value>
>      </init-param>
>   </filter>

and

>   <filter-mapping>
>      <filter-name>NtlmHttpFilter</filter-name>
>      <url-pattern>/suggestions/*</url-pattern>
>   </filter-mapping>

and

>   <filter-mapping>
>      <filter-name>NtlmHttpFilter</filter-name>
>      <url-pattern>/xxx/*</url-pattern>
>   </filter-mapping>

The sections above have a direct equivalent with Jespa, and there should in principle not
be any code changes to make in your applications.
Just the parameters in web.xml differ somewhat.

Both the jCIFS filter and the Jespa filter are servlet filters, and they basically do the
same thing :
- authenticate the current user of the application with the Windows Domain Controllers
(and whatever is used as their back-end authentication mechanism)
- "set" the internal "Tomcat user" to this user-id

Then, after that, runs the other filters that are configured above, and your application.
What they do with whatever information the authentication filter (jCIFS or Jespa) has
passed to Tomcat, we do not know, and there could be a problem there (but more likely not).
If there was a problem, then the people most likely to be able to help you are the Jespa guys.


In theory, there could be another way : replace this "application-level" filter-based
authentication by a container-level authentication (and get rid of the filters), but in
your current situation, I believe that the Jespa solution is really the simplest one.

And, really, consider upgrading your Tomcat version. Nothing which you are currently
using is supported anymore.


Attachment: users_242941.eml (zipped)


> Date: Thu, 1 Aug 2013 15:55:37 +0200
> From: aw@(protected)
> To: users@(protected)
> Subject: Re: java.net.UnknownHostException: Failed to negotiate with a suitable domain controller for xxx
>
> Seema Patel wrote:
> >
> >> Date: Thu, 1 Aug 2013 12:06:39 +0200
> >> From: aw@(protected)
> >> To: users@(protected)
> >> Subject: Re: java.net.UnknownHostException: Failed to negotiate with a suitable domain controller for xxx
> >>
> >> Seema Patel wrote:
> >>> Hi,
> >>>
> >>> I am not sure if this is the right List to post this on, please advise if it isn't and let me know where is best to post.
> >>>
> >>> I am getting the following error on one of our applications running on our intranet:
> >>>
> >>> 2013-07-31 17:15:11,180 [http-xxx.xxx.x.xxx-xx-x] ERROR org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/forms].[action] - Servlet.service() for servlet action threw exception
> >>> java.net.UnknownHostException: Failed to negotiate with a suitable domain controller for xxx.LOCAL
> >>> at jcifs.smb.SmbSession.getChallengeForDomain(SmbSession.java:187)
> >>> at jcifs.http.NtlmHttpFilter.negotiate(NtlmHttpFilter.java:150)
> >>> at jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:114)
> >>> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:215)
> >>> at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:188)
> >>> at org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:213)
> >>> at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:172)
> >>> at org.apache.catalina.authenticator.AuthenticatorBase.invoke (AuthenticatorBase.java:465)
> >>> at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:127)
> >>> at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:117)
> >>> at org.apache.catalina.authenticator.SingleSignOn.invoke (SingleSignOn.java:393)
> >>> at org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:108)
> >>> at org.apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.java:174)
> >>> at org.apache.coyote.http11.Http11AprProcessor.process (Http11AprProcessor.java:837)
> >>> at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:640)
> >>> at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1287)
> >>> at java.lang.Thread.run(Unknown Source)
> >>>
> >> I believe that you should read this page carefully, in particular the blue text at the
> >> beginning : http://jcifs.samba.org/src/docs/ntlmhttpauth.html
> >>
> >> Can you have a look at the WEB-INF/web.xml file *of your application*, and check if there
> >> is a servlet filter configured there, which matches the name above ?
> >>
> >> If so, make a backup copy of that web.xml file, and then edit it to remove that filter
> >> from it, and try again.
> >> I am not quite sure, but it looks possible to me that you have a duplicate authentication
> >> mechanism in use : one at the container (Tomcat) level, and one at the application level.
> >> And the one used at the application level is obsolete, unsupported, unmaintained etc..
> >>
> >
> > I have found out that JCIFS is no longer supported, but it will take a lot of time, development and resources to update it to the recommended Jespa. In my web.xml file I have the following:
> >
> > <filter>
> >      <filter-name>NtlmHttpFilter</filter-name>
> >      <filter-class>jcifs.http.NtlmHttpFilter</filter-class>
> >        
> >      <!--
> >         always needed for preauthentication / SMB signatures
> >      -->
> >      <init-param>
> >         <param-name>jcifs.smb.client.domain</param-name>
> >         <param-value>xxx</param-value>
> >      </init-param>
> >      <!-- SMB message signing requires a valid existing login -->
> >      <init-param>
> >         <param-name>jcifs.smb.client.username</param-name>
> >         <param-value>xxx</param-value>
> >      </init-param>
> >      <init-param>
> >         <param-name>jcifs.smb.client.password</param-name>
> >         <param-value>xxx</param-value>
> >      </init-param>
> >      <!-- Set the logging level -->
> >      <init-param>
> >         <param-name>jcifs.util.loglevel</param-name>
> >         <param-value>3</param-value>
> >      </init-param>
> >      <!-- allow non-IE browsers to use basic auth -->
> >      <init-param>
> >         <param-name>jcifs.http.insecureBasic</param-name>
> >         <param-value>true</param-value>
> >      </init-param>
> >   </filter>
> >   <filter>
> >      <filter-name>HRADGroupFilter</filter-name>
> >      <filter-class>xxx.ADGroupFilter</filter-class>
> >      <init-param>
> >         <param-name>AllowedGroups</param-name>
> >         <param-value>G-HR,G-MIS</param-value>
> >      </init-param>
> >   </filter>
> >      <filter>
> >      <filter-name>SuggestionsGroupFilter</filter-name>
> >      <filter-class>xxx.ADGroupFilter</filter-class>
> >      <init-param>
> >         <param-name>AllowedGroups</param-name>
> >         <param-value>xxx, xxx</param-value>
> >      </init-param>
> >   </filter>
> >  
> >   <filter-mapping>
> >      <filter-name>NtlmHttpFilter</filter-name>
> >      <url-pattern>/suggestions/*</url-pattern>
> >   </filter-mapping>
> >   <filter-mapping>
> >      <filter-name>SuggestionsGroupFilter</filter-name>
> >      <url-pattern>/suggestions/*</url-pattern>
> >   </filter-mapping>
> >   <filter-mapping>
> >      <filter-name>NtlmHttpFilter</filter-name>
> >      <url-pattern>/xxx/*</url-pattern>
> >   </filter-mapping>
> >   <filter-mapping>
> >      <filter-name>HRADGroupFilter</filter-name>
> >      <url-pattern>/xxx/xxx.do</url-pattern>
> >   </filter-mapping>
> >
> >
> > So, are you saying to just remove the following from the above?:
> >     <filter-name>NtlmHttpFilter</filter-name>
> >     <filter-class>jcifs.http.NtlmHttpFilter</filter-class>
> >
> > Is there anything else in there that needs to be removed? Sorry for my lack of understanding, but this was all developed by previous developers, who are no longer working here and have left no documentation.
> >
>
> Neither I nor the other contributors on this list knows what your application(s) really
> do, nor how your whole system really fits together.
> In addition, this list is for the support of Tomcat, and your issue is not really with
> Tomcat, but seems to be really at the application level and how this application
> a) performs user authentication
> b) later uses the results of the user authentication
> The fact that there is no documentation and that the relevant delevelopers have left is a
> pity, but not really something we can do anything about.
>
> What I really suggest, if this application is important for you (and apart from what Chuck
> already mentioned) is this : get in touch with the Jespa authors, at www.ioplex.com (email
> : support@(protected).
>
> Maybe first though : download the Jespa Operator's Guide from their website, and read it.
> That will already tell you a lot of what you need to know.
>
> Replacing the jCIFS HTTP filter by Jespa is not very hard, and mostly consists of
> installing Jespa and modifying the web.xml to use the Jespa filter instead of the jCIFS
> filter. That would be the following sections of your current web.xml :
>
> > <filter>
> >      <filter-name>NtlmHttpFilter</filter-name>
> >      <filter-class>jcifs.http.NtlmHttpFilter</filter-class>
> >
> >      <!--
> >         always needed for preauthentication / SMB signatures
> >      -->
> >      <init-param>
> >         <param-name>jcifs.smb.client.domain</param-name>
> >         <param-value>xxx</param-value>
> >      </init-param>
> >      <!-- SMB message signing requires a valid existing login -->
> >      <init-param>
> >         <param-name>jcifs.smb.client.username</param-name>
> >         <param-value>xxx</param-value>
> >      </init-param>
> >      <init-param>
> >         <param-name>jcifs.smb.client.password</param-name>
> >         <param-value>xxx</param-value>
> >      </init-param>
> >      <!-- Set the logging level -->
> >      <init-param>
> >         <param-name>jcifs.util.loglevel</param-name>
> >         <param-value>3</param-value>
> >      </init-param>
> >      <!-- allow non-IE browsers to use basic auth -->
> >      <init-param>
> >         <param-name>jcifs.http.insecureBasic</param-name>
> >         <param-value>true</param-value>
> >      </init-param>
> >   </filter>
>
> and
>
> >   <filter-mapping>
> >      <filter-name>NtlmHttpFilter</filter-name>
> >      <url-pattern>/suggestions/*</url-pattern>
> >   </filter-mapping>
>
> and
>
> >   <filter-mapping>
> >      <filter-name>NtlmHttpFilter</filter-name>
> >      <url-pattern>/xxx/*</url-pattern>
> >   </filter-mapping>
>
> The sections above have a direct equivalent with Jespa, and there should in principle not
> be any code changes to make in your applications.
> Just the parameters in web.xml differ somewhat.
>
> Both the jCIFS filter and the Jespa filter are servlet filters, and they basically do the
> same thing :
> - authenticate the current user of the application with the Windows Domain Controllers
> (and whatever is used as their back-end authentication mechanism)
> - "set" the internal "Tomcat user" to this user-id
>
> Then, after that, runs the other filters that are configured above, and your application.
> What they do with whatever information the authentication filter (jCIFS or Jespa) has
> passed to Tomcat, we do not know, and there could be a problem there (but more likely not).
> If there was a problem, then the people most likely to be able to help you are the Jespa guys.
>
>
> In theory, there could be another way : replace this "application-level" filter-based
> authentication by a container-level authentication (and get rid of the filters), but in
> your current situation, I believe that the Jespa solution is really the simplest one.
>
> And, really, consider upgrading your Tomcat version. Nothing which you are currently
> using is supported anymore.

When upgrading Tomcat from version 5.5 to 7, would I need to upgrade to version 6 first and then to 7 or can I go straight from 5.5 to 7?
I will first try all this in a test environment. Please bare with me, I may come back with further questions to your responses.
But thanks for all the feedback, its appreciated (especially as I'm a newbie to this).



> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@(protected)
> For additional commands, e-mail: users-help@(protected)
>
           

Attachment: users_242935.eml (zipped)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Ilya,

On 7/31/13 3:11 PM, Ilya Kazakevich wrote:
> They may use RemoteIpValve to fetch "real" ip from
> "x-forwarded-for" and set it to "remote_addr" where getRemoteAddr
> will get it.

+1

Assuming you can "modify" the webapp by inserting a Valve, you can use
it to do exactly what you want to do:

http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Remote_IP_Valve

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJR+l8/AAoJEBzwKT+lPKRY1oEQAIBga6U1jQdOXA217pVaZ9K5
6e6LRVuZfebUwztrHdN64MiHglGdtIOLOB+yZC4pCd3yvH+PfaHOZdyKrEY7osoI
aXBBy40S1u+1YQGvovfVhMRO4UUUs7S5jxkQNlvHtib7VVoILUBfHDf0cW2tilRf
SPAwvn3p1DeAuNq/m+VruRNDwHD270j9+OO0TSh+rWR6TK2XaSNIJ6eb4hWdmvPV
CoISQpadS8l4XawW09wrKKq7EN0WOrhKgj9o2U4fIQfayX8T3rvaLu1LQpHunEWV
Z9Cs3eliP09Uxhi2VWov5cx2mf9pxtLu3p+0400s/9MqHjutT6rkEOyuvs7BPtRD
JJ3wlrWY3Ah9SrFxHKv7FdJ5ycS5BX9+x+KzvIuuBUTDg/nB7Uz2aF1AwSzws2lI
5YSkw+5dRpnZqz2GY3W8gYwLjSLImYuPgJhWCiel/6I13HcwFllseR9GqxWXx0Zj
g0ChufG/WtVusH/uBcAt5FTUNfepiMBaYjjsZfG2VR7PQT64U3GqcHmeIf+OzOUH
oEIknGvozRWMytqGs8ZZ934vtX2mMkwqkpvlMS1sfor7KLDLWtIDEIR56DrXpecp
02y85wHZkf3FiPHR2QhDYKwWnhGg+3vknogPBgtWsgv6gLd130+jv/gBnlGzJC6T
H2gbsz1RLKEWvVEITxSb
=BAxw
-----END PGP SIGNATURE-----


Attachment: users_242936.eml (zipped)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Sol,

On 7/31/13 5:32 PM, sol myr wrote:
> Has anyone happened to stumble onto this issue, please: Our Ajax
> works perfectly as long as its non-secure. However, when switching
> to SSL we sometimes see 408 errors (incomplete request). This only
> happens on ajax, and inconsistently (similar requests might succeed
> on one moment, but fail on the other).
>
> Please note: 1. Our client is Chrome browser, using JQuery for
> ajax 2. Server is Tomcat 7 3. Network is fast and stable, and the
> ajax requests are small 4. Problem occurs for both our connectors:
> APR and Http (both with SSL enabled) 5. Our x509 certificate is
> valid (otherwise it would have failed on *all* ajax ssl requests,
> not to mention the non-ajax ssl)

How often is "sometimes"? Can you give a rough idea of the volume you
are serving, and what percentage seem to be failing? Is there any
pattern -- like certain IP addresses fail more often than others, etc.?

Do you have mobile clients? Or is all your testing local?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJR+mAeAAoJEBzwKT+lPKRYWNMP/iPaCTc07jMkpJ079rYB/R1H
aDb8rIrXMdEXb4iMqNiMRg3PlFpu5CfM2Z5XYClhpbdkFs6EW9lyD7KRPyPseFyg
G4TleXSCaKYCMlhOmW4biM3HE9Dj1+H2UEI+q4qcQWE3K0+PvQCB6IADg6Q1mT2y
bV7Yv5nOIyZY9Wq7LGTPe9TAfInfdPohb/fT5deu9vEhb/3bj+nbIbwrAfKXEfic
lpockmZxiq/tkQA1Ijjfi6nXkItmR+0VjQa+wHKg6lW43XHq3UCA4AVsH3cZde5C
K74WOv8OosTmacyeKeze/kNFtpf6HrkoSPfJ7OVP966iQ9RmYHMBf/t2X0Qe45Lt
vcjOMZCVAWzjqsJKe71Mi3WgDmqbGOyGYq0jTpI39CdqU/71juyQMxJe0mpJpUPk
MGjBWQYXg1cSCKSQjDPsdUSN7uRZfo9dmMQrcVyOcI5UAmap95KciyGeW1z8PKs8
x0E8bP2/c38INdGHAbbjgGwVacnav37VKNn0Yky4eCWjiMFwoym3L/eL/DvrtGVu
Be4V3ei7Dzju7R9x90KaumpG4OzC+SUI9oCFgDiVgbN5yQwsuP8Gaz0A/RCqdJFZ
EhvCbNKog9JU8hTmeCUiH/ACGzW7RjWFl8KZgZzmxbLHRGOjc3BGRIXKtB1G7OjU
o6LNmVxkLXLHERIleY4d
=zy5F
-----END PGP SIGNATURE-----


Attachment: users_242939.eml (zipped)
> -----Original Message-----
> From: André Warnier [mailto:aw@(protected)]
> Sent: Wednesday, July 31, 2013 12:27 PM
> To: Tomcat Users List
> Subject: Re: Cannot start apache tomcat 7.0 if server path contains two
> consecutive spaces.
>
> TRAN Trung Thanh wrote:
> > Hi all,
> > I am newbie here.
> > Today, I tried to start apache tomcat 7.0.42 in Linux environment.
> > Server path contains two consecutive spaces. When I run ./catalina.sh
> > run, server cannot start and there is the following exception in
> > console
> >
> > ./catalina.sh run
> > Using CATALINA_BASE:  /home/example/twoconsecutive spaces
> > Using CATALINA_HOME:  /home/example/twoconsecutive spaces
> > Using CATALINA_TMPDIR: /home/example/twoconsecutive spaces/temp
> > Using JRE_HOME:     /home/example/java/jdk1.6
> > Using CLASSPATH:     /home/example/twoconsecutive
> > spaces/bin/bootstrap.jar:/home/example/twoconsecutive
> > spaces/bin/tomcat-juli.jar
> > Exception in thread "main" java.lang.NoClassDefFoundError:
> > org/apache/catalina/startup/Bootstrap
> > Caused by: java.lang.ClassNotFoundException:
> > org.apache.catalina.startup.Bootstrap
> >   at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> >   at java.security.AccessController.doPrivileged(Native Method)
> >   at java.net.URLClassLoader.findClass (URLClassLoader.java:190)
> >   at java.lang.ClassLoader.loadClass (ClassLoader.java:306)
> >   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> >   at java.lang.ClassLoader.loadClass (ClassLoader.java:247)
> > Could not find the main class: org.apache.catalina.startup.Bootstrap.
> > Program will exit.
> >
> > Tomcat server can start if server path does not contain consecutive
> space.
> >
> > Do anyone face to the same issue with me in this case? Have you any
> > suggestion to fix this issue?
>
> Yes : don't do that (using spaces in paths).
>
>   It is quite important for my deployment.
> >
>
> That's a pity.
> Spaces in paths (and filenames) are evil, and should never have been
> allowed in the first place. A special place in hell is reserved for
> the genius who first allowed this stupid thing in an OS. I wish I had
> 0.1 cent for every programming hour lost because of this.
>
> Technically, you can certainly find the correct way to quote them in
> any particular place and environment. But usually, this is merely
> moving the problem to some other place further down the line, where it
> is even less visible and harder to find the bugs.
> I suppose the same could be said about any non-visible character, but
> spaces (along with
> TAB) are specially evil because in most environments, they are
> considered either as valid separators between words/tokens or as "non-
> significant".
>
> My serious recommendation would be to think really hard about a way to
> nip this in the bud, and avoid allowing them and using them in the
> first place.
> Think that if you allow them somewhere, and even if you quote them
> correctly there, you will have to continue quoting them (appropriately)
> everywhere else that you are using the corresponding strings. It is
> almost guaranteed that this will bite you somewhere.
>
>

Agree with everything Andre says here. Even under Windows, where the OS seems to handle it fine, as long as you're in the GUI, it is a problem. You have to remember to quote the path everytime you want to use it at the command line level, or in PowerShell, etc.
It is really easier to remember that if you want the look of a space, but need a non-printable character, to just use the underbar. How much easier things could be if instead of "My Documents" you could write My_Documents. Still looks like two words but it is only one.
As long as you have control over the naming, you should follow this advise.
Jeff


©2008 junlu.com - Jax Systems, LLC, U.S.A.