1

I have a workstation (PC1) that cannot communicate with a domain controller over RPC (TCP/135).

C:\PortQryV2> portqry.exe -n 192.168.1.1 -p tcp -o 135

Querying target system called:

 192.168.1.1

Attempting to resolve IP address to a name...

IP address resolved to dc.domain.local

querying...

TCP port 135 <epmap service>: FILTERED

Executing the same command on another workstation (PC2) in the same subnet and VLAN shows LISTENING along with all of the server's RPC endpoints.

C:\>netsh int ipv4 show dynamicport tcp

Protocol tcp Dynamic Port Range
---------------------------------
Start Port      : 49152
Number of Ports : 16384

The dynamic port range is the same on both PC1 and PC2.

Both PC1 and PC2 are running Windows 7 Enterprise SP1.

McAfee Host Intrusion Prevention (HIPS) software used to be installed on PC1 but was removed during the troubleshooting process. It remains installed on PC2. Both PC1 and PC2 used the same HIPS policy.

Windows firewall is currently disabled on PC1.

C:\>netsh advfirewall show allprofiles

Domain Profile Settings:
----------------------------------------------------------------------
State                                 OFF
Firewall Policy                       AllowInbound,AllowOutbound
LocalFirewallRules                    N/A (GPO-store only)
LocalConSecRules                      N/A (GPO-store only)
InboundUserNotification               Enable
RemoteManagement                      Disable
UnicastResponseToMulticast            Enable

Logging:
LogAllowedConnections                 Disable
LogDroppedConnections                 Disable
FileName                              %systemroot%\system32\LogFiles\Firewall\pfirewall.log
MaxFileSize                           4096


Private Profile Settings:
----------------------------------------------------------------------
State                                 OFF
Firewall Policy                       AllowInbound,AllowOutbound
LocalFirewallRules                    N/A (GPO-store only)
LocalConSecRules                      N/A (GPO-store only)
InboundUserNotification               Enable
RemoteManagement                      Disable
UnicastResponseToMulticast            Enable

Logging:
LogAllowedConnections                 Disable
LogDroppedConnections                 Disable
FileName                              %systemroot%\system32\LogFiles\Firewall\pfirewall.log
MaxFileSize                           4096


Public Profile Settings:
----------------------------------------------------------------------
State                                 OFF
Firewall Policy                       AllowInbound,AllowOutbound
LocalFirewallRules                    N/A (GPO-store only)
LocalConSecRules                      N/A (GPO-store only)
InboundUserNotification               Enable
RemoteManagement                      Disable
UnicastResponseToMulticast            Enable

Logging:
LogAllowedConnections                 Disable
LogDroppedConnections                 Disable
FileName                              %systemroot%\system32\LogFiles\Firewall\pfirewall.log
MaxFileSize                           4096

Ok.

I captured the RPC connection from portqry.exe using Wireshark and found that the TCP SYN DPU was sent, but no ACK ever received. The TCP SYN was sent twice more, displaying in Wireshark as [TCP Retransmission]. Later, I captured the same RPC communication on the domain controller using Wireshark. I saw the incoming TCP SYN but saw no SYN ACK reply. It's as though the domain controller is arbitrarily ignoring just this computer on just this port. Note that querying Kerberos (UDP/88) works just fine from PC1.

I also tried rebuilding the TCP/IP stack on PC1, to no avail.

Any ideas on what could be preventing this communication?

1 Answers1

1

After a lot of troubleshooting, I was able to determine that there was a Windows firewall rule enabled that would only allow connections from PC1 over TCP/135 and TCP/1027 if the connection is secure. In Windows Firewall with Advanced Security -> Inbound Rules, I went into the suspect rule properties. On the General tab, under Action, Allow the connection if it is secure was selected. On the Customize screen, Allow the connection if it is authenticated and integrity-protected was highlighted. The description for that item is as follows:

Allow only connections that are both authenticated and integrity-protected 
by using IPsec.  Compatible with Windows Vista and later.

enter image description here

Somehow this rule was established through a group policy on the domain. More than likely an administrator created this rule; however, it is possible that the software used on PC1 that requires this communication could have created the rule if it was installed using a domain admin account.