Trouble with SPNEGO

[tom at quarendon.net]

 > 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!