KrbException: Specified version of key is not available (44)

I have run into this proble many  times. This happens each time I change the password of the user account under which I have set the SPNs for my WebLogic Server instance. 

When I checked wireshark traces, I could see browser sending a SPNEGO token to WebLogic, and this token had kvno as "6". But when I checked my keytab file (on WebLogic side, using command "klist -ke -t mac5keytab"), I could see "5" as kvno againt HTTP principal.

Digging deeper, I used "ADSIEdit.msc" on my AD server and opened the user account and could see the value of attribute "msDS-KeyVersionNumber" was "6". So password change increments this attribute value and browser sends the latest "kvno" (in agreement with KDC, I suppose).

I also ran into the same error when I enrolled a windows 2008 R2 server with Windows 2003 (here my AD and KDC are located). This happened even when I had used a total different user account during enroll process.

So what is the way out? Regenerate the keytab file.

Here is what debug ATN stack trace looks like (source lines belong to WebLogic 10.3.4):

####<xxxxxxxxxxxx PM IST> <Debug> <SecurityAtn> <mac5.localdomain.com> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1308383561718> <BEA-000000> <acceptGssInitContextToken failed
com.bea.security.utils.kerberos.KerberosException: Failure unspecified at GSS-API level (Mechanism level: Specified version of key is not available (44))
 at com.bea.security.utils.kerberos.KerberosTokenHandler.acceptGssInitContextTokenInDoAs(KerberosTokenHandler.java:334)
 at com.bea.security.utils.kerberos.KerberosTokenHandler.acceptGssInitContextTokenInDoAs(KerberosTokenHandler.java:334)
.
.
.
Caused By: GSSException: Failure unspecified at GSS-API level (Mechanism level: Specified version of key is not available (44))
 at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:741)
 at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:323)
 at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:267)
.
.
.
Caused By: KrbException: Specified version of key is not available (44)
 at sun.security.krb5.EncryptionKey.findKey(EncryptionKey.java:527)
 at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:260)
 at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:134)
 at sun.security.jgss.krb5.InitSecContextToken.<init>(InitSecContextToken.java:79)
 at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:724)
 at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:323)
 at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:267)
.
.
.
.

Comments

  1. Hi, I encountered the issue too, the kvno in my keytab is 1, but in AD it's 4. I tried to re-generate the keytab file, but the kvno remained the same, which is 1, can you elaborate how to generate the keytab? I use ktab command in jdk. thanks.

    ReplyDelete
    Replies
    1. I hope I am not late on this one.

      Might be an issue or work-as-designed behavior with ktab, not sure about it. Following link might help you changing kvno to desired value using ktab:

      http://dmdaa.wordpress.com/2010/05/08/how-to-get-needed-kvno-for-keytab-file-created-by-java-ktab-utility/

      I usually use the ktpass command to generate the keytab. This command gives you an option to explicitly set the kvno during keytab generation. And if you do not specify the kvno explicitly in this command, then it would increment the kvno on AD side by one, and set this incremented value as the kvno for your principal in keytab as well. The downside of using this command would be that it changes the SPN of the account on AD, prefixing "HTTP/" to it. So, you would need to change the principal on login configuration file (krb5Login.conf) as well. But be cautious about following this path as this whole kerberos integration is sensitive; at the end it might leave the setup in non-working condition, and you would have to configure things from scratch.

      Delete

Post a Comment

Popular posts from this blog

Replacing expired certificates on SSL Server that uses JKS based keystore

Giving non-admin users the permission to access MBeans

Modifying the "supported" attributes of embedded ldap users/groups