Kerberos: kvno - "1" on client tickets

Question

We are setting up SSO for our web application for the client, but, unfortunately, we do not have access to the domain controller (another reason why we do not do any more experiments to verify our assumptions). So, we asked to run ktpass.exe and prepare the .ktpass file for use in our server configuration.

The problem we are facing is "the specified key version is not available."

I looked at the keytab file (knvo = 5) and checked the traffic from Wireshark on our web server:

As you can see, kvno = 1 in the AP-REQ ticket. I believe this is the right ticket to check the kvno version.

I know that compatibility problems with the Windows 2000 domain ( /kvno 1 should be used for compatibility with the Windows 2000 domain), but we are talking about working with the Windows 2008R2 server (and I can see the value msDS-Behavior-Version = 4 for our domain controller which corresponds to 2008R2!).

Is there something like the W2K domain mode we are facing?

Can explicit kvno = 1 help solve the problem? Ie, ktpass.exe [..] /kvno 1

EDIT # 1

The problem was an incorrectly defined SPN. This was HTTP / [e-mail] instead of using the fully qualified domain name. This will only work if WINS is enabled, but it turns out that it is not.

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

An answer will be kindly received explaining the effect that I observed.

Answer 1

I do not know the internal components very well, but MIT Kerberos clients do host-based host name resolution redirection to canonicalize the host name. In my experience, if the name does not resolve, it affects Kerberos auth. When I configure SQL Server service accounts to run Kerberos, I always have to register the SPN with the host name and fully qualified domain name, because different SQL components seem to use different resolution methods.

In a very simple network topology, WINS will be able to resolve the name. Even without WINS, NetBIOS will be able to resolve the host name. WINS and NetBIOS are highly dependent on broadcasts, so if your web server is on a different subnet, NetBIOS name resolution will fail, and WINS will also fail if it is not configured correctly. Windows should also use NetBIOS TCP / IP support.

Answer 2

The problem was an incorrectly defined SPN. This was HTTP/ [e-mail] instead of using the fully qualified domain name. This will only work if WINS is enabled, but it turns out that it is not.

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

An answer will be kindly received explaining the effect that I observed.