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.
