AD e o Firewall

RPC server not available.

Quem nunca viu isso ? Eu nos últimos meses encontrei muitos problemas relacionados a não comunicação entre servidores que estavam atrás de firewall ou possuía algum antivírus.

O maior do problemas é você afirmar que tal recurso não está funcionando devido ao firewall e o analista afirmar que não é firewall e que as portas estão liberadas.

Que situação, mas a parte legal é quando o firewall é desabilitado e tudo funciona e você dá só aquela olhadinha com cara de “Não disse.”

Como podemos testar e ter resultados em mãoes comprovando a existencia de bloqueios, filtros ou erros entre certos servidores ?

Será que apenas um Telnet na Porta 135 (RPC) é sinônimo de acesso 100% aos recursos do AD?

Primeiramente recomendo ter em seus favoritos s seguinte página Active Directory and Active Directory Domain Services Port Requirements

Depois o telnet é ótimo e uma excelente ferramenta de testes, mas possui algumas limitações. Por exemplo, se a porta está sendo filtrada ou testes de UDP não podem ser diagnosticados com ele por isso recomendo o uso do Portqry.

Em redes baseadas em Microsoft , você vai precisar trabalhar com protocolos baseados em UDP , como LDAP ou RPC . A maior parte da estrutura do protocolo NetBIOS utiliza UDP. Claro que a maioria é TCP mesmo veja a tabela de alguns recursos do AD e suas portas:

.

Tabela copiada de <http://technet.microsoft.com/en-us/library/replication-error-1722-the-rpc-server-is-unavailable(v=ws.10).aspx>

Port Query

Vamos usar nesse exemplo a ferramenta Port Query UI (portqueryui.exe) que é uma ferramenta para consultar as portas abertas.

Em duas versões, linha de comando e com interface gráfica (Baixe a versão gráfica que já vem com a versão de linha de comando)

Para obter a ferramenta : http://download.microsoft.com/download/3/f/4/3f4c6a54-65f0-4164-bdec-a3411ba24d3a/PortQryUI.exe

Com o portqry temos 3 tipos de estados:

• Listening – Um processo está escutando na porta no computador que você selecionou.

• Not Listening – Nenhum processo está escutando a porta de destino no sistema de destino.
  Portqry.exe recebeu uma mensagem de Protocolo de Controle de Internet (ICMP) “Destination Unreachable – Port inacessível” mensagem de volta da porta UDP de destino. Ou se a porta de destino é uma porta TCP, Portqry recebeu um pacote de confirmação TCP com a flag reset

• Filtered – A porta no computador que você selecionou está sendo filtrada

Portqry.exe não recebeu uma resposta da porta . Um processo pode ou não ser ouvindo na porta . Por padrão, portas TCP são consultadas três vezes, e as portas UDP são consultadas uma vez antes de um relatório indica que a porta está filtrada

A vantagem de utilizar a interface gráfica é poder usar consultas predefinidas.

Você irá notar que existe um teste chamado Using ephemeral source port que exibe as conexões de troca entre o cliente e o server.

Quando o cliente se conecta na porta 80 ele abre uma porta no cliente. Essa é uma porta “efêmera”.

Assim fica mais fácil testar as conexões de AD e não se esqueça de testar de vários servidores para confrontar os resultados e ter um diagnóstico mais eficaz.

• Artigo migrado – 2114 acessos até a data 11/02/2016