Problema intermitente de autenticação com ISA Server



Problema intermitente de autenticação com ISA Server


Por: Yuri Diógenes


 


1. Introdução


 


Já foram cerca de três casos nos últimos quatro meses em que esta indagação foi feita por clientes. Esse é o tipo do problema que parece ser algo simples de resolver, porém não é, principalmente porque estamos lidando com vários elementos que podem acarretar este tipo de comportamento. Neste caso também é importante salientar que o pedido de autenticação não é algo constante, só acontece em alguns momentos do dia. O ISA não necessariamente vai ser o culpado, as vezes ele é simplesmente a vítima. Vejamos a seguir alguns passos que podem ser seguidas quando um problema desta natureza ocorre.


 


2. Cenário


 


O cenário pode ser simples como também pode ser complexo, até mesmo porque independente da complexidade, o que precisa ser feito de fato é um aparato de coleta de dados para que se chegue a uma conclusão acerca da causa raiz do problema.


 


É importante definir de forma bem clara o sintoma a qual estamos trabalhando, apesar de já ter sido falado acima, vamos ser bem específicos quanto a o que ocorre: usuários são perguntados por autenticação quando estão navegando em sites durante alguns momentos do dia.


 


Para fins didáticos iremos usar um cenário de topologia simples, conforme mostra a figura abaixo:


 



 


No servidor ISA estamos usando autenticação integrada para acesso a web. Temos uma regra de navegação para Internet que requer autenticação, conforme mostra abaixo:


 



 


Em um cenário normal, sem problemas o que esperamos que acontece é a seguinte seqüência:


OBS: os exemplos de pacotes abaixo são resumidos, na prática outros pacotes aparecerão.


 


1. O cliente faz uma requisição para o servidor ISA para acessar um site, no exemplo será o www.msn.com:


 



192.168.0.180         192.168.0.3           HTTP     GET http://www.msn.com/ HTTP/1.0


 


2. O servidor ISA recebe o pacote, verifica as regras para este tipo de acesso e como a regra requer autenticação o ISA envia de volta para o cliente o seguinte pacote:


 



192.168.0.3           192.168.0.180         HTTP     HTTP/1.1 407 Proxy Authentication Required ( The ISA Server requires authorization to fulfill the request. Access to the Web Proxy filter is denied.  ) (text/html)


 


3. A negociação de autenticação acontece:


 



192.168.0.180         192.168.0.3           HTTP     GET http://www.msn.com/ HTTP/1.0, NTLMSSP_NEGOTIATE


 



192.168.0.3           192.168.0.180         HTTP     HTTP/1.1 407 Proxy Authentication Required ( Access is denied.  ), NTLMSSP_CHALLENGE


 



192.168.0.180         192.168.0.3           HTTP     GET http://www.msn.com/ HTTP/1.0, NTLMSSP_AUTH, User: CTEST\Administrator


 


4. Após o ISA receber as informações de autenticação do usuário, então ele vai validar tais informações no DC:


 



192.168.0.3           192.168.0.10          RPC_NETLOGON NetrLogonSamLogonEx request


192.168.0.10          192.168.0.3           RPC_NETLOGON NetrLogonSamLogonEx response


 


5. Partindo do pressuposto que o DC vai validar corretamente as credenciais, o ISA então volta a conversar com o cliente e o cliente começa a navegar corretamente no site.


 


Vejamos então o que fazer para deixar o ambiente pronto para capturar os dados.


 


3. Preparando o Ambiente


 


Para endereçar tal problema, antes mesmo de iniciarmos a preparação do ambiente devemos ter as respostas para as seguintes questões:


·         Geralmente que horário do dia tal problema ocorre?


·         Durante quanto tempo o problema continua ocorrendo?


·         O que é feito para resolver o problema? Há uma solução de contorno?


·         Há algum evento no log de sistemas do servidor ISA quando este problema ocorre?


 


Para nosso cenário fictício, as respostas foram:


 


