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 frustrating in SCCM ConfigMgr.

SCCM Firewall Ports Details Direction with DC Other Servers

Technet documentation provides 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 will 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 detail is not given in the TechNet article. More information via the TechNet article is 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), 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?

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.

Adaptiva

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

For SCCM 2012 to work correctly (or to get installed), We need to open the Firewall ports between SCCM 2012 CAS server in the 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 my previous posts, “ConfigMgr Primary Installation Error Attempted to perform unauthorized“.

So why is this post again? I’ve not mentioned the ports’ direction, which is very important information from a security perspective. The client initiates a connection via which port number and DCs reply with which port etc. I searched for this information on the internet for days and remained unlucky.

The above diagram gives us a fair bit of idea about Firewall ports and 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 and 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 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 the conclusion is that only one port is required to open bi-directional, and that is RPC dynamic ports!!! Rest all  Firewall ports mentioned above should be opened in a unidirectional way as mentioned in 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 ports 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 acknowledgment (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 about Source Ports mentioned in the network trace. Source ports are dynamic. You need to 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 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 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://www.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)

Author

Anoop is Microsoft MVP! He is a Solution Architect in enterprise client management with more than 20 years of experience (calculation done in 2021) in IT. He is a blogger, Speaker, and Local User Group HTMD Community leader. His main focus is on Device Management technologies like SCCM 2012, Current Branch, and Intune. E writes about ConfigMgr, Windows 11, Windows 10, Azure AD, Microsoft Intune, Windows 365, AVD, etc…

1 thought on “SCCM Firewall Ports Details Direction with DC Other Servers | Configuration Manager | Bi-direction”

  1. Thank You! for creating a detailed troubleshooting guide with SCCM traffic associated problems. The most critical piece of information is the port number and the direction of traffic from from client to DC, from DC to other servers such as Distribution Point and Management Point Servers. The MOST IMPORTANT initial traffic from the endpoint is the RPC EPM Handshake. NOTE: I am in a troubleshooting session for the last more than two weeks after Active Directory was changed out and Port Opening Requests were NOT completed.

    Reply

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.