[jcifs] 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:mba2000 at ioplex.com] 
Sent: Thursday, March 16, 2006 5:18 PM
To: Aleksandr Sharikov
Cc: jcifs at samba.org
Subject: Re: PLEASE HELP:Problem with JCIFS

On Thu, 16 Mar 2006 19:01:23 -0500
"Aleksandr Sharikov" <ashariko at opentext.com> 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