Meu cliente exige SSO no domínio do Windows para meu servidor web/aplicativo baseado em Linux. O servidor tem seu próprio keytab instalado e tudo funciona bem. O domínio Windows (EXAMPLE.ORG) possui uma conta de usuário de serviço com SPN HTTP/server.example.org associado. Meu servidor de aplicativos (WildFly) exige autenticação Kerberos e nega autenticação NTLM.
Tenho um domínio de teste (baseado em 2016) que foi criado com configurações padrão. Estou tentando repetir esta configuração no domínio de teste e não consigo fazer o Kerberos funcionar. Vejo solicitação de negociação do servidor, mas o cliente sempre retorna ticket NTLM.
WWW-Authenticate: Negotiate (request)
Authorization: Negotiate TlRMTVNTU..... (reply)
Na infraestrutura do cliente, vejo o mesmo com o ticket Kerberos
WWW-Authenticate: Negotiate (request)
Authorization: Negotiate YIIHmAYGKw.... (reply)
A única diferença (além do GPO) que vejo é que meu SPN não está dentro do mesmo domínio DNS. Meu domínio AD é tdm.sample.org e o servidor é server.sample.org, não sei se isso importa.
Há algum tempo, também tive o mesmo problema no domínio. Tanto o cliente IE quanto o Windows Server 2016 com IIS unidos no mesmo domínio também usavam NTLM.
Acredito que existam poucas configurações de GPO que regulam como o cliente pode ou não autorizar, mas nenhum dos documentos que li ajudou.
Existe alguma descrição clara de quais restrições a autenticação do cliente Kerberos possui ou alguma dica ou estratégia de depuração que possa ser aplicada?
Responder1
Existem várias restrições quando o Windows nem mesmo tenta a autorização Kerberos.
1. SPN aponta para PTR, não para alias da web
Se o seu servidor web não membro do domínio tiver um alias, você não precisará atribuir SPN a esse alias. Seria verificado em relação ao registro DNS real desse servidor.
Digamos que você tenha isso:
A record server.example.org -> 10.0.0.1
PTR record 10.0.0.1 -> server.example.org
CNAME record webapp.example.org -> server.example.org
Acessandowebapp.exemplo.orgvocê não precisa de SPNHTTP/webapp.exemplo.org, você deve atribuirHTTP/servidor.exemplo.orgSOMENTE para o registro de serviço. Acredito que deveria ser um endereço IP se também não houver registro PTR.
2. Os membros do domínio NÃO devem ser chamados por nenhum outro nome.
Eu tenho um servidor membro do domínio com IIS e autenticação integrada do Windows habilitada. Devido à minha configuração de rede, ele possui configuração de DNS tanto na rede sem domínio quanto na rede de domínio:
srv.example.org -> 10.0.0.1
10.0.0.1 -> srv.example.org
E também registrou no domínio:
srv.tdm.example.org -> 10.0.0.1
Este servidor não permitiria o Kerberos se fosse acessado como srv.example.org, o Kerberos funcionará apenas se fosse acessado como srv.tdm.example.org. Ainda não funcionará se for acessado via endereço IP.
Eu acho que a natureza desse fato é causada pela resolução de nomes do Windows no domínio, que geralmente acontece antes do DNS.
Continuarei pesquisando e atualizarei esta resposta.