Tudo bem, recriando meu banco de dados Kerberos e adicionando entidades a cada enctype estava disponível (aes256-cts: normal arcfour-hmac: normal des3-hmac-sha1: normal des-cbc-crc: normal des: normal des: v4 des: norealm des: onlyrealm des: afs3) e, em seguida, exportar o HTTP/link.to.website@REALM para um keytab para o apache, os usuários do Active Directory agora podem efetuar login também.
Veja um exemplo de como adicionar um principal a cada codificação e exportá-lo para um keytab:
addprinc -e "aes256-cts: normal arcfour-hmac: normal des3-hmac-sha1: normal des-cbc-crc: normal des: normal des: v4 des: norealm des: onlyrealm des: afs3" HTTP / www .eindwerk.lan
ktadd -e "aes256-cts: normal arcfour-hmac: normal des3-hmac-sha1: normal des-cbc-crc: normal des: normal des: v4 des: noreal des: onlyrealm des: afs3" -kt / etc / apache2 / apache.keytab HTTP / www.eindwerk.lan
EDIT: Ok, tudo parece estar funcionando corretamente, exceto que o Internet Explorer sempre tenta obter um ticket para HTTP / [TRUSTED_DOMAIN_NAME_IN_WIN_2003] na primeira tentativa. No meu caso, isso se traduz em "HTTP / EINDWERK.LAN", enquanto deveria ser "HTTP / NS.EINDWERK.LAN".
Eu também notei que tentar mudar o nome de domínio da confiança [IMAGE] completamente e absolutamente quebra qualquer autenticação cross-realm: os TGTs são trocados corretamente, mas quando o KDC Linux local tenta realmente usar o ticket, ele descobre que não pode descriptografá-lo, emitindo um "PROCESS_TGS: authtime 0, para HTTP / ns.eindwerk .lan @ EINDWERK.LAN, Nenhuma chave correspondente na entrada "erro no log do KDC. A razão para isso pode muito bem ser que muitos dos mecanismos de criptografia considerem o domínio e o nome de usuário como salt, de modo que o nome do domínio realmente precise ser configurado corretamente.