Kerberos: kvno is '1' in client tickets

Question

We're configuring SSO for our web app for a customer, but unfortunately we don't have access to the domain controller (one more reason why we don't do more experimenting to check our assumptions). So, we asked to run ktpass.exe and prepare .ktpass file to use for our server configuration.

The issue we are facing is "specified version of key is not available".

I looked up the keytab file (knvo = 5), and checked out the traffic with Wireshark on our web server:

As you can see, kvno = 1 in AP-REQ ticket. I suppose that it's the right ticket to check kvno version.

I know there're compatibility issues with Windows 2000 domain ( /kvno 1 must be used for Windows 2000 domain compatibility), but we are said to deal with Windows 2008R2 server (and I can see the value msDS-Behavior-Version = 4 for our domain controller, which matches 2008R2!).

Is there anything like W2K domain mode we are facing with?

Would explicit kvno=1 help to resolve the issue? Ie, ktpass.exe [..] /kvno 1

EDIT #1

The problem was about incorrectly specified SPN. It was HTTP/computer_name@DOMAIN.COM instead of using fully-qualified domain name. This would only work if WINS were enabled, but it turned out it wasn't.

After generating keytab with the correct SPN, everything works fine, and kvno sent according to actual account value.

Will kindly accept answer that explains the effect I observed.

Answer 1

I do not know the internals well, but MIT Kerberos clients do forward resolution of the hostname part of a host-based service principal to canonicalize the hostname. In my experience if the name does not resolve it does affect Kerberos auth. When I setup service accounts for SQL Server to do Kerberos I always have to register an SPN with the host name and the fully qualified domain name because different SQL components seem to use different resolution methods.

In a very basic network topology WINS would be able to resolve the name. Even without WINS though, the NetBIOS service would be able to resolve the hostname. WINS and NetBIOS rely heavily on broadcasts, so if your webserver is on a different subnet, NetBIOS name resolution would fail, and WINS too if not configured correctly. Also Windows need to use the TCP/IP NetBIOS Helper service.

Answer 2

The problem was about incorrectly specified SPN. It was HTTP/computer_name@DOMAIN.COM instead of using fully-qualified domain name. This would only work if WINS were enabled, but it turned out it wasn't.

After generating keytab with the correct SPN, everything works fine, and kvno sent according to actual account value.

Will kindly accept answer that explains the effect I observed.