Source : https://www.anoopcnair.com/2014/10/01/domain-controller-firewall-ports-details-direction-communication-sccm-2012-r2-cas-primary-servers/
In terms of Firewall rules implementation, SCCM 2007 is very straight forward. However, SCCM 2012 is bit more confusing and it may require loads of coordination with security team :). Sometimes opening Firewall Rules may be really frustrating in SCCM ConfigMgr 2012. Technet documentation is excellent in providing the firewall port numbers and direction of communication. So what is direction of communication? Some ports need to be opened single direction and some need to be opened in bi-directional way. The direction of communication is very important from security perspective.
In this post I’m going to explain about the Firewall ports requirement between CAS server and DCs in Primary Server Domain (CHILD domain hereafter). I’ll also cover about the FW ports requirement between SCCM 2012 Primary server and DCs in SCCM CAS server domain (ROOT Domain hereafter). This details is not given in the technet article. More details via TechNet article here. Why is this not explained in the technet article ? In general, when you’ve two way trust between root and child domains (Primary server and CAS server) then these ports must be already opened. In some cases, the two way trust is only between the DCs of child and root domains. Hence the required ports are not opened between the clients in root domains and DCs in clients child domain.
Computers in child domain should have access to the ROOT DCs, and computers in Root domain should have access to child DC. This is required because I understand that computers in the domain need to access resources in the Trusting domain, be it child to root OR root to child. While allowing network communication from computer to Trusting domain DC, on the ports above (or below), we may choose to allow just one computer that needs to access resources across domain.. More details about this in the network trace examples below.
To SCCM 2012 to work correctly (or to get installed), We need to open the Firewall ports between SCCM 2012 CAS server in root domain and child DCs. Also these well known ports should opened between SCCM 2012 primary server in child domain and domain controllers in root domain. I’ve explained this issue in one of my previous post “ConfigMgr Primary Installation Error Attempted to perform unauthorized“. So why is this post again, I’ve not mentioned the direction of the ports and that is very important information from security perspective. Client initiates a connection via which port number and DCs send reply with which port etc.. I was searching for this information in the internet for days and remained unlucky.
Above diagram gives us a fair bit of idea about Firewall ports along with the direction of communication between SCCM 2012 primary server located at child domain and root DCs. Another part of this diagram is that Firewall ports along with the direction of communication between SCCM 2012 CAS server located at root domain and child DCs. To avoid complications in diagram, I’ve not covered the the port details of local DC communication details with it’s own clients.
So conclusion is only one port required to opened in bi directional way and that is RPC dynamic ports!!! Rest all Firewall ports mentioned above should be opened in unidirectional way as mentioned the above diagram.
More details about this can be fetched from the below network trace examples :-
Network trace example 3 way successful RPC EPM handshake
Tcp: Flags=......S., SrcPort=52702, DstPort=DCE endpoint resolution(135), PayloadLen=0, Seq=722369472, Ack=0, Win=8192 ( Negotiating scale factor 0x8 ) = 8192 {TCP:36, IPv4:7}
Tcp: Flags=...A..S., SrcPort=DCE endpoint resolution(135), DstPort=52702, PayloadLen=0, Seq=1169857372, Ack=722369473, Win=8192 ( Negotiated scale factor 0x8 ) = 2097152 {TCP:36, IPv4:7}
Tcp: Flags=...A...., SrcPort=52702, DstPort=DCE endpoint resolution(135), PayloadLen=0, Seq=722369473, Ack=1169857373, Win=512 (scale factor 0x8) = 131072 {TCP:36, IPv4:7}
Network Trace example for Successful RPC Bind
After the 3 way handshake it initiates an RPC Bind to the Endpoint Mapper. Successful RPC bind !
MSRPC MSRPC:c/o Bind: IObjectExporter(DCOM) UUID{99FCFEC4-5260-101B-BBCB-00AA0021347A} Call=0x2 Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0 {MSRPC:37, TCP:36, IPv4:7}
MSRPC MSRPC:c/o Bind Ack: IObjectExporter(DCOM) UUID{99FCFEC4-5260-101B-BBCB-00AA0021347A} Call=0x2 Assoc Grp=0x1E0D9 Xmit=0x16D0 Recv=0x16D0 {MSRPC:37, TCP:36, IPv4:7}
Microsoft clients connect to RPC Endpoint Mapper on port 135. Then the Endpoint Mapper tells the client which port a requested service is listening on. The port numbers are assigned dynamically and can be anywhere between 1024 and 65,535.
When a service starts up, it registers with the RPC service and requests the assignment of one or more dynamic port numbers. When the remote client needs to communicate with that service, it does not know which port numbers have been assigned.
To find out, the client connects to the server on TCP port 135 (the “well-known” port number for the RPC Endpoint Mapper service), and identifies the service to which it wants to connect. The RPC Endpoint Mapper service replies with the port number that the client should use to connect to the desired service. The client then reconnects to the server using the assigned port number, and communication with the desired service begins.
RPC End Point Mapper Handshake Failure (failed) Network trace :
The entry in the below net amount analysis means [SynReTransmit #101] resending the request for RPC EPM handshake but NO acknowledgement (response) from the server as we can see in the above successful trace (Flags=…A..S. and Flags=…A….) This could be because Firewall issue. You may need to open the FirePorts between client and server.
While opening Firewall ports, there is no need to worry from Source Ports mentioned in the network trace. Source ports are dynamic. You just need provide Source IP andDestination IP along with destination ports.
TCP TCP:Flags=......S., SrcPort=52702, DstPort=DCE endpoint resolution(135), PayloadLen=0, Seq=2557920356, Ack=0, Win=8192 ( Negotiating scale factor 0x8 ) = 8192 {TCP:14, IPv4:13}
TCP TCP:[SynReTransmit #101]Flags=......S., SrcPort=52702, DstPort=DCE endpoint resolution(135), PayloadLen=0, Seq=2557920356, Ack=0, Win=8192 ( Negotiating scale factor 0x8 ) = 8192 {TCP:14, IPv4:13}
TCP TCP:[SynReTransmit #101]Flags=......S., SrcPort=52702, DstPort=DCE endpoint resolution(135), PayloadLen=0, Seq=2557920356, Ack=0, Win=8192 ( Negotiating scale factor 0x8 ) = 8192 {TCP:14, IPv4:13}
Network Trace example for Failed Client server communication network trace on LDAP Port 389
The entry in the below net amount analysis means Flags=…A.R.. seems to me as TCP reset or Reject (I can’t confirm this )
TCP:Flags=……S., SrcPort=52705, DstPort=LDAP(389), PayloadLen=0, Seq=914145090, Ack=0, Win=8192 ( Negotiating scale factor 0x8 ) = 8192 {TCP:22, IPv4:13} TCP:Flags=…A.R.., SrcPort=LDAP(389), DstPort=52705, PayloadLen=0, Seq=251831252, Ack=914145091, Win=8192 {TCP:22, IPv4:13}
Network Trace example for Failed Microsoft Global Catalog LDAP 3268 connection
The entry in the below net amount analysis means [SynReTransmit #101] resending the request for Global Catalog LDAP 3268 but NO acknowledgement (response) from the server as we can see in the above trace (Flags=…A..S. and Flags=…A….) This could be because Firewall issue. You may need to open the FirePorts between client and server.
TCP:Flags=......S., SrcPort=52707, DstPort=Microsoft Global Catalog (LDAP)(3268), PayloadLen=0, Seq=54051677, Ack=0, Win=8192 ( Negotiating scale factor 0x8 ) = 8192 {TCP:43, IPv4:13}
TCP:[SynReTransmit #1238]Flags=......S., SrcPort=52707, DstPort=Microsoft Global Catalog (LDAP)(3268), PayloadLen=0, Seq=54051677, Ack=0, Win=8192 ( Negotiating scale factor 0x8 ) = 8192 {TCP:43, IPv4:13}
TCP:[SynReTransmit #1238]Flags=......S., SrcPort=52707, DstPort=Microsoft Global Catalog (LDAP)(3268), PayloadLen=0, Seq=54051677, Ack=0, Win=8192 ( Negotiating scale factor 0x8 ) = 8192 {TCP:43, IPv4:13}
Network Trace example for Failed Microsoft DNS port 53
The entry in the below net amount analysis means [SynReTransmit #101] resending the request for DNS connection on port 53 but NO acknowledgement (response) from the server as we can see in the above trace (Flags=…A..S. and Flags=…A….) This could be because Firewall issue. You may need to open the FirePorts between client and server.
TCP:Flags=......S., SrcPort=52714, DstPort=DNS(53), PayloadLen=0, Seq=2780093052, Ack=0, Win=8192 ( Negotiating scale factor 0x8 ) = 8192 {TCP:54, IPv4:13}
TCP:[SynReTransmit #2312]Flags=......S., SrcPort=52714, DstPort=DNS(53), PayloadLen=0, Seq=2780093052, Ack=0, Win=8192 ( Negotiating scale factor 0x8 ) = 8192 {TCP:54, IPv4:13}
Network Trace example for Failed Kerberos port 88 connection
The entry in the below net amount analysis means [SynReTransmit #101] resending the request for Kerberos port 88 but NO acknowledgement (response) from the server as we can see in the above trace (Flags=…A..S. and Flags=…A….) This could be because Firewall issue. You may need to open the FirePorts between client and server.
TCP:Flags=......S., SrcPort=52716, DstPort=Kerberos(88), PayloadLen=0, Seq=1708886965, Ack=0, Win=8192 ( Negotiating scale factor 0x8 ) = 8192 {TCP:65, IPv4:13}
TCP:[SynReTransmit #2874]Flags=......S., SrcPort=52716, DstPort=Kerberos(88), PayloadLen=0, Seq=1708886965, Ack=0, Win=8192 ( Negotiating scale factor 0x8 ) = 8192 {TCP:65, IPv4:13}
KerberosV5 KerberosV5: {UDP:69, IPv4:13}
No comments:
Post a Comment