Works fine on windows client but not unix client?

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

Works fine on windows client but not unix client?

MrKimi
I am using jcifs to authenticate web service requests and if works just fine when we go from Windows to Windows.
But when we go from unix to windows it doesn't play. Specifically what happens is the initial (unauthorised) request is rejected as usual and the second request is sent but with no body. It looks like this:

content-length: 692
Content-Type: text/xml; charset=utf-8
accept: application/soap+xml, application/dime, multipart/related, text/*
soapaction: "http://adhb.govt.nz/PatientSearchOrGetFromXml"
Authorization: Negotiate TlRMTVNTUAABAAAAASIAAAAAAAAAAAAACwALACAAAABKQ0lGUzBfMV9BRA==
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Java/1.4.2_08
Host: 127.0.0.1:1234
Connection: keep-alive

I notice the 'Authorization: Negotiate', where the equivalent when there is a windows client is 'Authorization: NTLM', otherwise the requests look the same, except the windows one had a body and a longer length.

I'm thinking there is some config setting on the unix box we need to set which defaults the right way on Windows.
Any thoughts?
Thanks
Roger
--

Roger Parkinson
+64 21 508 792


roger.vcf (209 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Works fine on windows client but not unix client?

Michael B Allen-4
On Wed, 15 Feb 2006 12:52:36 +1300
Roger Parkinson <[hidden email]> wrote:

Stangely my mailer will not include anything but your vcard in my reply.

Anyway, the servlet container must be offering WWW-Authenticate:
Negotiate. The JCIFS Filter is also offering WWW-Authenticate: NTLM
but the client (firefox?) is choosing Negotiate (whereas the Windows
client is choosing NTLM). You would need a full capture [1] to see
what's really going on but clearly there's some form of interference
from another authentiaction filter.

I'm assuming of course that you're using the stock filter without
any modifications or non-standard properties or you surely would have
mentioned otherwise.

Mike

[1] http://jcifs.samba.org/capture.html
Reply | Threaded
Open this post in threaded view
|

Re: Works fine on windows client but not unix client?

MrKimi
This sounds, promising, thanks.
I am using the stock jcifs1.2.7 filter (fair question!)
The server is IIS running a .NET web service (so no jcifs code involved at that end)
The client is a just a java program deployed as a jar file and running under a shell script, and that is, of course, where jcifs is used.
I do have tons of capture files lying around now, but the snippet I showed earlier is where the difference between the windows and the unix client shows up.

So, how come the unix client is chosing 'Negotiate'? Is it just that it is non-windows. I imagine that a client running on windows would be more likely to choose NTLM by default. Is it necessarily a problem that it wants to Negotiate? By that I mean is the IIS server capable of negotiating or does it reject non NTLM requests? If the latter then what am I looking for at the unix end?

I'm guessing there is some System property that needs to be set somewhere (or perhaps unset), but that's just a guess.
Thanks
Roger


Michael B Allen wrote:
On Wed, 15 Feb 2006 12:52:36 +1300
Roger Parkinson [hidden email] wrote:

Stangely my mailer will not include anything but your vcard in my reply.

Anyway, the servlet container must be offering WWW-Authenticate:
Negotiate. The JCIFS Filter is also offering WWW-Authenticate: NTLM
but the client (firefox?) is choosing Negotiate (whereas the Windows
client is choosing NTLM). You would need a full capture [1] to see
what's really going on but clearly there's some form of interference
from another authentiaction filter.

I'm assuming of course that you're using the stock filter without
any modifications or non-standard properties or you surely would have
mentioned otherwise.

Mike

[1] http://jcifs.samba.org/capture.html



  

--

Roger Parkinson
+64 21 508 792


roger.vcf (209 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Works fine on windows client but not unix client?

Michael B Allen-4
I don't understand. You say you're using the filter but there's no
jcifs on the server? I suspect you're mistaken about what the "filter"
is and you're really just using the jcifs HTTP client wrapper. In that
case it could be that the HTTP client on windows will automatically do
authentication which bypasses the wrapper. There was recently a discussion
about this on the mailing list. Search the archives.

Mike

On Wed, 15 Feb 2006 16:14:55 +1300
Roger Parkinson <[hidden email]> wrote:

> begin:vcard
> fn:Roger Parkinson
> n:Parkinson;Roger
> adr:Ponsonby;;P O Box 47959;;;1034;New Zealand
> email;internet:[hidden email]
> tel;cell:+64 21 508 792
> x-mozilla-html:TRUE
> version:2.1
> end:vcard
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Works fine on windows client but not unix client?

MrKimi
Sorry, I misunderstood what you meant by filters. I am, indeed, using the client wrapper.

I found the thread "NTLM http client uses Sun NTLM coming with JVM 1.4.2_10 instead of jcifs" in the archives and it applies to windows to windows communications, this is unix to windows.

Can I recap?

For the testbed everything is on one machine and no domain is active. JVM is 1.5.0-05
We have a .NET based web service on IIS and a small java program that accesses it. When anonymous access is turned on for the web service everything works fine. In the live system we plan to deploy to the anonymous access is off so we need that to work too.

We turn off anonymous access and leave out any jcifs code: success (presumably the Sun NTLM is working for us here)
Put in the jcifs code and it still works ie

        jcifs.Config.registerSmbURLHandler();
        jcifs.Config.setProperty("jcifs.smb.client.username",userName);
        jcifs.Config.setProperty("jcifs.smb.client.password",password);
(username and password are valid on this machine, and it is all localhost and no domain

Next step is to pretend we aren't a windows client by using:
        System.setProperty("os.name", "something else");

And this gets us the same problem as we get on the unix box.

When I compare the headers of the request that works and the request that doesn't there is a difference in the Type 1 authorization parameter. The request that works contains NTLM and the request that doesn't contains 'Negotiate'.

I think I saw somewhere that the NTLM request can only come from a windows client for copyright reasons, so is there something I need to change on my server (IIS) so that it understands 'Negotiate'? Or is there something else I need to do to jcifs?

Thanks
Roger

Michael B Allen wrote:
I don't understand. You say you're using the filter but there's no
jcifs on the server? I suspect you're mistaken about what the "filter"
is and you're really just using the jcifs HTTP client wrapper. In that
case it could be that the HTTP client on windows will automatically do
authentication which bypasses the wrapper. There was recently a discussion
about this on the mailing list. Search the archives.

Mike

On Wed, 15 Feb 2006 16:14:55 +1300
Roger Parkinson [hidden email] wrote:

  
begin:vcard
fn:Roger Parkinson
n:Parkinson;Roger
adr:Ponsonby;;P O Box 47959;;;1034;New Zealand
[hidden email]
tel;cell:+64 21 508 792
x-mozilla-html:TRUE
version:2.1
end:vcard


    



  

--

Roger Parkinson
+64 21 508 792


roger.vcf (209 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Works fine on windows client but not unix client?

Michael B Allen-4
It doesn't work on the unix side? If you run in on unix it sends
Negotiate? JCIFS doesn't emit Negotiate. Sounds like Java 1.5 has a new
capability in which case you shouldn't need jCIFS at all on Windows or
UNIX (unless you want to imporsonate).

If IIS is rejecting Negotiate it could be that it's KDC doesn't have
a trust with your UNIX box's KDC. Or it could be that IIS simply isn't
configured for "Integrated authentication". You might even have to edit
the metabase.

  http://support.microsoft.com/?id=215383

Theres a way to do this by simply editing an XML file but I don't recall
off the top of my head how that's done.

Mike

On Thu, 16 Feb 2006 10:25:46 +1300
Roger Parkinson <[hidden email]> wrote:

> begin:vcard
> fn:Roger Parkinson
> n:Parkinson;Roger
> adr:Ponsonby;;P O Box 47959;;;1034;New Zealand
> email;internet:[hidden email]
> tel;cell:+64 21 508 792
> x-mozilla-html:TRUE
> version:2.1
> end:vcard
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Works fine on windows client but not unix client?

MrKimi
Okay I have the answer. I was setting content-length in my headers. Removing that makes the problem go away. Here is why:
When the type 1 message is sent the original headers are copied in, but the content is not. So someone expects to see n bytes of message that never arrives. The result is... a very long wait.

And just to clarify: Negotiate does get emitted by NtlmHttpURLConnection on a type 1 message if the server includes Negotiate in its www-authenticate items. IIS includes two: NTLM and Negotiate. So NtlmHttpURLConnection sends a Negotiate as its Type 1 message.

Also I reproduced this under 1.4.2-b28 running on Win2k with os.name set to 'something else', or left alone. The Sun code was masking the problem under windows to windows connections on later JVM versions (as discussed in another thread) but not on earlier ones and not on unix to windows.

Regards
Roger

Michael B Allen wrote:
It doesn't work on the unix side? If you run in on unix it sends
Negotiate? JCIFS doesn't emit Negotiate. Sounds like Java 1.5 has a new
capability in which case you shouldn't need jCIFS at all on Windows or
UNIX (unless you want to imporsonate).

If IIS is rejecting Negotiate it could be that it's KDC doesn't have
a trust with your UNIX box's KDC. Or it could be that IIS simply isn't
configured for "Integrated authentication". You might even have to edit
the metabase.

  http://support.microsoft.com/?id=215383

Theres a way to do this by simply editing an XML file but I don't recall
off the top of my head how that's done.

Mike

On Thu, 16 Feb 2006 10:25:46 +1300
Roger Parkinson [hidden email] wrote:

  
begin:vcard
fn:Roger Parkinson
n:Parkinson;Roger
adr:Ponsonby;;P O Box 47959;;;1034;New Zealand
[hidden email]
tel;cell:+64 21 508 792
x-mozilla-html:TRUE
version:2.1
end:vcard


    



  

--

Roger Parkinson
+64 21 508 792