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: http://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:
http://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: http://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:


http://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 Accessnã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: http://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:
http://mycomputer ou http://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: http://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: http://support.microsoft.com/?id=811889


319723 Information about SQL Server 2000 Kerberos support, including SQL Server: http://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: http://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:


 


http://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:
http://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)


http://go.microsoft.com/fwlink/?LinkId=40003


 


Getting Delegation to Work with IIS & ASP.NET—Ins and Outs of Protocol Transition—Part II (Level 300)


http://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/NTAuthenticationProviders

Se 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: http://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: http://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: http://support.microsoft.com/?id=327825


280830 Kerberos authentication may not work if user is a member of many groups: http://support.microsoft.com/?id=280830


 


 


 


[Mais informações]


 


Kerberos (synonyms): http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/techref/en-us/w2k3tr_kerb_how.asp


 


‘Whitepaper’ (Troubleshooting Kerberos Delegation):
http://www.microsoft.com/downloads/details.aspx?FamilyID=99b0f94f-e28a-4726-bffe-2f64ae2f59a2&displaylang=en


 


          (RFC1510): http://www.ietf.org/rfc/rfc1510.txt


 


 


[Kerberos errors]


 


Description of Common Kerberos-Related Errors in Windows 2000: http://support.microsoft.com/default.aspx?scid=kb;en-us;q230476
Troubleshooting Kerberos Errors: http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx
Service Logons Fail Due to Incorrectly Set SPNs:


http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/Operations/579246c8-2e32-4282-bce7-3209d1ea8bf1.mspx

Comments (1)

  1. madalena dias says:

    saudações

    sou madalena dias sou de angola eu vi que voce tem muita coisa interessante sobre redes por favor podes me enviar materias practicas de redes ligadas a intalacao de redes e configuraçao de routeres  e hardware e de software.

    muito obrigada pela anteçao

    madalena dias

Skip to main content