Introdução
Este documento descreve como resolver o problema quando a Auth falha através do Cisco Web Security Appliance (WSA) quando o cliente usa NEGOEXTS.
Informações de Apoio
O Cisco Web Security Appliance (WSA) pode autenticar usuários para aplicar políticas com base no usuário ou grupo. Um dos métodos disponíveis é o Kerberos. Ao usar o Kerberos como um método de autenticação em uma Identidade, o WSA responde à solicitação HTTP de um cliente com uma resposta HTTP 401 (transparente) ou 407 (explícita) que contém o cabeçalho WWW-Authenticate: Negotiate. Nesse ponto, o cliente envia uma nova solicitação HTTP com o cabeçalho Authorization: Negotiate, que contém os protocolos GSS-API (Generic Security Service Application Program Interface) e SPNEGO (Simple Protected Negotation). Em SPNEGO, o usuário apresenta os mechTypes que ele suporta. Estes são os tipos de mecanismo suportados pelo WSA:
- KRB5 - Método de autenticação Kerberos usado se o Kerberos for suportado e configurado corretamente no cliente e se um tíquete Kerberos válido estiver presente para o serviço que está sendo acessado
- NTLMSSP - Método do Provedor de Suporte de Segurança NTLM da Microsoft usado se não houver tíquetes Kerberos válidos disponíveis, mas houver suporte para o método de autenticação Negotiate
Problema: a autenticação falha no WSA quando o cliente usa NEGOEXTS
Em versões mais recentes do Microsoft Windows, um novo método de autenticação é suportado chamado NegoExts, que é uma extensão do protocolo de autenticação Negotiate. Este mechType é considerado mais seguro que NTLMSSP e é preferido pelo cliente quando os únicos métodos suportados são NEGOEXTS e NTLMSSP. Mais informações podem ser encontradas neste link:
Apresentando Extensões do Pacote de Autenticação de Negociação
Esse cenário geralmente ocorre quando o método de autenticação Negotiate é selecionado e não há mechType KRB5 (provavelmente devido à ausência de um Tíquete Kerberos válido para o serviço WSA). Se o cliente selecionar NEGOEXTS (pode ser visto como NEGOEX no Wireshark), o WSA será desabilitado para processar a transação de autenticação e a autenticação falhará para o cliente. Quando isso ocorre, esses logs são vistos nos logs de autenticação:
14 Nov 2016 16:06:20 (GMT -0500) Warning: PROX_AUTH : 123858 : [DOMAIN]Failed to parse NTLMSSP packet, could not extract NTLMSSP command14 Nov 2016 16:06:20 (GMT -0500) Info: PROX_AUTH : 123858 : [DOMAIN][000] 4E 45 47 4F 45 58 54 53 00 00 00 00 00 00 00 00 NEGOEXTS ........
Quando a autenticação falhar, isso ocorrerá:
Se os privilégios de convidado estiverem habilitados, o cliente será classificado como Não autenticado e redirecionado para o site
Se os privilégios de convidado estiverem desabilitados - o cliente será apresentado a outro 401 ou 407 (dependendo do método proxy) com os métodos de autenticação restantes apresentados no cabeçalho da resposta (Negociar não será apresentado novamente). Um prompt de autenticação provavelmente ocorrerá se NTLMSSP e/ou Autenticação básica estiver configurado. Se não houver outros métodos de autenticação (a identidade é configurada somente para Kerberos), a autenticação simplesmente falhará.
Solução
A solução para esse problema é remover a autenticação Kerberos da identidade ou corrigir o cliente para que ele receba um tíquete Kerberos válido para o serviço WSA.
Feedback