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.


 




















Testes Realizados a Partir do ISA


Resultado


Observações


Execução de um ping para os controladores de domínio


Resposta realizada com sucesso



netdiag /v


Um dos principais erros observado foi o mostrado abaixo:


 


DC list test . . . . . . . . . . . : Failed


[WARNING] Cannot call DsBind to clusterdc.ctest.com


(192.168.0.10). [RPC_S_CALL_FAILED]


 


Trust relationship test. . . . . . : Failed


Test to ensure DomainSid of domain ‘CTEST’ is correct.


[FATAL] Secure channel to domain ‘CTEST’ is broken.


[ERROR_NO_LOGON_SERVERS]


 


É possível notar problemas na comunicação RPC. O teste do canal de segurança pode ser apenas uma vítima neste momento.


nltest /sc_verify:ctest


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


Para testar o canal de segurança o NLTEST foi executado, porém também sem sucesso.


 


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.


 


 

Comments (0)