Re: PLEASE HELP:Problem with JCIFS

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: PLEASE HELP:Problem with JCIFS

Michael B Allen-4
On Thu, 16 Mar 2006 19:01:23 -0500
"Aleksandr Sharikov" <[hidden email]> wrote:

>
> Mike,
>
> Would you please to take a look on a couple captured files I collected
> from our customer?
>
> We is using JCIFS to do SingleSignOn access to our web application. In
> house everything works fine.
> When customer uses IE LOCALLY on the same computer where Tomcat is
> installed everything works.
> However when the customer from the same domain tries to connect to the
> same web application, he gets "page not found".
> I see from captured file that server sends challenge to client browser
> and client responds, but server does not responds after that.
>
> Host computer is Windows2003. I tried to use username/password for
> "preauthentication", but it did not work. So I returned to use
> domainController share approach but put there just in case domain and
> wins too. No username. password entries now in web.xml. I have only
> domain, wins,domaincontroller,share,loglevel tags.

If you use domainController you don't need domain unless you're doing
preauth. Also, if you're having a problem you might try removing the
logonShare thingy while you're testing.

>
>  <<cap.zip>>
> I attached 2 Ethereal capture files 1st for success case when we use
> browser locally, and 2nd for failed case when we used browser on remote
> computer.

In the first capture HTTP Negotiate authentication is used. Kerberos is
negotiated. The JCIFS filter uses HTTP NTLM authentiction. So the JCIFS
filter wasn't being used at all. I suspect you're running on IIS
and IIS has integrated authentication turned on so it intercepted the
authentication before reaching the Filter.

In the second capture HTTP NTLM authentication IS being negotiated but
you're right it's strangely not completing. What's strange is the auth
handshake is supposed to look like this:

1 C: GET
2 S: Unauthorized, WWW-Authenticate: NTLM
3 C: GET, Authorization: <base64 encoded token 1>
4 S: Unauthorized, WWW-Authenticate: NTLM <base64 encoded token 2>
5 C: GET, Authorization: <base64 encoded token 3>
6 S: 200 OK ... data

The server does step 4 but the client never does step 5. Why it's aborting
right before the last step I have no idea.

In general I would say there is some kind of configuration or policy
issue with the client. But JCIFS seems like it's doing it's job. I mean
it sends token 2 so it's up to the client (IE) to send the final request.

Unfortunately I'm not going to be available much for the next week. I CC'd
the list. Maybe someone has seen this problem before?

Mike
Reply | Threaded
Open this post in threaded view
|

RE: PLEASE HELP:Problem with JCIFS

Aleksandr Sharikov
Mike,

Thanks you very much for the fast response.

There is no IIS there. We use only Tomcat 5.025.

I forgot to tell that I tried also to set lmCompatibility level to the
value in the registry, but it was not working and I removed it.

I tried to configurate client IE:
1.
put site in trusted zone in IE,
2.
use (a) authenticate automatically on Intranet OR (b) Use current names
for login.

Nothing works there. But works very well in house.

What else can I do with client browser settings so the browser will send
the last request?

Thanks

Alex



-----Original Message-----
From: Michael B Allen [mailto:[hidden email]]
Sent: Thursday, March 16, 2006 5:18 PM
To: Aleksandr Sharikov
Cc: [hidden email]
Subject: Re: PLEASE HELP:Problem with JCIFS

On Thu, 16 Mar 2006 19:01:23 -0500
"Aleksandr Sharikov" <[hidden email]> wrote:

>
> Mike,
>
> Would you please to take a look on a couple captured files I collected

> from our customer?
>
> We is using JCIFS to do SingleSignOn access to our web application. In

> house everything works fine.
> When customer uses IE LOCALLY on the same computer where Tomcat is
> installed everything works.
> However when the customer from the same domain tries to connect to the

> same web application, he gets "page not found".
> I see from captured file that server sends challenge to client browser

> and client responds, but server does not responds after that.
>
> Host computer is Windows2003. I tried to use username/password for
> "preauthentication", but it did not work. So I returned to use
> domainController share approach but put there just in case domain and
> wins too. No username. password entries now in web.xml. I have only
> domain, wins,domaincontroller,share,loglevel tags.

If you use domainController you don't need domain unless you're doing
preauth. Also, if you're having a problem you might try removing the
logonShare thingy while you're testing.

>
>  <<cap.zip>>
> I attached 2 Ethereal capture files 1st for success case when we use
> browser locally, and 2nd for failed case when we used browser on
> remote computer.

In the first capture HTTP Negotiate authentication is used. Kerberos is
negotiated. The JCIFS filter uses HTTP NTLM authentiction. So the JCIFS
filter wasn't being used at all. I suspect you're running on IIS and IIS
has integrated authentication turned on so it intercepted the
authentication before reaching the Filter.

In the second capture HTTP NTLM authentication IS being negotiated but
you're right it's strangely not completing. What's strange is the auth
handshake is supposed to look like this:

1 C: GET
2 S: Unauthorized, WWW-Authenticate: NTLM
3 C: GET, Authorization: <base64 encoded token 1>
4 S: Unauthorized, WWW-Authenticate: NTLM <base64 encoded token 2>
5 C: GET, Authorization: <base64 encoded token 3>
6 S: 200 OK ... data

The server does step 4 but the client never does step 5. Why it's
aborting right before the last step I have no idea.

In general I would say there is some kind of configuration or policy
issue with the client. But JCIFS seems like it's doing it's job. I mean
it sends token 2 so it's up to the client (IE) to send the final
request.

Unfortunately I'm not going to be available much for the next week. I
CC'd the list. Maybe someone has seen this problem before?

Mike
Reply | Threaded
Open this post in threaded view
|

Re: PLEASE HELP:Problem with JCIFS

Oliver Schoett
Aleksandr Sharikov wrote:
> Nothing works there. But works very well in house.
>  
The phrase "in house" suggests that the client having problems is
located at another site.  How is that site connected to the server
site?  Since NTLM auth is connection-based, you cannot have a proxy
between browser and server (a proxy is required to maintain different
TCP connections to the client and to the server).

This also rules out a firewall with an HTTP proxy between client and
server.  VPN connections, packet filters and routers doing NAT should
work, as they do allow a proper TCP connection between client and server.

Regards,

Oliver Schoett