Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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.