·         O problema geralmente ocorre durante 7:30 e 8:30 da manhã. As vezes também ocorre entre 13 e 14 horas.


·         O problema ocorre as vezes por 10 minutos, as vezes por 5 minutos e algumas vezes por segundos.


·         Nada é feito para resolver, na realidade na maioria das vezes pedimos para o usuários simplesmente cancelar a tela de logon e tentar acessar o site novamente. Algumas vezes isso é suficiente outras ele tem que tentar múltiplas vezes até conseguir.


·         Sim, dois logs são criados, são eles:


 



Event ID     : 5719


Raw Event ID : 5719


Record Nr.   : 1


Category     : None


Source       : NETLOGON


Type         : Error


Generated    : 8/23/2006 7:45:45 AM


Written      : 8/23/2006 7:45:45 AM


Machine      : ISANAME


Message      : This computer was not able to set up a secure session with a domain


controller in domain DOMAINNAME..


 



Type: Error


Date: 08/23/2006


Time: 07:46:43


Event ID: 5783


Source: NETLOGON


User: N/A


Computer: ISANAME


Details:


The session setup to the Windows NT or Windows 2000 Domain Controller \\DCNAME for the domain DOMAINNAME is not responsive.


 


Bem, esse é o tipo do problema que as vezes é difícil de sincronizar as informações necessárias para que tenhamos tudo que está ocorrendo na hora que tal tela aparece. Muitas vezes o maior desafio deste tipo de problema é fazer com que as informações sejam capturadas ao mesmo tempo em todos os servidores envolvidos, neste caso: no cliente (opcional), no domain controller e no servidor ISA.


 


Mas, as respostas que foram dadas já são elementos chave para darmos início as hipóteses válidas para tal situação, vejamos: Se o problema só ocorre durante estes horários fica a pergunta: o que há na rede durante estes horários? Na maioria das vezes a resposta é: temos mais tráfego devido a termos diversos usuários fazendo logon. Com base nisso já podemos desconfiar de problemas de performance, mas performance aonde? No DC, no ISA, na rede? Isso é que iremos ver…


 


3.1. Preparando o Domain Controller


 


Uma das primeiras medidas que precisa ser realizada no domain controller é assegurar que temos os seguintes componentes ativos:


a.      Network Monitor: instale o netmon através do Painel de Controle do Windows, aumente o configuração de buffer para no mínimo 200 MB para não haver perigo de perdermos informações durante a coleta, deixe o netmon sempre ativo no servidor;


b.      Netlogon Log: aumente o log do netlogon, para fazer isso (pressupondo que o servidor tem as ferramentas de suporte do Windows instalada), vá ao prompt de comando e digite: nltest /dbflag:0x2080ffff. Este comando vai aumentar o nível de log no arquivo %windir%\debug\netlogon.log. Para mais informações sobre este comando veja o artigo KB109636.


c.      Performance Advisor: instale a ferramenta Windows Server Performance Advisor. Esta ferramenta vai analisar diversos aspectos de performance no controlador de domínio. Para baixar esta ferramenta clique aqui.


 


3.2. Preparando o Servidor ISA


 


A preparação do servidor ISA consiste em usar os itens A e B da preparação acima. Com a observação de que ao configurar o netmon é preciso vincular a captura na placa de rede interna do ISA.


 


4. O problema aconteceu!!! O que fazer?


 


Tendo em vista que temos os componentes já configurados em todas as pontas o que  precisamos agora é capturar todas as informações quando o problema ocorrer. Para isso temos que:


·         Parar a captura do netmon no ISA e no DC logo após o problema ocorrer;


·         Copiar o arquivo do netlogon.log do ISA e do DC para um outro local, caso contrário as informações serão sobrescritas;


·         Executar o SPA no DC quando o problema estiver ocorrendo.


 


5. Análisando e Criando um Plano de Ação


 


Agora que temos os dados, verifique os seguintes pontos:


 


5.1 Analisando o Network Monitor:


