Solução de problemas do AD FS – Autenticação integrada do Windows
A autenticação integrada do Windows permite que os usuários façam logon com suas credenciais do Windows e experimentem o SSO (logon único), usando o Kerberos ou NTLM.
Por que a autenticação integrada do Windows falha
A autenticação integrada do Windows falhará por três motivos principais. Eles são: – Configuração incorreta do SPN (Nome da Entidade de Serviço) – Token de Associação de Canal – Configuração do Internet Explorer
Configuração incorreta do SPN
Um SPN (nome da entidade de serviço) é um identificador exclusivo de uma instância de serviço. Os SPNs são usados pela autenticação Kerberos para associar uma instância de serviço a uma conta de logon de serviço. Isso permite que um aplicativo cliente solicite que o serviço autentique uma conta, mesmo se o cliente não tiver o nome da conta.
Um exemplo de como um SPN é usado com o AD FS é o seguinte:
- Um navegador da Web consulta o Active Directory para determinar qual conta de serviço está executando sts.contoso.com
- O Active Directory informa ao navegador que é a conta de serviço do AD FS.
- O navegador receberá um tíquete Kerberos para a conta de serviço do AD FS.
Se a conta de serviço do AD FS tiver um SPN configurado incorretamente ou errado, isso poderá causar problemas. Examinando os rastreamentos de rede, você pode ver erros como Erro de KRB: KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN.
Usando rastreamentos de rede (como Wireshark), você pode determinar qual SPN o navegador está tentando resolver e, em seguida, usando a ferramenta de linha de comando, setspn - Q <spn>, você pode fazer uma pesquisa nesse SPN. Ele pode não ser encontrado ou pode ser atribuído a outra conta diferente da conta de serviço do AD FS.
Você pode verificar o SPN examinando as propriedades da conta de serviço do AD FS.
Token de associação de canal
Atualmente, quando um aplicativo cliente se autentica no servidor usando Kerberos, Digest ou NTLM usando HTTPS, um canal TLS (Transport Level Security) é estabelecido pela primeira vez e a autenticação ocorre usando esse canal.
O Token de associação de canal é uma propriedade do canal externo protegido por TLS e é usado para associar o canal externo a uma conversa pelo canal interno autenticado pelo cliente.
Se houver um ataque "man-in-the-middle" ocorrendo e eles estiverem descriptografando e criptografando novamente o tráfego SSL, a chave não corresponderá. O AD FS determinará que há algo entre ele e o navegador da Web. Isso fará com que a autenticação Kerberos falhe e o usuário será solicitado com uma caixa de diálogo 401 em vez de uma experiência de SSO.
Isso pode ser causado por:
- Qualquer coisa entre o navegador e o AD FS
- Fiddler
- Proxies reversos executando a ponte SSL
Por padrão, isso é definido como "Permitir" no AD FS. Você pode alterar essa configuração usando o cmdlet Set-ADFSProperties -ExtendedProtectionTokenCheck None do PowerShell
Para obter mais informações, consulte Práticas recomendadas para o planejamento e a implantação seguros do AD FS.
Configuração do Internet Explorer
Observação
Se você estiver usando o Chrome, adicione-o à lista de agentes de usuário compatíveis com WIA.
Por padrão, o Internet Explorer se comportará da seguinte maneira:
- O Internet Explorer receberá uma resposta 401 do AD FS com a palavra NEGOTIATE no cabeçalho.
- Isso instrui o navegador da Web a obter um tíquete Kerberos ou NTLM para enviar de volta ao AD FS.
- Por padrão, o IE tentará fazer isso (SPNEGO) sem interação do usuário se a palavra NEGOTIATE estiver no cabeçalho. Ele só funcionará nos sites da intranet.
Há duas coisas principais que podem impedir que isso aconteça.
Habilitar a Autenticação Integrada do Windows não está marcado nas propriedades do IE. Isso está localizado em Opções da Internet –> Avançado –> Segurança.
As zonas de segurança não estão configuradas corretamente
Os FQDNs não estão na zona da intranet
A URL do AD FS não está na zona da intranet.
