Freigeben über

Problema intermitente de autenticação com ISA Server

  • Artikel

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

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

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

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

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

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

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

Até a próxima....

Comments

  • Anonymous
    January 01, 2003
    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

  • Anonymous
    January 01, 2003
    Olá Maycon, Obrigado pela visita ao nosso blog e obrigado pelos comentário. Yuri Diógenes

  • Anonymous
    January 01, 2003
    Obrigado Maia, pela visita e pelo feedback. Yuri Diógenes

  • Anonymous
    September 06, 2006
    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 []

  • Anonymous
    September 06, 2006
    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.

  • Anonymous
    September 07, 2006

    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.

  • Anonymous
    September 07, 2006
    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.

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

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

  • Anonymous
    December 09, 2006
    Yuri, parabéns pelo post, realmente muito bom ainda bem que existem pessoas como você !! rsrsr.. Grande abraço....

  • Anonymous
    March 15, 2007
    The comment has been removed