Monday, December 20, 2010

Kinit Fails to Generate Keytab - Exception: krb_error 14 - in Windows 2008R2 Domain

I ran into this issue specifically when setting up a kerberos ticket for the Teamworks 6.2.2 (jboss) service account running on windows 2003R2 in a windows 2008R2 domain. The reason I need kerberos here is so that a Web Part on a SharePoint 2010 server can pass through authentication from the user (the infamous doublehop delegation issue).

Windows 2008R2 domain controllers no longer support the older DES encryption used by Teamworks 6.x for Kerberos ticket encryption (DES-CBC-CRC). Bamf. Roadblock.

Here is the error I get when I try to run the kinit command to setup the Kerberos ticket for the Teamworks service account:

C:\Program Files (x86)\Support Tools>C:\Teamworks\java_x64\bin\kinit -k -t C:\t
amworks\sso.keytab HTTP/TWServer@MYDOMAIN.LOCAL
Exception: krb_error 14 KDC has no support for encryption type (14) KDC has no
upport for encryption type
KrbException: KDC has no support for encryption type (14)
Caused by: KrbException: Identifier doesn't match expected value (906)
... 4 more

krb_error 14 points to an issue with the encryption types. Googling led me to the fact that Windows 2008R2 no longer supports DES encryption types used by Teamworks/jboss.

From there I tried enabling a workaround posted by Microsoft but it doesn’t seem to have any effect, even after rebooting all servers in the domain:

As a last ditch effort, I ended up adding a windows 2003R2 BDC to my domain and tried pointing kinit to the new BDC. It worked. When I ran the kinit command, it automatically picked up the BDC instead of the PDC and generated the ticket successfully. After that, everything came up fine - Kerberos authentication worked from IIS/SharePoint 2010 to Teamworks, giving me SSO from my teamworks inbox webpart.


Mister C said...

Isn't this workaround essentially re-enabling the least secure encryption algorithm there is, though? Not that I can present a practical solution, I'm just speaking in theory.

Bryan said...

Yep, thats pretty much what I'm shooting for here. And it looks like we will need to support this product for a while in a production environment, so we will have to come up with some alternative since I have no control over production domain controllers.

I'm starting to lean towards removing the kereberos piece from the puzzle - which is really only required to support accessing the teamworks site in a SSO way through a SharePoint Web Part. Forcing users to go directly to the Teamworks portal allows us to use NTLM, which is probably a better long term solution (though there is still another teamworks quirk with windows 7 NTLM authentication that needs to be addressed)

mehak kashish said...

wonderful information, I had come to know about your blog from my friend nandu , hyderabad,i have read atleast 7 posts of yours by now, and let me tell you, your website gives the best and the most interesting information. This is just the kind of information that i had been looking for, i'm already your rss reader now and i would regularly watch out for the new posts, once again hats off to you! Thanks a ton once again, Regards,
obiee training in hyderebad