Within my web application I'm seeing this stack trace:
javax.servlet.ServletException: GSSException: Failure unspecified at GSS-API level (Mechanism level: Specified version of key is not available (44))
net.sourceforge.spnego.SpnegoHttpFilter.doFilter(SpnegoHttpFilter.java:233)
root cause
GSSException: Failure unspecified at GSS-API level (Mechanism level: Specified version of key is not available (44))
sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:741)
sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:323)
sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:267)
sun.security.jgss.spnego.SpNegoContext.GSS_acceptSecContext(SpNegoContext.java:874)
sun.security.jgss.spnego.SpNegoContext.acceptSecContext(SpNegoContext.java:541)
sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:323)
sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:267)
net.sourceforge.spnego.SpnegoAuthenticator.doSpnegoAuth(SpnegoAuthenticator.java:444)
net.sourceforge.spnego.SpnegoAuthenticator.authenticate(SpnegoAuthenticator.java:283)
net.sourceforge.spnego.SpnegoHttpFilter.doFilter(SpnegoHttpFilter.java:229)
This is the best I can do to show the keytab file isn't corrupt:
C:\spnego>klist -k otsa.keytab
Service principal: HTTP/e1-3ots-int01.eu.msds.rhi.com@EU.MSDS.RHI.COM
KVNO: 20
Service principal: HTTP/e1-3ots-int02.eu.msds.rhi.com@EU.MSDS.RHI.COM
KVNO: 21
Service principal: HTTP/EMEA-OTSINT.eu.msds.rhi.com@EU.MSDS.RHI.COM
KVNO: 22
This is the command that was used to create the keytab for the web server:
Is this an issue with there being a descrepancy between the encryption type sent from the browser and the encryption type used to create the keytab file? How do you resolve that?
Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well my preflight program is working.
Within my web application I'm seeing this stack trace:
javax.servlet.ServletException: GSSException: Failure unspecified at GSS-API level (Mechanism level: Specified version of key is not available (44))
net.sourceforge.spnego.SpnegoHttpFilter.doFilter(SpnegoHttpFilter.java:233)
root cause
GSSException: Failure unspecified at GSS-API level (Mechanism level: Specified version of key is not available (44))
sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:741)
sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:323)
sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:267)
sun.security.jgss.spnego.SpNegoContext.GSS_acceptSecContext(SpNegoContext.java:874)
sun.security.jgss.spnego.SpNegoContext.acceptSecContext(SpNegoContext.java:541)
sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:323)
sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:267)
net.sourceforge.spnego.SpnegoAuthenticator.doSpnegoAuth(SpnegoAuthenticator.java:444)
net.sourceforge.spnego.SpnegoAuthenticator.authenticate(SpnegoAuthenticator.java:283)
net.sourceforge.spnego.SpnegoHttpFilter.doFilter(SpnegoHttpFilter.java:229)
This is the best I can do to show the keytab file isn't corrupt:
C:\spnego>klist -k otsa.keytab
Service principal: HTTP/e1-3ots-int01.eu.msds.rhi.com@EU.MSDS.RHI.COM
KVNO: 20
Service principal: HTTP/e1-3ots-int02.eu.msds.rhi.com@EU.MSDS.RHI.COM
KVNO: 21
Service principal: HTTP/EMEA-OTSINT.eu.msds.rhi.com@EU.MSDS.RHI.COM
KVNO: 22
This is the command that was used to create the keytab for the web server:
C:\scripts>KTPASS -in otsa.keytab -out otsa.keytab -princ HTTP/EMEA-OTSINT.eu.msds.rhi.com@EU.MSDS.RHI.COM -pass XXXX@T01 -mapuser eu\svcOTSAuth -crypto DES-CBC-MD5 -ptype KRB5_NT_PRINCIPAL +DesOnly
Existing keytab:
Keytab version: 0x502
keysize 77 HTTP/e1-3ots-int01.eu.msds.rhi.com@EU.MSDS.RHI.COM ptype 1 (KRB5_NT_P
RINCIPAL) vno 20 etype 0x3 (DES-CBC-MD5) keylength 8 (0x089b0826ba627f07)
keysize 77 HTTP/e1-3ots-int02.eu.msds.rhi.com@EU.MSDS.RHI.COM ptype 1 (KRB5_NT_P
RINCIPAL) vno 21 etype 0x3 (DES-CBC-MD5) keylength 8 (0xb59e4016029e7391)
Targeting domain controller: n2-1adc-eu01.eu.msds.rhi.com
Using legacy password setting method
Successfully mapped HTTP/EMEA-OTSINT.eu.msds.rhi.com to svcOTSAuth.
Key created.
Output keytab to otsa.keytab:
Keytab version: 0x502
keysize 77 HTTP/e1-3ots-int01.eu.msds.rhi.com@EU.MSDS.RHI.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 20 etype 0x3 (DES-CBC-MD5) keylength 8 (0x089b0826ba627f07)
keysize 77 HTTP/e1-3ots-int02.eu.msds.rhi.com@EU.MSDS.RHI.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 21 etype 0x3 (DES-CBC-MD5) keylength 8 (0xb59e4016029e7391)
keysize 75 HTTP/EMEA-OTSINT.eu.msds.rhi.com@EU.MSDS.RHI.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 22 etype 0x3 (DES-CBC-MD5) keylength 8 (0xb508c79d34a83d80)
Account svcOTSAuth has been set for DES-only encryption.
This is the latest krb5.ini file stored at $JAVA_HOME/jre/security/lib/krb5.ini
default_realm = EU.MSDS.RHI.COM
default_tkt_enctypes = des-cbc-md5 rc4-hmac
default_tgs_enctypes = des-cbc-md5 rc4-hmac
forwardable = false
renewable = true
noaddresses = true
clockskew = 3000
EU.MSDS.RHI.COM = {
kdc = N2-1ADCM-EU01.EU.MSDS.RHI.COM
default_domain = EU.MSDS.RHI.COM
}
.eu.msds.rhi.com = EU.MSDS.RHI.COM
eu.msds.rhi.com = EU.MSDS.RHI.COM
Is this an issue with there being a descrepancy between the encryption type sent from the browser and the encryption type used to create the keytab file? How do you resolve that?
Thanks.
I'm really glad that you were able to get the pre-flight working.
But sorry about not being able to help with the issue you are having with the keytab file that the ktpass.exe utility created.
I'm just not familiar with the ktpass.exe utility.
As you know, the ktpass.exe utility is not required and hence most people don't use it and instead use something else.
By the way, you might want to confirming that everything is working as expected without the keytab file…?
You may also want to consider starting over but this time follow the instructions in this guide…
http://spnego.sourceforge.net/server_keytab.html