Trouble with SPNEGO

[tom at quarendon.net]

I'm having trouble with getting spnego to work, and was hoping someone might help.
I'm trying to perform a "Negotiate" authentication from a browser. My browser is Chrome on Windows 10.
The endpoint I'm connecting to us a standard jetty server (it's wrapped up in karaf), but I've implemented the actual Negotate handling manually.

If I run the server on a Linux machine, using openjdk 1.8.141, it works, I can successfully authenticate.
If I run the server on a Windows machine (same desktop machine as the browser is running on), using oracle jdk 1.8.144, I can't get it to work.

I have researched around, and it looks like there are some relevant JDK issues in the past in this area (e.g, JDK-8078439, JDK-8048194), but I should have the fixes to those. However my symptoms seem very similar to these bug reports. However, since this seems very complicated to get exactly right, I suspect I've either got something wrong in my java code, or there's some issue in my machine Active Directory configuration.

The sun.security.spnego.debug trace output in the case it doesn't work is this:

SpNegoContext.acceptSecContext: receiving token = a0 74 30 72 a0 30 30 2e 06 0a 2b 06 01 04 01 82 37 02 02 0a 06 09 2a 86 48 82 f7 12 01 02 02 06 09 2a 86 48 86 f7 12 01 02 02 06 0a 2b 06 01 04 01 82 37 02 02 1e a2 3e 04 3c 4e 54 4c 4d 53 53 50 00 01 00 00 00 97 b2 08 e2 07 00 07 00 35 00 00 00 0d 00 0d 00 28 00 00 00 0a 00 d7 3a 00 00 00 0f 54 51 55 41 52 45 4e 44 4f 4e 2d 50 43 54 45 41 4d 57 50 43
SpNegoToken NegTokenInit: reading Mechanism Oid = 1.3.6.1.4.1.311.2.2.10
SpNegoToken NegTokenInit: reading Mechanism Oid = 1.2.840.48018.1.2.2
SpNegoToken NegTokenInit: reading Mechanism Oid = 1.2.840.113554.1.2.2
SpNegoToken NegTokenInit: reading Mechanism Oid = 1.3.6.1.4.1.311.2.2.30
SpNegoToken NegTokenInit: reading Mech Token
SpNegoContext.acceptSecContext: received token of type = SPNEGO NegTokenInit
SpNegoContext: negotiated mechanism = 1.2.840.113554.1.2.2
The underlying mechanism context has not been initialized
SpNegoContext.acceptSecContext: mechanism wanted = 1.2.840.113554.1.2.2
SpNegoContext.acceptSecContext: negotiated result = ACCEPT_INCOMPLETE
SpNegoContext.acceptSecContext: sending token of type = SPNEGO NegTokenTarg
SpNegoContext.acceptSecContext: sending token = a1 14 30 12 a0 03 0a 01 01 a1 0b 06 09 2a 86 48 86 f7 12 01 02 02

I then get a second request comming in, and this fails quickly with 
GSSAPI exception
GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)
        at sun.security.jgss.GSSHeader.<init>(Unknown Source)
        at sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source)
        at sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source)


When it does work, to a linux machine, I see this:
SpNegoContext.acceptSecContext: receiving token = <much longer token here>
SpNegoToken NegTokenInit: reading Mechanism Oid = 1.2.840.48018.1.2.2
SpNegoToken NegTokenInit: reading Mechanism Oid = 1.2.840.113554.1.2.2
SpNegoToken NegTokenInit: reading Mechanism Oid = 1.3.6.1.4.1.311.2.2.30
SpNegoToken NegTokenInit: reading Mechanism Oid = 1.3.6.1.4.1.311.2.2.10
SpNegoToken NegTokenInit: reading Mech Token
SpNegoContext.acceptSecContext: received token of type = SPNEGO NegTokenInit
SpNegoContext: negotiated mechanism = 1.2.840.113554.1.2.2
SpNegoContext.acceptSecContext: negotiated mech adjusted to 1.2.840.48018.1.2.2
Entered Krb5Context.acceptSecContext with state=STATE_NEW


The obvious difference here is the order of the mechanism OIDs. My first question is why this is different? It's the same browser performing both requests. So does this difference indicate something different in the kerberos service tickets the client machine has for the two services? I have had difficulties getting this far, with there being some configuration changes needed at the Active Directory level related to my Windows machine, so maybe there's still some some configuration issue there?


Tracing through the java code in SpNegoContext.java, it's clear that the condition:
                if (mechList[0].equals(mech_wanted) ||
                        (GSSUtil.isKerberosMech(mechList[0]) &&
                         GSSUtil.isKerberosMech(mech_wanted))) {

isn't true, hence GSS_acceptSecContext is never called, hence isMechContextEstablished() when it is called generates the "The underlying mechanism context has not been initialized" message. However I've no idea why that's the case.

Can someone give me more of an insight into why this isn't working for me? Given the previous bugs in this area that have been fixed, I suspect that this *can* work, which suggests to me that I've got some kind of configuration problem that is why I'm getting this. 

Thanks.