Guia de ‘Troubleshooting’ para problemas de Kerberos no IIS6
Guia de ‘Troubleshooting’ para problemas de Kerberos no IIS6
Por: Joao Delinger de Souza
Olá pessoal,
Bem-vindo a comunidade do blog LATAM. Meu nome é Joao Delinger de Souza e trabalho na Microsoft há quase 6 anos. Trabalhei com diversos produtos durante esse tempo, no entanto durante os últimos 3 anos, ‘Internet Information Server’ foi o produto com que mais trabalhei e dei suporte aos clientes Premier.
Na coluna desse mês eu criei um simples guia para auxiliá-lo a resolver problemas de autenticação em Kerberos no IIS6.
Tenha em mente que, uma vez que esse assunto é bem complexo, teremos aquí como objetivo, manter esse guia o mais curto o possível.
Abaixo estão algumas siglas que usaremos nessa coluna:
AD - Active Directory;
IE - Internet Explorer
FQDN – Fully Qualified Domain Name
SPN - Service Principal Name
TGT - (Ticket Granting Ticket) – um ‘ticket’ para um cliente se autenticar no KDC
TGS - (Ticket Granting Service) Exchange
KDC - Key Distribution Server
AS - (Authentication Service) Exchange
AP - (Client/Server Authentication) Exchange
Guia de ‘Troubleshooting’ para problemas de Kerberos no IIS6
[Escopo]
O escopo desse guia é de lhe ajudar nos problemas relacionados à autenticaçaão Kerberos e IIS6. Esse guia não irá lhe explicar tudo em detalhes, porém fornecerá ótimas referências caso necessite se aprofundar mais no assunto.
[Introdução]
O cenário mais comum é uma aplicação rodando em um servidor IIS 6.0 no qual necessita ‘delegar’ o usuário autenticado em um outro servidor(es). Esse processo chama-se ‘delegation’ e requer Kerberos para funcionar corretamente no IIS e nos outros servidores que farão parte no processo de autenticação.
Aquí você pode ver o tráfego no Kerberos para o cenário acima citado. O cliente acessa o servidor IIS, a aplicação no IIS ‘impersonates’ a identidade do cliente e acessa o servidor SQL remoto:
Nesse ponto você não precisa entender o que ‘AS_REQ’ e ‘TGS_REQ’ significam.
Iremos mais para frente associar os números dos passos da figura acima com as seções de ‘Troubleshooting’ abaixo.
Antes disso, vamos verificar se o seu ambiente possue a configuração básica:
[Configuração Básica]
1) Todos os servidores pertencem ao mesmo Domínio/Floresta?
Se a resposta for não para um dos items acima, você terá que verificar se todas as relações de confiança (trusts) estão configuradas entre os domínios.
2) O servidor IIS está configurado para ‘Trusted Computer for Delegation’?
Isto pode ser feito através do Active Directory Users and Computers MMC, Domain\Computers\Computer name\Properties.
Win2000 mixed domains: na aba ‘General’ - ”Trust computer for delegation” deverá estar marcado.
Win2003 native: na aba ‘Delegation’ – no mínimo “Trust this computer for delegation to any service” deverá estar marcado.
Importante: após voce ter mudado a configuração acima no AD, voce terá que fazer um ‘purge’ nos tickets’ do cliente usando a ferramenta kerbtray ou simplesmente fazendo um LogOff/LogOn no cliente.
Kerbtray.exe: https://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/kerbtray-o.asp
Se você decidir usar “Constraint Delegation” e/ou “Protocol Transition”, veja a seção abaixo [Protocol Transition] .
3) Verifique que a conta que precisa ser ‘delegada’ não está marcada como “Account is sensitive and cannot be delegated“ no AD.
Essa operação pode ser feita via Active Directory Users and Computers MMC\User Account\Properties\aba Account\Account options.
4) Se o servidor ‘Backend’ (remoto) é um servidor MCS cluster, verifique todas as configurações descritas no artigo abaixo:
235529 Kerberos support on Windows 2000-based server clusters: https://support.microsoft.com/?id=235529
5) No servidor IIS6 certifique-se de que estamos passando o header ‘Negociate’ para o browser. Isso permite aos clientes selecionarem Kerberos ou NTLM:
215383-How to configure IIS to support both Kerberos and NTLM authentication: https://support.microsoft.com/default.aspx?scid=kb;EN-US;215383
No cliente certifique-se de que o Internet Explorer irá usar Kerberos:
Internet Options\Advanced "Enable Integrated Windows Authentication" deve estar marcado.Do contrário Internet Explorer irá usar NTLM em vez de Kerberos.
6) Se o servidor IIS está usando NLB (load balanced) consulte o artigo abaixo:
https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/kerbnlb.mspx
[Configuração no servidor IIS6]
Agora vamos checar a configuração no IIS6:
1) O cliente que requisita um Website/Virtual Directory precisa passar por um processo chamado “impersonation”.
Se a aplicação precisa delegar o usuário autenticado, certifique-se de que o Website/Virtual Directory não esteja configurado para usar ‘Anonymous Access’ via IIS MMC:
Website\Virtual Directory\Properties\Directory Security\Authentication Methods
"Enable Anonymous Access” não deve estar marcado;
“Integrated Windows Authentication” deve estar marcado.Se a aplicação for desenvolvida em ASP.Net, certifique-se de que o cliente será "impersonated". Abra o arquivo Web.config localizado na mesma pasta da aplicação e veja se na seção <System.web> voce possui o seguinte elemento: <identity impersonate="true" />:
306158 - How to implement impersonation in an ASP.NET application: https://support.microsoft.com/default.aspx?scid=kb;EN-US;306158
2) Verifique se temos que configurar um “Service Principal Name (SPN)” adicional para o servidor IIS. Este é um requerimento para o Kerberos funcionar corretamente.
Aqui estão os items que temos que checar:
A) O cliente está acessando o servidor IIS via Netbios name/AD FQDN ou DNS Alias?
Exemplo: https://mycomputer ou https://www.mysite.com
B) Normalmente o website sendo requisitado estará usando um ‘Application Pool’. Qual é a identidade configurada para esse ‘Application pool’?
IIS MMC: Internet Information Services\Application Pools\AppPoolName\Properties\Identity
Baseado na combinação de ambas (A e B) você talvez tenha que executar um passo adicional (registrar um novo SPN).
Veja a tabela abaixo:
AppPoolIdentity |
Accesso via |
Ação Requerida |
Configuração AD SPN |
NetworkService ou LocalSystem |
AD FQDN ou Netbios Name |
Nenhuma |
Object server: HOST/FQDN HOST/Netbiosname |
NetworkService ou LocalSystem |
DNS Alias |
SETSPN -A HTTP/DNSAlias Netbiosname |
Object server: HOST/FQDN HOST/Netbiosname HTTP/DNSALias |
Domain User |
AD FQDN or Netbios Name |
SETSPN -A HTTP/FQDN Domain\User SETSPN -A HTTP/Netbios Domain\User Certifique-se de que o usuário do domínio esteja marcado como “ Trust this User for delegation to any service” Active Directory Users and Computers MMC\UserAccount\Properties\aba Delegation |
Object server: HOST/FQDN HOST/Netbiosname Object User: HTTP/FQDN HTTP/Netbiosname |
Domain User |
DNS Alias |
SETSPN -A HTTP/DNSAlias Domain\User Certifique-se de que o usuário do domínio esteja marcado como “ Trust this User for delegation to any service” Active Directory Users and Computers MMC\UserAccount\Properties\aba Delegation |
Object server: HOST/FQDN HOST/Netbiosname Object User: HTTP/DNSAlias |
Nota: se um DNS CNAME for criado não será necessário adicionar nenhuma entrada para ele porque o cliente irá requisitar um TGS para o AD FQDN e não para o DNS CNAME. Maiores informações sobre o utilitário SETSPN:
SetSPN.exe: https://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/setspn-o.asp
Exemplo de como obter as configurações do SPN do servidor IIS:
Object Server: setspn –L Netbiosname
Object User: setspn –L DomainUser
[Configuração do servidor ‘Backend’]
O servidor backend (no qual IIS irá delegar o usuário ‘impersonated’), terá que ter um SPN válido registrado no AD, do contrário a comunicação entre o servidor IIS e o servidor Backend irá falhar. O servidor ‘Backend’ pode ser um servidor de arquivos, SQL, ou outro servidor IIS.
Para um servidor ‘Backend’ (IIS), use a tabela acima para verificar se algum SPN adicional deve ser registrado.
Para um servidor ‘Backend’ (SQL) , os seguintes arquivos se aplicam:
811889 How to troubleshoot the "Cannot generate SSPI context" error message: https://support.microsoft.com/?id=811889
319723 Information about SQL Server 2000 Kerberos support, including SQL Server: https://support.microsoft.com/?id=319723
824402 You receive a "Cannot generate SSPI context" error message when you use TCP/IP to connect to SQL Server 2000
(artigo ainda não publico)
Para um servidor SQL Analysis Server veja:
828280 How to configure an Analysis server computer to use Kerberos: https://support.microsoft.com/?id=828280
[Troubleshooting]
[Caching]
Se todos os passos acima foram verificados e a autenticação ainda não funciona corretamente, certifique-se de que voce não esteja enfrentando um problema de cache.
Se algumas mudanças foram feitas no AD, feche o seu IE e faça um "purge" nos ‘tickets’ usando o utilitário Kerbtray ou simplesmente faça um LogOff/Logon no cliente:
https://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/kerbtray-o.asp
Se as mudanças foram feitas na máquina de ‘Backend’ (IIS), reinicie o servidor.
[Tracing]
Começe o processo de ‘troubleshooting’ no cliente:
Verifique se o cliente requisitou um ticket para o ‘IIS hostname’ (use a ferramenta Kerbtray):
Kerbtray\List Tickets > Voce deverá ver um ticket com o nome HTTP/FQDN. Caso voce não o veja, colete um trace de rede no cliente.
Aqui está um exemplo de um ‘trace’ de rede com uma requisição bem sucedida:
Primeiro passo é um ‘GET’ emitido pelo cliente para o IIS. Veja o ‘Host Header’, pois é com esse nome que o cliente irá fazer o pedido do ticket via Kerberos.
HTTP: GET Request from Client
HTTP: Request Method =GET
HTTP: Uniform Resource Identifier =/t.asp
HTTP: Protocol Version =HTTP/1.1
HTTP: Host =much108
A resposta será um 401, porque o cliente precisa fornecer as credenciais:
HTTP: Response to Client; HTTP/1.1; Status Code = 401 - Unauthorized
HTTP: Protocol Version =HTTP/1.1
HTTP: Status Code = Unauthorized
HTTP: Reason =Unauthorized
HTTP: Server =Microsoft-IIS/6.0
HTTP: WWW-Authenticate =Negotiate
HTTP: WWW-Authenticate =NTLM
Repare no cabecalho ‘WWW-Authenticate’ acima. O IIS envia esse cabecalho contendo os metodos de autenticação. Certifique-se de que a palavra ‘Negotiate’ esteja presente no cabeçalho. Se ela não estiver presente leia a seção [NTAuthenticationProviders] no final desse documento.
A próxima requisição é um KRB_AS_REQ para o KDC, no qual seria o passo (1) na figura acima:
KERBEROS: KRB_AS_REQ
KERBEROS: Request body (req-body[4])
KERBEROS: Client name (cname[1]) =administrator
KERBEROS: Principal name value (name-string[1]) =administrator
KERBEROS: Realm (realm[2]) =REQ90198.ILS
KERBEROS: Server name (sname[3]) =krbtgt/REQ90198.ILS
KERBEROS: Principal name type (name-type[0]) = KRB_NT_SRV_INST (Service & other unique instance)
KERBEROS: Principal name value (name-string[1]) =krbtgt/REQ90198.ILS
A resposta com exito deve ser um kerberos: KRB_AS_REP. Note que você verá KRB_AS_REQ apenas para a primeira requisição:
Em seguida o cliente requisita o TGS para a máquina ‘much108’ , no qual é o passo (2) na nossa figura acima,
Você verá que o cliente requisita o SPN do FQDN a partir do HTTP GET:
KERBEROS: KRB_TGS_REQ
KERBEROS: Request body (req-body[4])
KERBEROS: Realm (realm[2]) =REQ90198.ILS
KERBEROS: Server name (sname[3]) =HTTP/much108.req90198.ils
KERBEROS: Principal name type (name-type[0]) = KRB_NT_SRV_INST (Service & other unique instance)
KERBEROS: Principal name value (name-string[1]) =HTTP/much108.req90198.ils
A resposta com exito deverá ser kerberos: KRB_TGS_REP
Finalmente o cliente envia um GET novamente com o ticket. Esse seria o passo (3) na nossa figura acima.
No cabeçalho ‘HTTP Authorization’ você verá algo como:
HTTP: GET Request from Client
HTTP: Request Method =GET
HTTP: Uniform Resource Identifier =/t.asp
HTTP: Host =much108
HTTP: Connection =Keep-Alive
HTTP: Data: Number of data bytes remaining = 1262 (0x04EE)
HTTP: Authorization =Negotiate YIIJ4wYGKwYBBQUCoIIJ1zCCCdO gJDAiBgkqhkiC9x…..
Importante: ‘Negotiate’ não necessariamente significa que um ticket Kerberos foi transferido. ‘Negotiate’ pode ser Kerberos ou NTLM.
Abaixo está um exemplo em um trace de rede. Uma boa indicação que NTLM foi usado seria a existencia da seguinte string: ‘TlRMTVNTUA’.
HTTP: Authorization =Negotiate TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFASgKAAAAD
Se o IIS apenas oferece NTLM ou se o IE está configurado para não suportar o cabeçalho ‘Negotiate’, voce verá o seguinte cabecalho:
HTTP: Authorization =NTLM TlRMTVNTUAABAAAAB7IIoggACAAvAAAABwAHACgAAAAFASgKAAAAD01VQ0
No final, a resposta do servidor IIS deverá ser um 200 OK:
HTTP: Response to Client; HTTP/1.1; Status Code = 200 - OK
Se um ticket Kerberos foi transferido para o cliente mas você ainda obtem um ’access denied’, eu recomendo habilitar o
‘Auditing’ para ‘Logon Event Failures / User Logon Failures’ no IIS usando Local Security Policy MMC.
Caso você veja falhas de logon no log de eventos de segurança, verifique novamente se o(s) SPN(s) no IIS foram registrados conforme a tabela acima.
Nota: se todos os passos acima não resolverem o seu problema, eu sugiro tirar um trace de rede no servidor ‘backend’ para verificar todo o trafego do Kerberos, pois o passo (4) acima na figura ainda pode falhar.
[Protocol Transition]
O uso de Kerberos Constraint Delegation (S4U2Proxy) e Protocol Transition (S4U2Self) estão somente disponíveis em domínios nativos Windows 2003.
Estas novas caracteristicas podem ser configuradas via Active Directory Users and Computers MMC, Domain\computers\computer name\properties\aba ‘Delegation’.
Constraint Delegation (S4U2Proxy) significa que o ‘delegate’ é apenas permitido delegar para especificos serviços configurados.
A configuração para o S4U2Proxy seria a combinação de “Trust this computer for delegation to specific services only” e “Use Kerberos only”.
Se selecionado você precisará adicionar o service para o qual você deseja delegar; um servidor SQL por exemplo (veja o ‘scren shot’ abaixo).
Protocol Transition (S4U2Self) permite o servidor IIS requisitar um ticket Kerberos para um usuário que foi autenticado pelo IIS usando um protocolo differente como NTLM ou Basic. Por exemplo, o cliente pode autenticar no IIS usando ‘Basic Authentication’ (SSL). Após isso, o IIS requisitará um ticket Kerberos em nome do cliente (nesse caso o cliente não precisa acessar o KDC diretamente pois o IIS acessará o KDC para ele) e o restante do processo de autenticação até o SQL é feita toda em Kerberos.
A configuração para o S4U2Self seria a combinação de “Trust this computer for delegation to specific services only” e “Use any authentication protocol”.
O exemplo abaixo mostra como ‘Protocol Transition’ é configurado no IIS (Much108) para estar apto a delegar para o servidor SQL remoto (Much111).
Find more details about this advanced topic here:
https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerbdel.mspx
Getting Delegation to Work with IIS & ASP.NET—Ins and Outs of Protocol Transition—Part I (Level 300)
https://go.microsoft.com/fwlink/?LinkId=40003
Getting Delegation to Work with IIS & ASP.NET—Ins and Outs of Protocol Transition—Part II (Level 300)
https://go.microsoft.com/fwlink/?LinkId=40004
[NTAuthenticationProviders]
Caso o servidor IIS não responda com o cabecalho ‘Negotiate’ em um ‘401 response’, exemplo:
HTTP: WWW-Authenticate =Negotiate
você terá que checar as configurações no Metabase (NTAuthenticationProviders) usando o script ‘adsutil.vbs’ (diretório default C:\Inetpub\AdminScripts):
cscript adsutil.vbs get w3svc/NTAuthenticationProvidersSe o resultado do script for ‘NTLM’ então adicione a palavra ‘Negotiate’ rodando o mesmo script:
cscript adsutil.vbs set w3svc/NTAuthenticationProviders Negotiate,NTLM
[IIS retorna “400 Bad Request” para ‘Kerberos tokens’ muito grandes]
Se o seu ‘Kerberos token’ for maior do que > 16kb, você receberá a mensagem acima.
Para a versão IIS5 configure’MaxClientRequestBuffer’ conforme artigo abaixo:
310156 How to limit the header size of the HTTP transmission that IIS accepts: https://support.microsoft.com/?id=310156
Para a versão IIS6 configure ‘MaxFieldLength’ e ‘MaxRequestBytes’ no registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters
Name: MaxFieldLength
Type: DWORD
Value: 32768 (decimal)
Name: MaxRequestBytes
Type: DWORD
Value: 32768 (decimal)
Artigo: 820129 INF: Http.sys Registry Settings for IIS: https://support.microsoft.com/?id=820129
[MaxTokenSize e erro: “out of memory”]
Se um usuário pertence a muitos grupos, o valor default (12kb) em ‘MaxTokenSize’ não será o suficiente. Favor consultar os seguintes artigos sobre esse tópico:
327825 New Resolution for Problems That Occur When Users Belong to Many Groups: https://support.microsoft.com/?id=327825
280830 Kerberos authentication may not work if user is a member of many groups: https://support.microsoft.com/?id=280830
[Mais informações]
Kerberos (synonyms): https://www.microsoft.com/resources/documentation/WindowsServ/2003/all/techref/en-us/w2k3tr_kerb_how.asp
‘Whitepaper’ (Troubleshooting Kerberos Delegation):
https://www.microsoft.com/downloads/details.aspx?FamilyID=99b0f94f-e28a-4726-bffe-2f64ae2f59a2&displaylang=en
(RFC1510): https://www.ietf.org/rfc/rfc1510.txt
[Kerberos errors]
Description of Common Kerberos-Related Errors in Windows 2000: https://support.microsoft.com/default.aspx?scid=kb;en-us;q230476
Troubleshooting Kerberos Errors: https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx
Service Logons Fail Due to Incorrectly Set SPNs: