Acontece que o maior problema aqui é um dos problemas que o AES256 pretendia resolver.
TL; DR : o nome principal no keytab agora precisa corresponder ao nome da conta.
O problema
Se tivéssemos executado KRB5_TRACE=/dev/stderr kinit [email protected] de volta quando a conta estivesse habilitada somente para a criptografia RC4-HMAC, teríamos visto essa linha na saída:
[8192] 1441829478.537451: Selected etype info: etype rc4-hmac, salt "", params ""
Agora que temos o AES256 ativado, essa linha é assim:
[8200] 1441829508.947208: Selected etype info: etype aes256-cts, salt "REALM.COMHostServiceAccount", params ""
Quando a comutação foi feita da autenticação NTLM para o Kerberos, o algoritmo RC4-HMAC foi especificado para reutilizar o hash NTLM. A Microsoft se recusou a colocar um sal no hash para facilitar a interoperabilidade dos sistemas existentes com o Kerberos. Agora que os usuários têm a oportunidade de atualizar, um salt é especificado para os algoritmos AES256 e AES128, e o salt é o nome do usuário.
Podemos ver isso se gerarmos keytabs para RC4-HMAC e AES256 usando nomes de usuários diferentes. Com o RC4-HMAC:
fluggo@host:~$ ktutil
ktutil: add_entry -password -p HTTP/[email protected] -k 1 -e rc4-hmac
Password for HTTP/[email protected]: 12345
ktutil: add_entry -password -p [email protected] -k 1 -e rc4-hmac
Password for [email protected]: 12345
ktutil: write_kt rc4.keytab
ktutil: q
fluggo@host:~$ klist -Kek rc4.keytab
Keytab name: FILE:rc4.keytab
KVNO Principal
---- --------------------------------------------------------------------------
1 HTTP/[email protected] (arcfour-hmac) (0x7a21990fcd3d759941e45c490f143d5f)
1 [email protected] (arcfour-hmac) (0x7a21990fcd3d759941e45c490f143d5f)
... o hash é o mesmo, então essas duas entradas são equivalentes. Mas com AES256:
fluggo@host:~$ ktutil
ktutil: add_entry -password -p HTTP/[email protected] -k 1 -e aes256-cts-hmac-sha1-96
Password for HTTP/[email protected]: 12345
ktutil: add_entry -password -p [email protected] -k 1 -e aes256-cts-hmac-sha1-96
Password for [email protected]: 12345
ktutil: write_kt aes.keytab
ktutil: q
fluggo@host:~$ klist -Kek aes.keytab
Keytab name: FILE:aes.keytab
KVNO Principal
---- --------------------------------------------------------------------------
1 HTTP/[email protected] (aes256-cts-hmac-sha1-96) (0x5746fa6f9b0c990ba7fb20acd85065040d66e843a043508569841768ef2b7917)
1 [email protected] (aes256-cts-hmac-sha1-96) (0x6a98fdccbce4db77f40192f4e916e0900a1b9cba2f6ca8bc737d968e4b961c25)
... os hashes são diferentes. O nome principal é importante e precisa corresponder ao UPN da conta.
Uma solução
Como o nome de usuário deve estar correto para o keytab funcionar, geramos um novo keytab com o nome principal que o Active Directory usa no ticket:
# rm /etc/apache2/service.keytab
# ktutil
ktutil: add_entry -password -p [email protected] -k 1 -e aes256-cts-hmac-sha1-96
Password for [email protected]: <enter password here>
ktutil: add_entry -password -p [email protected] -k 1 -e aes128-cts-hmac-sha1-96
Password for [email protected]: <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
O Apache se preocupa com o nome principal no keytab e, portanto, não encontrará essas entradas por conta própria. Em vez disso, apenas direcionamos o Apache para usar qualquer entidade principal que ele possa encontrar:
KrbServiceName Any
Eu queria que o Apache encontrasse o diretor pelo nome correto, mas isso dificilmente importa, já que nossos diretores são os únicos no keytab.
Reinicie o Apache, atualize a página e a autenticação deve funcionar agora.