I have account DomainA and resource DomainR in a one way external trust:
DomainR > DomainA
There is a firewall in place between the two domains restricting all traffic by default.
I have allowed through all the necessary ports (445,389,3268,88,etc) but am having some issues with the info in the KB article.
Restricting Active Directory replication traffic and client RPC traffic to a specific port:
http://support.microsoft.com/kb/224196
My goal is to allow the DomainA accounts login access to DomainB resources. However, this fails even after setting the static ports defined in the KB above. I have set the following on all DCs (and restarted Netlogon):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DCTcpipPort = 50000
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\TCP/IP Port = 50001
I have also set the NTFRS port as referenced in the linked article from the KB (as there was some text that made me infer it might also be necessary):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTFRS\Parameters\RPC TCP/IP Port Assignment = 50002
These statically defined ports are all opened through the firewall. However logins across the one-way trust fail. Here is what I am finding in my netcaps:
In a login with no firewall in place, the DC of DomainR will contact the EPM on port 135 of DomainA and then proceed with a TCP connection over 49158 to perform a DCERPC BIND followed by (one or more) LSARPC lookupSids3 request. Once the LSARPC
responses are received the user is logged in.
However, with a firewall, the dynamic port 49158 is blocked and the LSARPC connection will obviously fail.
After several attempts to connect, it seems DomainR then attempts a connection over the DCTcpipPort port designated for Netlogon (50000) to perform a DCERPC bind followed by RPC_NET calls for NetrServerReqChallenge ane NetrServerAuthenticate3 concluded
with a NetrLogonDummyRoutine1. All of these calls are responded to from DomainA since the static Netlogon port is open, however logins are still unsuccessful.
It would seem to me that the LSARPC traffic is not properly being routed over the statically defined port and when this fails the RCP_NET traffic is being used as a possbile fallback - but not enough to get the job done. Why is the LSARPC traffic not
being routed over the Netlogon static DCTcpipPort?
I realize that this can be solved by creating an encrypted channel between the DCs and allowing all traffic to be tunneled over that, but that is not what I am testing in this scenario. According to the MS docs I would have appeared to implement all
that is required. It would appear that LSARPC is not honoring the statically defined port assignment. Why is this? What else needs to be done to get this to work?
thanks