SCCM Firewall Ports Details Direction with DC Other Servers | Configuration Manager | Bi-direction. SCCM 2007 is very straightforward in terms of firewall rule implementation.
However, SCCM 2012 is a bit more confusing, and it may require extensive coordination with the security team. 🙂 Sometimes, opening Firewall Rules in SCCM ConfigMgr can be frustrating.
Technet documentation provides the firewall port numbers and direction of communication. So, what is the direction of communication? Some ports need to be opened in a single direction, and some need to be opened in a bidirectional way. The direction of communication is significant from a security perspective.
In this post, I will explain the Firewall port requirement between the CAS server and DCs in the Primary Server Domain (CHILD domain hereafter). I’ll also cover the FW ports requirement between the SCCM 2012 Primary server and DCs in the SCCM CAS server domain (ROOT Domain hereafter). SCCM Firewall Ports Details?
- SCCM Firewall Ports Download the List of ConfigMgr Firewall Ports
- SCCM ConfigMgr How to Setup Co-Management – Firewall Ports Proxy Requirements
SCCM Firewall Ports Details Direction with DC Other Servers
This detail is not given in the TechNet article. More information can be found in the TechNet article here. Why is this not explained in the TechNet article? Generally, these ports must be opened when you’ve two-way trust between root and child domains (Primary server and CAS server). Sometimes, the two-way trust is only between the DCs of the child and root domains.
Hence, the required ports are not opened between clients in root domains and DCs in the client’s child domain. What are the 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 must access resources in the Trusting domain, be it child to root OR root to the child. While allowing network communication from the computer to the Trusting domain DC on the ports above (or below), we may allow just one computer that needs to access resources across the domain.
More details about this area in the network trace examples are below. SCCM Firewall Ports Details?
For SCCM 2012 to work correctly (or to be installed), we need to open the Firewall ports between the SCCM 2012 CAS server in the root domain and child DCs.
Also, these well-known ports should be opened between the 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 essential 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 was unlucky.
The above diagram gives us a fair idea about Firewall ports and the direction of communication between the SCCM 2012 primary server located at the 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)
Network Trace Example 3-Way Successful RPC EPM Handshake
So the conclusion is that only one port is required to open bi-directional, and that is RPC dynamic ports!!! All the rest of the 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:-
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, an RPC Bind is initiated at 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 the 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 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 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 of a Firewall issue. You may need to open the FirePorts between the client and server.
When 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 the Source IP and Destination IP along with the 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 of a Firewall issue. You may need to open the FirePorts between the 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 acknowledgement (response) from the server, as we can see in the above trace (Flags=…A..S. and Flags=…A….). This could be because of a Firewall issue. You may need to open the reports between the client and the 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 acknowledgement (response) from the server, as we can see in the above trace (Flags=…A..S. and Flags=…A….). This could be because of a Firewall issue. You may need to open the client and server firewall ports. 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)
We are on WhatsApp now. To get the latest step-by-step guides, news, and updates, Join our Channel. Click here. HTMD WhatsApp.
Author
Anoop C Nair is Microsoft MVP from 2015 onwards for consecutive 10 years! He is a Workplace Solution Architect with more than 22+ years of experience in Workplace technologies. He is a Blogger, Speaker, and Local User Group Community leader. His main focus is on Device Management technologies like SCCM and Intune. He writes about technologies like Intune, SCCM, Windows, Cloud PC, Windows, Entra, Microsoft Security, Career etc…
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.