Por que meus clientes enviam as solicitações HTTP antes de obter os tickets do Kerberos do KDC

Question

Eu tenho tentado pegar lulas com kerberos por alguns dias, mas estou com muita dor. Eu verifiquei todos os arquivos de configuração todos eles parece OK.

Aqui está a minha pergunta, hoje eu capturei os pacotes com wireshark e vi que meu navegador cliente envia e obtém os pacotes HTTP antes de obter os tickets do KDC.

Eu posso conectar a Internet através do squid, mas ele usa o NTLM ao invés do Kerberos, estou pensando que o fallback de autorização para o NTLM, porque ele tenta Kerberos Auth antes ele recebe o ticket do KDC. (pode obter os ingressos mais tarde)

O que pode fazer com que o KDC não consiga enviar os tickets durante o período de autenticação?

Se necessário; você pode obter o log completo de wireshark aqui .
update: updated wireshark logs, por favor, verifique isso em vez de primeiro

update2: arquivo conf do squid: link

Muito obrigado.

    

Answer 1

Não vejo nenhum desafio do proxy para autenticação no rastreamento que você enviou. O único tráfego Kerberos que vejo é um TGT para Realm: LABRISTEST.COM emitido para test1.

Se o proxy estivesse aplicando a autenticação, esperaria um rastreio com "StatusCode: 407, Autenticação de proxy necessária" retornada por proxy. Consulte o link , por exemplo, de um rastreamento provável em que o proxy requer autenticação.

Eu não vejo nenhuma autenticação baseada em NTLM ou Kerberos no proxy.

O cliente só solicitará tickets se precisar (ou seja, o proxy informar que a autenticação é necessária). Até então, não sabe quais os bilhetes para solicitar e tenta anonimamente. Então você deve ver uma solicitação de ingresso depois de acessar o proxy anonimamente. E isso também, somente se não houver nenhum ticket em cache localmente no lado do cliente. Também é possível que, apesar de nenhum ticket localmente armazenado em cache, você não veja nenhuma solicitação devido a um cache negativo (armazenou em cache o fato de que a solicitação anterior de ticket falhou).

Eu também noto que você não está usando o IE (UserAgent: Mozilla / 5.0 (Windows NT 6.1; rv: 8.0) Gecko / 20100101 Firefox / 8.0) para testar isso. Eu sugiro que você use o IE para testes, a menos que você tenha certeza de que o Firefox está configurado para responder corretamente às solicitações de autenticação.

Atualização (16 de janeiro): Você deve sempre limpar o cache DNS (ipconfig / flushdns) e o cache do kerberos antes de coletar rastreios. Isso permite que o tráfego DNS relacionado à detecção de KDCs e as solicitações de tíquete do Kerberos sejam bem-sucedidos / falhem.

Também é importante saber como você configura as configurações de proxy no navegador, já que isso tem alguma diferença nos tickets solicitados. A porta do proxy parece ser 3128 e o nome é labris-1. Portanto, você provavelmente precisará registrar http / labris-1: 3128 e http / labris-1.labristest.com: 3128 SPN no objeto AD usado pelo serviço de proxy. Você também precisa adicionar a chave reg do link para todos os IE maiores que V6 . Certifique-se de que o keytab esteja atualizado e acessível no servidor do squid.