> 1.3.6.1.4.1.311.2.2.10 is NTLM which has a much smaller token size. Java
> does not support NTLM as a GSS-API mechanism.
Yes. So it looks like the browser is preferring NTLM and pre-emptively sending
a token for that.
> I am not sure how this happens. Normally you need to configure the browser
> (For example, somewhere in about:config for Firefox) on which server you can
> use SPNEGO. Maybe you set up one and ignored the other?
Chrome uses the normal Windows "internet options" configuration for this. You
configure "zones" and one of the settings is "allow windows integrated
authentication". Both machines in my case are in the same domain, so I *think*
that it should be attempting the same kind of authentication. But I've no idea
how I tell (well, other than the fact that the lists of mechanism OIDs it sends
are different, so there must be *some* difference)
I get exactly the same result if I try from Firefox. Adding my host into the
network.negotiate-auth.trusted-uris configuration setting doesn't have any
effect. Well, without it firefox doesn't seem to do anything, but with it I get
exactly the same behaviour of mechanism OIDs being sent.
I also get the same behaviour if I use a C++ HTTP client I have that just uses
Windows SSPI "negotiate" package to do the same thing, but my guess is that's
subject to the same basic configuration in terms of what mechanisms it will put
in its list.
> BTW, I assume you are using a single Windows KDC with 2 service principals
> HTTP/windows.server and HTTP/linux.server and different keytab used on those
> 2 servers. Is that correct?
I am, yes. I have successfully run a "java to java" example using the same
keytab I'm using for this experiment, so I've successfully used a java client
to perform the same authentication (at a lower level, directly, not going over
HTTP, just JGSS talking to JGSS if you know what I mean, as a "unit test" of
the basic code that's accepting the token that comes out of the HTTP header and
attempts to perform the authentication), so I believe that the keytab is OK,
and I believe that the KDC will accept my requests to authenticate users.
However I have had difficulties getting that far. The Linux set up worked
easily, but the Windows setup was more complex, there needs to be an actual
user principal as well as the HTTP service principal. I *believe* that I'm
passed that now though.
Issue JDK-8048194 has the same set of mechanism OIDs, and has the same basic
symptom, but I'm unclear whether the issue is the same or not there.
The fact that the client request contains Kerberos in the mechanism OIDs
suggests to me that it would be happy to process a Kerberos authentication,
it's just that its first choice would be NTLM. I'm assuming that the response
that the java sends back is "I can't accept your first choice, but this OID is
on your list and I will accept that, so send me a token for that mechanism
please". The browser response to that though appears to be a token that the
java code can't read, and the error appears to come before any of the debugging
output that prints any of the token information.
Naively, I assume that the fact that the client and the server are on the same
machine isn't an issue?
Thanks for any help you can give me!
