How to avoid frequent KVNO increases, when using Apache HTTPD with mod_auth_kerb talking to AD?

Question

I've setup Apache HTTPD 2.4 with mod_auth_kerb, created a service account on Active Directory, added a SPN for my http hostname, created a keytab file on the linux machine, and had SSO start working nicely for users logged into the AD domain from IE. It was all good!

However, every week or so, users instead of getting signed into the website instead get a http basic auth prompt up, which won't accept their credentials. Looking in the httpd server logs, we see entries like:

[auth_kerb:error] [pid 8040] [client 192.168.100.100:54460] gss_accept_sec_context() failed: Unspecified GSS failure.  Minor code may provide more information (, Key version number for principal in key table is incorrect)

What seems to have happened is that the KVNO (Kerberos Key Version Number) on AD has incremented, so they keytab is invalid. We can see that by doing something like:

$ kinit '[email protected]'
Password for [email protected]

$ kvno HTTP/sso.example.com
HTTP/[email protected]: kvno = 12

$ klist -k krb5-keytab 
Keytab name: FILE:krb5-keytab
KVNO Principal
---- ---------------------------------------------
11   HTTP/[email protected]

The KVNO that AD is reported has somehow been incremented, and is one higher than the one in the keytab that Apache is using, which is causing the Kerberos SSO to fail

If we re-create the keytab, with something like:

$ kinit '[email protected]'
Password for [email protected]

$ KEYTAB=krb5-keytab
$ SN="HTTP/[email protected]"
$ KVNO=`kvno $SN | awk -F'kvno = ' '{print $2}'`
$ echo "KVNO for $SN is $KVNO"
KVNO for HTTP/[email protected] is 12

$ rm $KEYTAB
$ ktutil
addent -password -p HTTP/[email protected] -k 12 -e arcfour-hmac
wkt krb5-keytab
$ chown apache.apache $KEYTAB
$ chmod 440 $KEYTAB
$ chcon -u system_u -t httpd_config_t $KEYTAB
$ service httpd restart

Then Kerberos SSO will begin working again, and all will be fine! For a week or so, when suddenly it will fail again, as the KVNO has silently and mysteriously bumped itself one value higher on AD....

So, what do I need to do, either on AD or in how I create the kerberos keytab file on Linux, so that the KVNO doesn't keep randomly increasing itself every 1-2 weeks thus breaking all our user's ability to access the site?

Solution 1

Active Directory increments KVNO pursuant to RFC 4120. Microsoft documented their implementation of it in the document MS-KILE section 3.1.5.8.

Active Directory essentially ignores KVNO. (Except on Read-Only DCs - if an RODC is compromised, the keys it holds can not be reused against another DC.) So my point is AD generally doesn't care what your KVNO is - even though it does still maintain KVNOs - it only cares if your ticket is valid and not expired. (Whether your Linux client does strict checking of KVNOs though, I don't know. It apparently does.)

Active Directory is going to try to decrypt/validate with the most recent key that it has for that principal, and if that doesn't work, it will try with the previous one (as long as the previous key is still within its lifetime,) and if that doesn't work it will fail the request. Regardless of what KVNO the client sends in. But remember that not all domain controllers will have your KVNO-1 (that is, the previous KVNO,) only the domain controller who last issued your ticket.

KVNO is incremented when the client computer changes its password or renews its ticket or its ticket expires. By default, Active Directory uses 7 days for maximum time in which a ticket may be renewed, which matches your description of "it works for a week or so."

There is no mechanism to stop Active Directory from incrementing KVNO when it receives a valid password change or ticket rotation from a domain member computer. So my point is that Active Directory doesn't "mysteriously" update KVNO - it does so for specific reasons.

It appears to me that your Linux machine is still trying to use its (now expired) ticket after its maximum lifetime of 7 days. (Or Active Directory has been configured for something shorter.)

Look in your /etc/krb5.conf and verify that the maximum ticket lifetime is within the maximum ticket lifetime that is specified in Active Directory (the Kerberos Policy in the Default Domain Group Policy.) You have to renew your ticket (and your KVNO must increase) within that interval specified by AD.

Solution 2

You're probably hitting this bug https://bugzilla.samba.org/show_bug.cgi?id=6750

There are a couple of samba config changes that will solve it. I set

kerberos method = secrets and keytab