·         Abra o resultado da captura do netmon do servidor ISA e faça um filtro para o ISA e o DC. O que você tem nesta comunicação? Tem alguma demora na conversação?


·         Verifique se o equipamento ativo de rede (neste caso a switch) tem estatísticas de uso e poderia mostrar possíveis gargalos na comunicação. Use o artigo abaixo como referência:


 


325487           How to troubleshoot network connectivity problems


http://support.microsoft.com/?id=325487


 


·         Abra também a captura que foi feita no DC e compare os resultados? Alguma mensagem de erro na comunicação?


·         Faça filtros também para o IP do cliente, por exemplo: Do ISA para o cliente e vice versa, o que temos?


·         Caso seja detectado tais demoras e enfileiramento na comunicação entre ISA e DC é importante verificar a chave de registro mencionada no artigo abaixo.


 


326040           How to configure an ISA Server computer for a very large number of authentication requests


http://support.microsoft.com/?id=326040


 


OBS: Dos três casos mencionados no início do artigo, um foi resolvido com esta mudança de registro.


 


Outro artigo muito importante para parametrizações de registro TCP/IP em cenários desta natureza é o artigo abaixo:


 


839880           How to troubleshoot RPC Endpoint Mapper errors


http://support.microsoft.com/?id=839880


 


 


5.2. Analisando o netlogon.log


·         Abra o arquivo netlogon.log no ISA e verifique a hora que o problema ocorreu, veja nesta hora o que temos na comunicação com o DC;


·         Um exemplo típico de problemas na comunicação entre estes dois servidores é o resultado abaixo:


 



<timestamp> [CRITICAL] WW001: NlSessionSetup: Session setup: cannot I_NetServerReqChallenge 0xc0020018


<timestamp> [MISC] Eventlog: 5719 (1) “<domain>” 0xc0020018 c0020018 …. <timestamp> [SESSION] <domain>: NlSetStatusClientSession: Set connection status to c000005e


 


ou


 



<timestamp>  [CRITICAL] NlPrintRpcDebug: Couldn’t get EEInfo for I_NetLogonSamLogonEx: 1761 (may be legitimate for 0xc0020018)


<timestamp> [CRITICAL] DOMAINNAME: NlpUserValidateHigher: denying access after status: 0xc0020018 1


 


Note que o evento que aparece no arquivo netlogon.log é o mesmo que aparece no log de sistema (5719). No segundo exemplo tempos o erro 0xc0020018, que por sua vez significa “The RPC server is too busy to complete this operation.”.


Tais erros no netlogon.log são indícios que o domain controller está passando por uma alta utilização naquele momento. No Windows Server 2003 com SP1 existe um problema documentado acerca disso, neste caso use o artigo abaixo para saber a solução:


 


You may receive an “RPC server is too busy to complete this operation” error message when you try to log on to a computer that is running Windows Server 2003 with Service Pack 1


http://support.microsoft.com/?id=905700


 


Como o artigo acima sugere a aplicação de um hotfix, confira se as versões dos arquivos a qual o hotfix está aplicando são mais novas do que a que existe nos servidores (ISA e DC).


 


OBS: Dos três casos que falei no começo deste artigo, dois foram resolvidos com este hotfix.


 


5.3. Analisando o SPA


·         Verifique se há problemas de performance no servidor;


·         O SPA gera um relatório em XML que você poderá facilmente identificar se o servidor está passando por algum problema de performance ou não. Abaixo temos um exemplo do que seria este relatório:


 


Não é raro também que algumas vezes cheguemos a conclusão através deste relatório que o problema é a performance do DC, as vezes temos um gargalo de processador. Um exemplo disso é: se o DC durante do problema tiver o contador Process Queue Length maior que 2 por processador isso já sinaliza um gargalo.


 


Para uma referência acerca dos contadores e resultados esperados, veja o artigo abaixo:


 


Windows 2000 Performance Tuning


http://www.microsoft.com/technet/prodtechnol/windows2000serv/maintain/optimize/perftune.mspx


 


 


6. Conclusão


 


