SCCM Firewall Ports Details Direction with DC Other Servers | Configuration Manager | Bi-direction

SCCM Firewall Ports Details Direction with DC Other Servers | Configuration Manager | Bi-direction. In terms of Firewall rules implementation, SCCM 2007 is very straightforward.

However, SCCM 2012 is a bit more confusing and it may require loads of coordination with the security team :). Sometimes opening Firewall Rules may be really frustrating in SCCM ConfigMgr.

SCCM Firewall Ports Details Direction with DC Other Servers

Technet documentation is excellent in providing the firewall port numbers and direction of communication. So what is the direction of communication? Some ports need to be opened single direction and some need to be opened in a bi-directional way. The direction of communication is very important from a security perspective.

SCCM Firewall Ports Details Direction with DC Other Servers | Configuration Manager | Bidirection
SCCM Firewall Ports Details Direction with DC Other Servers | Configuration Manager | Bi-direction

In this post, I’m going to explain the Firewall ports requirement between CAS server and DCs in Primary Server Domain (CHILD domain hereafter). I’ll also cover the FW ports requirement between SCCM 2012 Primary server and DCs in the SCCM CAS server domain (ROOT Domain hereafter). SCCM Firewall Ports Details?

Patch My PC

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 the client’s child domain. SCCM Firewall Ports Details?

1E Nomad

Computers in the child domain should have access to the ROOT DCs, and computers in the Root domain should have access to the 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 the 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 the domain.

More details about this in the network trace examples below. SCCM Firewall Ports Details?

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 be opened between SCCM 2012 primary server in the child domain and domain controllers in the root domain. I’ve explained this issue in one of my previous posts “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 a security perspective. The client initiates a connection via which port number and DCs send a reply with which port etc. I was searching for this information on the internet for days and remained unlucky.

The above diagram gives us a fair bit of idea about Firewall ports along with the direction of communication between the SCCM 2012 primary server located at child domain and root DCs. SCCM Firewall Ports Details.

Another part of this diagram is the Firewall ports along with the direction of communication between the SCCM 2012 CAS server located at the root domain and child DCs. To avoid complications in the diagram, I’ve not covered the port details of local DC communication details with its own clients.

  • TCP 445 (SMB)
  • TCP/UDP 88 ( Kerberos )
  • TCP/UDP 135 (RPC)
  • TCP/UDP Dynamic (RPC)
  • TCP/UDP 389 (LDAP)
  • TCP 3268 (Global Catalog LDAP)
  • TCP/UDP 53 (DNS Query)

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

Client Initiates a connection on Source port 52702 (RPC Dynamic port) to the server on destination port 135 (End Point Mapper). Server replies back using source port 135 and destination port 52702.

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 – SCCM Firewall Ports Details

After the 3 way handshake, it initiates an RPC Bind to the Endpoint Mapper. Successful RPC bind! SCCM Firewall Ports Details Direction with DC Other Servers | Configuration Manager | Bi-direction.

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 – SCCM Firewall Ports Details

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 and Destination 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 – SCCM Firewall Ports Details

The entry in the below net amount analysis means [SynReTransmit #101] resending the request for DNS connection on port 53 but NO acknowledgment (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 reports 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 SCCM Firewall Ports Details

The entry in the below net amount analysis means [SynReTransmit #101] resending the request for Kerberos port 88 but NO acknowledgment (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 firewall ports between client and server. SCCM Firewall Ports Details?

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}

Resources

See more available at: https://anoopcnair.com/2014/05/27/microsoft-rpc-remote-procedure-call-point-mapper-details-sccm-troubleshooting/

SCCM Related Posts Real World Experiences Of SCCM Admins (anoopcnair.com)