Isolando Problemas onde o ISA Server Parece ser o Culpado – Sessão 3

Por: Yuri Diógenes

1. Introdução

Na sessão passada vimos um cenário de VPN bastante interessante, onde o ISA realmente parecia ser o culpado. Porém no final foi visto que o roteador/modem era o elemento que causava o problema. Cenários que envolvem conectividade entre componentes de terceiros são sempre desafiadores e este próximo cenário mais uma vez mostra isso.

2. Cenário – ISA Server parou de autenticar os usuários de domínio

Neste cenário o problema final era que os usuários de domínio não conseguiam acessar a Internet, o ISA sempre pedia autenticação. O pedido de autenticação era para qualquer usuário e mesmo quando o usuário digitava corretamente as credenciais o problema persistia.

Um outro comportamento em particular que acontecia neste cenário é que ao abrir as políticas de Firewall o erro abaixo acontecia:

"The trust relationship between this workstation and the primary domain failed. 0x800706fd"

A partir deste erro podemos entender que este servidor ISA que era membro do domínio estava tendo dificuldades para acessar o controlador de domínio. Contudo ainda não estava claro que este era o problema.

2.1. Coletas

Como se tratava de um problema de acesso, iniciamos uma bateria de testes básicos para entender o nível de acesso que era possível estabelecer entre o ISA e os controladores de domínio.

Adicionalmente usamos também o NLTEST para tentar reiniciar o canal de segurança mas a comunicação com o controlador de domínio não acontecia de forma alguma. Resolvi obter uma captura de rede para entender o que estava de fato ocorrendo.

3.3. Análise

A coleta de dados foi fundamental para a determinação da causa raiz. Pois foi possível entender o que estava ocorrendo a nível de rede durante esta comunicação:

· O teste foi realizado colocando o network monitor no servidor ISA (placa interna) e executando novamente o comando nltest /sc_verify:ctest. Foi possível então observar que o 3 way handshake acontecia normalmente e foi negociado a comunicação RPC e negociação de “End Point Mapper”:

2788 15:24:32.530 192.168.0.8 clusterdc.ctest.com TCP TCP: Flags=.S...... , SrcPort=1571, DstPort=DCE endpoint resolution(135), Len=0, Seq=853700869, Ack=0, Win=16384 (scale factor not found)

2789 15:24:32.530 clusterdc.ctest.com 192.168.0.8 TCP TCP: Flags=.S..A... , SrcPort=DCE endpoint resolution(135), DstPort=1571, Len=0, Seq=3785297540, Ack=853700870, Win=16384 (scale factor not found)

2790 15:24:32.530 192.168.0.8 clusterdc.ctest.com TCP TCP: Flags=....A..., SrcPort=1571, DstPort=DCE endpoint resolution(135), Len=0, Seq=853700870, Ack=3785297541, Win=17520 (scale factor not found)

· Em seguida o servidor ISA tenta fazer o vínculo (bind) usado portas altas:

2791 15:24:32.530 192.168.0.8 clusterdc.ctest.com MSRPC MSRPC: c/o Bind: UUID{E1AF8308-5D1F-11C9-91A4-08002B14A0FA} Endpoint Mapper Call=0x1 Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0

+ Tcp: Flags=...PA..., SrcPort=1571, DstPort=DCE endpoint resolution(135), Len=72, Seq=853700870 - 853700942, Ack=3785297541, Win=17520 (scale factor not found)

- RPC: c/o Bind: UUID{E1AF8308-5D1F-11C9-91A4-08002B14A0FA} Endpoint Mapper Call=0x1 Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0

  + Bind: {E1AF8308-5D1F-11C9-91A4-08002B14A0FA} Endpoint Mapper

· O pacote enviando pelo ISA não é respondido e com isso o servidor ISA faz uma retransmissão e 3 segundos depois o controlador de domínio envia o TCP Reset:

2831 15:24:35.155 clusterdc.ctest.com 192.168.0.8 TCP TCP: Flags=..R....., SrcPort=DCE endpoint resolution(135), DstPort=1571, Len=0, Seq=3785297601, Ack=3785297601, Win=0 (scale factor not found)

- Tcp: Flags=..R....., SrcPort=DCE endpoint resolution(135), DstPort=1571, Len=0, Seq=3785297601, Ack=3785297601, Win=0 (scale factor not found)

    SrcPort: DCE endpoint resolution(135)

    DstPort: 1571

    SequenceNumber: 3785297601 (0xE19F0EC1)

    AcknowledgementNumber: 3785297601 (0xE19F0EC1)

  + DataOffset: 80 (0x50)

  - Flags: ..R.....

     CWR: (0.......) CWR not significant

     ECE: (.0......) ECN-Echo not significant

     Urgent: (..0.....) Not Urgent Data

     Ack: (...0....) Acknowledgement field not significant

     Push: (....0...) No Push Function

     Reset: (.....1..) Reset

     Syn: (......0.) Not Synchronize sequence numbers

     Fin: (.......0) Not End of data

    Window: 0 (scale factor not found)

    Checksum: 34874 (0x883A)

    UrgentPointer: 0 (0x0)

Nesse momento o que ocorre é a seguinte mensagem de erro:

Flags: 80

Trusted DC Name

Trusted DC Connection Status Status = 1311 0x51f ERROR_NO_LOGON_SERVERS

Trust Verification Status = 1311 0x51f ERROR_NO_LOGON_SERVERS

The command completed successfully

4. Conclusão

Após este teste ficou claro que havia algo entre o controlador de domínio e o ISA que estava de alguma forma barrando a comunicação correta. Esta conclusão é devido ao fato de que toda a rede interna do usuário não tinha problema. Todos os serviços de logon interno funcionavam corretamente, toda comunicação RPC era estabelecida.

Envolvemos o time de segurança e foi então que descobrimos que o administrador do Firewall (que só naquele momento foi revelado que existia) havia instalado um software adicional no firewall que fazia um tipo de análise de conteúdo e dinamicamente bloqueava portas. Após desinstalar este produto a comunicação entre o ISA e o controlador de domínio ocorreu corretamente e os usuários voltaram a ter acesso a Internet corretamente.