Vérifier les ports pour un domaine en trust

[hmi]

http://www.microsoft.com/downloads/deta ... laylang=en
· Invoke PortqryUI.exe

· Enter replication partner’s IP or FQDN in the “Destination to query” textbox.

· Select Pre-defined query – “Domains and Trusts”.

· Hit the “Query” button and let it finish.

· Save the above output to a text file.



o through the PortqryUI query result by searching for “Return Code” phrase in the output.

è If the return code is 0, it indicates that this DC was able to communicate with its partner DC on that particular port.

è The return code 2 is normally reported for UDP ports as we don’t get an ACK for that communication. This can be ignored if it’s returned for a UDP port.

è The return code of 1 indicates that this DC was unable to talk to the target DC on the respective port. This either indicates that the service related to this port is not running on the target or that port is FILTERED on the firewall.

è Any other return code also needs investigation.




Sample output of PortqyrUI

In our scenario, we need to ensure that the following ports are open on both these DCs.

· TCP 135 – Endpoint mapper

· TCP,UDP 389 – LDAP

· TCP, UDP 88 – Kerberos

· TCP 445 – SMB

· TCP 139 – SMB, Namepipe

· TCP, UDP 53 – if these servers are DNS servers too.



Out of the above ports, the one that is most IMP to look at in the RPC related errors is TCP 135.

à This is the Endpoint Mapper port. A DC would first communicate with its partner on port 135 to get the details of the TCP ports the NTDS and Netlogon services are listening on. It’s only when it gets this response from the Endpoint mapper that it would communicate with the NTDS (DRS) and Netlogon service on the target DC (Partner DC).



To get the list of the Endpoints on the partner DC and get the list of services and the ports associated with it, we can use another tool called RPCdump. This tool also has the capability of checking if source server can communicate with all endpoint on the destination server.



RPCdump is a part of Windows resource kit.

http://www.microsoft.com/downloads/deta ... laylang=en



Command : RPCDUMP /s destination_server /v /i > RPCdump_destination.txt



In our scenario, we need to review the TCP port the DRS Interface is listening on. You can either search using the phrase DRS or using the following UUID e3514235-4b06-11d1-ab04-00c04fc2dcd2.



Other UUIDs:

e3514235_4b06_11d1_ab04_00c04fc2dcd2 DRS

12345778_1234_abcd_ef00_0123456789ab LSA

12345678_1234_abcd_ef00_01234567cffb NETLOGON

12345778_1234_abcd_ef00_0123456789ac SAM



When looking at this log we need to check if for the respective UUID and IsListening result.

è IsListening:YES – this means that the source server was able to communicate with target server on the respective port.

è IsListening:NO – means that this port is filtered on the firewall.

è IsListening:Unknown – this may mean that you need to investigate further as packets targeted to the respective port may not be reaching the server. In this scenario a simultaneous network trace may help.



Sample RPCdump output