It turns out that the major problem here is one of the problems AES256 was intended to solve.
TL;DR: The principal name in the keytab now needs to match the account name.
The Problem
If we had run KRB5_TRACE=/dev/stderr kinit HostServiceAccount@REALM.COM back when the account was enabled for only RC4-HMAC encryption, we would have seen this line in the output:
[8192] 1441829478.537451: Selected etype info: etype rc4-hmac, salt "", params ""
Now that we have AES256 enabled, though, that line looks like this:
[8200] 1441829508.947208: Selected etype info: etype aes256-cts, salt "REALM.COMHostServiceAccount", params ""
When the switch was made from NTLM authentication to Kerberos, the RC4-HMAC algorithm was specified to reuse the NTLM hash. Microsoft declined to put a salt into the hash to make it easier for existing systems to interoperate with Kerberos. Now that users have the opportunity to upgrade, a salt is specified for the AES256 and AES128 algorithms, and the salt is the user name.
We can see this if we generate keytabs for RC4-HMAC and AES256 using different usernames. With RC4-HMAC:
fluggo@host:~$ ktutil
ktutil: add_entry -password -p HTTP/host.example.com@REALM.COM -k 1 -e rc4-hmac
Password for HTTP/host.example.com@REALM.COM: 12345
ktutil: add_entry -password -p HostServiceAccount@REALM.COM -k 1 -e rc4-hmac
Password for HostServiceAccount@REALM.COM: 12345
ktutil: write_kt rc4.keytab
ktutil: q
fluggo@host:~$ klist -Kek rc4.keytab
Keytab name: FILE:rc4.keytab
KVNO Principal
---- --------------------------------------------------------------------------
1 HTTP/host.example.com@REALM.COM (arcfour-hmac) (0x7a21990fcd3d759941e45c490f143d5f)
1 HostServiceAccount@REALM.COM (arcfour-hmac) (0x7a21990fcd3d759941e45c490f143d5f)
...the hash is the same, so these two entries are equivalent. But with AES256:
fluggo@host:~$ ktutil
ktutil: add_entry -password -p HTTP/host.example.com@REALM.COM -k 1 -e aes256-cts-hmac-sha1-96
Password for HTTP/host.example.com@REALM.COM: 12345
ktutil: add_entry -password -p HostServiceAccount@REALM.COM -k 1 -e aes256-cts-hmac-sha1-96
Password for HostServiceAccount@REALM.COM: 12345
ktutil: write_kt aes.keytab
ktutil: q
fluggo@host:~$ klist -Kek aes.keytab
Keytab name: FILE:aes.keytab
KVNO Principal
---- --------------------------------------------------------------------------
1 HTTP/host.example.com@REALM.COM (aes256-cts-hmac-sha1-96) (0x5746fa6f9b0c990ba7fb20acd85065040d66e843a043508569841768ef2b7917)
1 HostServiceAccount@REALM.COM (aes256-cts-hmac-sha1-96) (0x6a98fdccbce4db77f40192f4e916e0900a1b9cba2f6ca8bc737d968e4b961c25)
...the hashes are different. The principal name matters, and it needs to match the UPN of the account.
A Solution
Since the username must be correct for the keytab to work, we generate a new keytab with the principal name Active Directory uses on the ticket:
# rm /etc/apache2/service.keytab
# ktutil
ktutil: add_entry -password -p HostServiceAccount@REALM.COM -k 1 -e aes256-cts-hmac-sha1-96
Password for HostServiceAccount@REALM.COM: <enter password here>
ktutil: add_entry -password -p HostServiceAccount@REALM.COM -k 1 -e aes128-cts-hmac-sha1-96
Password for HostServiceAccount@REALM.COM: <enter password here>
ktutil: write_kt /etc/apache2/service.keytab
ktutil: q
# chown -v www-data:root /etc/apache2/service.keytab
# chmod -v 440 /etc/apache2/service.keytab
Apache cares about the principal name in the keytab, and so it won't find these entries on its own. Instead, we just direct Apache to use whatever working principal it can find:
KrbServiceName Any
I wanted Apache to find the principal by the correct name, but it hardly matters since our principals are the only ones in the keytab.
Restart Apache, refresh the page, and the authentication should work now.
Best Answer
As explained in the linked document, the memory cache is using
MEMORYkeyword so the following should do the job:But note that this type of
ccachewill be destroyed once the process exits. Note that:needs to be present, otherwise it will try to store the ticket in the file calledMEMORYin current working directory.