Eu decidi criar um novo proxy em uma versão posterior do Ubuntu usando a versão mais recente do msktutil e está realmente funcionando. Eu acho que vou migrar todos os dados e trocar os IPs durante a próxima janela de manutenção.
Temos uma filial na Costa Rica onde, na época, havíamos implementado um proxy do Squid com o SSO usando o AD e ele estava funcionando perfeitamente. Recentemente, implementamos um RODC no site. Depois que isso aconteceu, ninguém conseguiu autenticar e não consegui corrigir o problema. Eu deletei o objeto AD usado para a autenticação do kerberos e executei este comando:
msktutil -c -b "CN=COMPUTERS" -s HTTP/PROXY.domain.com -k /etc/squid3/PROXY.keytab --computer-name PROXY-K --upn HTTP/PROXY.domain.com --server dc1.domain.com --verbose
Este comando cria o objeto no AD, mas não define a senha. Eu recebo o seguinte erro:
Error: krb5_set_password_using_ccache failed (Cannot contact any KDC for requested realm) Error: set_password failed
Certifiquei-me de que esta máquina possa resolver os controladores de domínio.
Neste ponto, estou perdido. Lutei contra isso por um mês, e realmente pude usar alguma orientação. Eu tenho quatro outros proxies de squid idênticos que não ficam atrás de um RODC e funcionam perfeitamente.
Suponho que o RODC esteja funcionando corretamente, por exemplo: o Kerberos está OK, o AD DS está em funcionamento, etc.
Acho que meu próximo passo seria capturar um rastreamento de rede, filtrando apenas DNS e Kerberos e, em seguida, ver o que o (s) cliente (s) está fazendo.
--- 07/01/2017 ---
Eu posso ver um handshake do Kerberos ocorrendo entre o 172.26.48.25 e o 172.21.1.19. No entanto, duas respostas AS-REQ (solicitação de serviço de autenticação) falham, com um KRB5KDC_ERR_PREAUTH_REQUIRED visto regularmente. Isso é esperado UMA VEZ com o Kerberos 5. Ver duas vezes é ímpar e normalmente indica problemas de sincronização de horário entre o cliente KDC e o Kerberos.
No entanto, vemos o cliente solicitar um ticket de serviço. A parte do serviço de concessão de ticket (TGS) do KDC responde com KRB5_NT_UNKNOWN (tipo de nome do Kerberos desconhecido). Eu, portanto, talvez investigue um pouco mais esse erro, pois normalmente não esperaria que o cliente avançasse com a solicitação de um tíquete de serviço se a autenticação inicial falhasse.