Well I won't say it CAN'T be done with Windows, but I will say that the limitation is session based. The problem then, is that for each session Windows caches one ticket. When you lock your computer then unlock it another session is initiated and a new key is requested from the KDC. The same thing happens when you log off then on to your computer again. This method is actually how user permissions are determined for server sessions as well, meaning the key/ticket can be cached so that every server resource or session you initiate doesn't have to ask you for your password, but I've never heard/read/researched of it to be able to cache more than one.
Now, you probably already know that given your knowledge that you've displayed in your question, so I'll say that based off the fact that Windows stores the key you get when a TGT is issued and is session based, I don't think it's possible with JUST Windows. The MIT Kerberos for Windows may have a way to initiate two sessions under one user, but even then, I'm not sure how the resources you are accessing would know which ticket/key pair to use. Does that make sense?
Please see this for a description of how Windows stores TGTs/key pairs.
Very good question by the way.
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
It's okay, I solved it. When I ran config.krb5 it created a file at /etc/krb5/krb5.conf, but a file already existed at /etc/krb5.conf. It was using that configuration instead of the one I created, so I removed /etc/krb5.conf.