A principal mensagem deste artigo é mostrar que problemas de autenticação no ISA podem ser categorizados em três tipos básicos:


 


·         Problemas constantes.


·         Problemas que acontecem ao acessar determinados sites.


·         Problemas que acontecem em determinadas horas do dia


 


O artigo se preocupou mais em descrever sobre o último tipo, pois é um tema onde diversos elementos são necessários para se chegar a uma conclusão. Para os outros dois tipos recomendo principalmente a utilização do “Paper” abaixo:


 


Troubleshooting Client Authentication on Access Rules in ISA Server 2004


http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/ts_client_rules.mspx


 


Até a próxima….


 

Comments (11)

  1. Anonymous says:

    Olá Ricardo,

    O artigo abaixo explica os detalhes da autenticação no ISA 2006:

    http://www.microsoft.com/technet/isa/2006/authentication.mspx

    Espero que lhe ajude.

    Grato,

    Yuri Diogenes

  2. Anonymous says:

    Olá Maycon,

    Obrigado pela visita ao nosso blog e obrigado pelos comentário.

    Yuri Diógenes

  3. Anonymous says:

    Obrigado Maia, pela visita e pelo feedback.

    Yuri Diógenes

  4. Rubens Zolotujin says:

    olha eu resolvi isto da seguinte forma:

    instala o windows 2003 server

    nao coloca a maquina no dominio

    instala o isa 2004 depois aplica o sp2 do isa 2004

    e depois coloca a maquina no dominio

    nunca mais se vai ter problemas…

    ai basta fazer as suas politicas de acesso..

    1 []

  5. Yuri Diogenes says:

    Olá Rubens,

    Uma das coisas que procurei mostrar no artigo é que a origem deste problema podem ser várias, este são exemplos de possíveis causas que levam a tal comportamento. Porém, no seu caso se as ações que você fez resolveu isso provavelmente leva a crer que o sintoma era o mesmo porém a causa raiz era outra.

    Quando você remove o servidor e coloca novamente no domínio o canal de segurança entre o servidor membro (ISA) e o DC é refeito (reset secure channel) e caso o canal de segurança seja a causa raiz do problema então ele será realmente resolvido.

    Então seu plano de ação é válido, porém caso a causa raiz não seja o canal de segurança o problema voltará acontecer. Principalmente se for um problema de performance nos DCs.

    Grande abraço e obrigado por contribuir com seu feedback.

  6. Luciano de Lima - MVP Windows Server Brasil says:

    Yuri parabéns pelo excelente artigo. Realmente esse é um problema muito difícil de resolver.

    Estou publicando esse e outros artigos que você escreveu lá no fórum do TechnetBrasil e o pessoal está adorando.

    Essa é uma ótima iniciativa do Latin America Support Team, o qual tem compartilhado com o público essas maravilhosas informações.

    Um grannnnnnnnnde abraço e até a próxima.

  7. Yuri Diogenes says:

    Obrigado Luciano.

    Feedbacks como este servem de estímulo para o Time continuar publicando artigos e contribuindo para o crescimento das comunidades virtuais.

    Grande Abraço.

  8. Maycon Alves D. Costa says:

    Yuri show de postagem, excelente mesmo, meus parabêns , um grande abraço do amigo Maycon Alves.

  9. Maycon Alves D. Costa says:

    Yuri show de postagem, excelente mesmo, meus parabêns , um grande abraço do amigo Maycon Alves.

  10. Maia says:

    Yuri, parabéns pelo post, realmente muito bom ainda bem que existem pessoas como você !! rsrsr..

    Grande abraço….

  11. Ricardo Soares says:

    Show de bola seu artigo Yuri.

    Só tenho uma dúvida:

    Como o ISA procurar e encontra um domain controler para validar as requisições?

    Ele utiliza o reverso de DNs para encontrar um DC?

    Existe algum documento microsoft que diz como é feita essa procura de DCs para que o ISA autentique os usuários?

    Desde já muito obrigado

    Ricardo Soares