You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've asked the question over at StackOverflow but to no avail: LINK
Using the 1.0.1.RELEASE version of this project (via Grails Spring Security Kerberos plugin). I am getting "Negotiate Header was Invalid"
I found the following reply:
I've done some digging and it appears to have nothing to do with NTLM, but how the user ID is presented. If NTLM token uses a username in the form of "someuser", it doesn't work. But, if you format the user credentials in the form of DOMAIN\someuser or someuser@domain.com all is good. We've had success in cases where the user is prompted for credentials and used the DOMAIN\someuser format.
In the logs the username shows up as user@EXAMPLE.COM. I am testing in IE on Windows Server 2012 and it doesn't give me a chance to type in creds. I have to use a computer in another domain. Even why typing in creds in the format suggested I get the same error.
All the details on this issue are in the StackOverFlow link provided but here is the console output:
2019-03-20 15:05:43.684 DEBUG --- [nio-8080-exec-7] o.s.s.k.w.a.SpnegoEntryPoint : Add header WWW-Authenticate:Negotiate to http://devbox.tst.trknow.com:8080/secure/index, forward: no
2019-03-20 15:05:43.684 DEBUG --- [nio-8080-exec-7] o.s.s.k.w.a.SpnegoEntryPoint : Add header WWW-Authenticate:Negotiate to http://devbox.tst.trknow.com:8080/secure/index, forward: no
2019-03-20 15:05:55.323 DEBUG --- [io-8080-exec-10] w.a.SpnegoAuthenticationProcessingFilter : Received Negotiate Header for request http://devbox.tst.trknow.com:8080/secure/index: Negotiate YIIHKwYGKwYBBQUCoIIHHzCCBxugMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYK*Truncated*
2019-03-20 15:05:55.323 DEBUG --- [io-8080-exec-10] w.a.SpnegoAuthenticationProcessingFilter : Received Negotiate Header for request http://devbox.tst.trknow.com:8080/secure/index: Negotiate YIIHKwYGKwYBBQUCoIIHHzCCBxugMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYK*Truncated*
2019-03-20 15:05:55.324 DEBUG --- [io-8080-exec-10] .a.KerberosServiceAuthenticationProvider : Try to validate Kerberos Token
2019-03-20 15:05:55.324 DEBUG --- [io-8080-exec-10] .a.KerberosServiceAuthenticationProvider : Try to validate Kerberos Token
Found KeyTab C:\grails3projects\http-grails.keytab for HTTP/devbox.tst.trknow.com@TST.TRKNOW.COM
Found KeyTab C:\grails3projects\http-grails.keytab for HTTP/devbox.tst.trknow.com@TST.TRKNOW.COM
Entered Krb5Context.acceptSecContext with state=STATE_NEW
Java config name: null
Native config name: C:\windows\krb5.ini
Loaded from native config
>>> KeyTabInputStream, readName(): TST.TRKNOW.COM
>>> KeyTabInputStream, readName(): HTTP
>>> KeyTabInputStream, readName(): devbox.tst.trknow.com
>>> KeyTab: load() entry length: 70; type: 1
>>> KeyTabInputStream, readName(): TST.TRKNOW.COM
>>> KeyTabInputStream, readName(): HTTP
>>> KeyTabInputStream, readName(): devbox.tst.trknow.com
>>> KeyTab: load() entry length: 70; type: 3
>>> KeyTabInputStream, readName(): TST.TRKNOW.COM
>>> KeyTabInputStream, readName(): HTTP
>>> KeyTabInputStream, readName(): devbox.tst.trknow.com
>>> KeyTab: load() entry length: 78; type: 23
>>> KeyTabInputStream, readName(): TST.TRKNOW.COM
>>> KeyTabInputStream, readName(): HTTP
>>> KeyTabInputStream, readName(): devbox.tst.trknow.com
>>> KeyTab: load() entry length: 94; type: 18
>>> KeyTabInputStream, readName(): TST.TRKNOW.COM
>>> KeyTabInputStream, readName(): HTTP
>>> KeyTabInputStream, readName(): devbox.tst.trknow.com
>>> KeyTab: load() entry length: 78; type: 17
Looking for keys for: HTTP/devbox.tst.trknow.com@TST.TRKNOW.COM
Added key: 17version: 14
Added key: 18version: 14
Added key: 23version: 14
Found unsupported keytype (3) for HTTP/devbox.tst.trknow.com@TST.TRKNOW.COM
Found unsupported keytype (1) for HTTP/devbox.tst.trknow.com@TST.TRKNOW.COM
>>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType
Using builtin default etypes for permitted_enctypes
default etypes for permitted_enctypes: 18 17 16 23.
>>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType
MemoryCache: add 1553108589/041556/905183D04DE02C32E30F1CE01B5F9AC2/bmoe.dev@TST.TRKNOW.COM to bmoe.dev@TST.TRKNOW.COM|HTTP/devbox.tst.trknow.com@TST.TRKNOW.COM
>>> KrbApReq: authenticate succeed.
Krb5Context setting peerSeqNumber to: 710158400
>>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType
Krb5Context setting mySeqNumber to: 59568554
>>> Constrained deleg from GSSCaller{UNKNOWN}
2019-03-20 15:05:56.104 DEBUG --- [io-8080-exec-10] .a.KerberosServiceAuthenticationProvider : Succesfully validated bmoe.dev@TST.TRKNOW.COM
2019-03-20 15:05:56.104 DEBUG --- [io-8080-exec-10] .a.KerberosServiceAuthenticationProvider : Succesfully validated bmoe.dev@TST.TRKNOW.COM
2019-03-20 15:05:56.289 WARN --- [io-8080-exec-10] w.a.SpnegoAuthenticationProcessingFilter : Negotiate Header was invalid: Negotiate YIIHKwYGKwYBBQUCoIIHHzCCBxugMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYK*Truncate*
grails.plugin.springsecurity.userdetails.NoStackUsernameNotFoundException: User not found
2019-03-20 15:05:56.289 WARN --- [io-8080-exec-10] w.a.SpnegoAuthenticationProcessingFilter : Negotiate Header was invalid: Negotiate YIIHKwYGKwYBBQUCoIIHHzCCBxugMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYK*Truncate*
grails.plugin.springsecurity.userdetails.NoStackUsernameNotFoundException: User not found
The text was updated successfully, but these errors were encountered:
I've asked the question over at StackOverflow but to no avail: LINK
Using the 1.0.1.RELEASE version of this project (via Grails Spring Security Kerberos plugin). I am getting "Negotiate Header was Invalid"
I found the following reply:
I've done some digging and it appears to have nothing to do with NTLM, but how the user ID is presented. If NTLM token uses a username in the form of "someuser", it doesn't work. But, if you format the user credentials in the form of
DOMAIN\someuser
orsomeuser@domain.com
all is good. We've had success in cases where the user is prompted for credentials and used theDOMAIN\someuser
format.Originally posted by @damnhandy in #89 (comment)
In the logs the username shows up as
user@EXAMPLE.COM
. I am testing in IE on Windows Server 2012 and it doesn't give me a chance to type in creds. I have to use a computer in another domain. Even why typing in creds in the format suggested I get the same error.All the details on this issue are in the StackOverFlow link provided but here is the console output:
The text was updated successfully, but these errors were encountered: