Rob3r70 SharePoint Blog

When securing a SharePoint Server farm (2016, 2019, or Subscription Edition), the best starting point is always Microsoft’s official security hardening documentation. The primary resource — “Plan security hardening for SharePoint Server” — provides clear recommendations for reducing the attack surface while keeping the farm functional.

Key Hardening Steps We Followed from Microsoft Documentation

We strictly followed Microsoft’s guidance, including:

• Least-privilege configuration for service accounts and application pools.
• SQL Server hardening: Blocking default SQL ports (TCP 1433 and UDP 1434) where possible and using SQL Server client aliases for farm communication. This is one of Microsoft’s primary recommendations to prevent direct database exposure between farms or from external networks.
• Restricting unnecessary services and features.
• Enabling Windows Firewall rules only for required traffic.
• Keeping the environment fully patched and rotating ASP.NET machine keys (especially important after recent vulnerabilities).

Microsoft emphasizes securing inter-server communication within the farm. The documentation lists specific ports for service applications and Windows Communication Foundation (WCF):

• TCP 32843 (HTTP binding – default for service apps)
• TCP 32844 (HTTPS binding)
• TCP 32845 (net.tcp – only if used by third-party service apps)
• TCP 808 (WCF)

It also stresses proper firewall configuration between SharePoint servers, the database tier, and other components.

The Unexpected Discovery: Ports 135 and 445 Are Required Between SharePoint Servers

While implementing strict firewall rules based on the official docs, we encountered intermittent issues with farm functionality — timer jobs failing, service applications not responding reliably, search crawling problems, and occasional Distributed Cache or profile synchronization hiccups.

After careful troubleshooting and packet analysis, we found that TCP ports 135 (RPC Endpoint Mapper) and 445 (SMB) needed to be opened between all SharePoint servers in the farm for normal operation.

These ports are not always prominently highlighted in the SharePoint-specific hardening article for intra-farm traffic, but they are essential for several underlying Windows components that SharePoint relies on:

• Port 135 (RPC): Used by DCOM, WMI, and various remote procedure calls for management, configuration synchronization, and inter-server coordination.
• Port 445 (SMB): Required for file sharing operations, named pipes (even when SQL uses aliases), administrative shares during certain operations, and core Windows services like Netlogon.

This aligns with broader Microsoft documentation on Windows network port requirements and real-world SharePoint deployments. Many administrators discover this only during hardening or when applying aggressive firewall policies.

Important note: These ports should still be tightly restricted — allow them only between SharePoint servers in the same farm (and to the SQL server where necessary), never to the general internal network or internet. Use IP-based firewall rules or network segmentation for maximum security.

Lessons Learned and Recommendations

1. Start with Microsoft’s official hardening guide and cross-reference the general “Service overview and network port requirements for Windows”.
2. Test thoroughly in a staging environment after applying firewall restrictions. Many “hidden” dependencies surface only under load.
3. Document your exact allowed ports and rules — this helps during audits and future troubleshooting.
4. Combine network hardening with other layers: regular patching, AMSI integration, least-privilege accounts, and monitoring for anomalous activity.

By following Microsoft’s documentation while validating real-world behavior, we achieved a significantly hardened SharePoint farm without breaking core functionality. The key takeaway? Official port lists are an excellent foundation, but always validate intra-farm communication empirically — especially for RPC (135) and SMB (445).

Here is the PowerShell script I use to set firewall exceptions:

$remoteAddresses="10.10.10.93","10.10.10.94"
New-NetFirewallRule -DisplayName "SharePoint Inbound" -Direction Inbound -Protocol TCP -Enabled True -Action Allow -LocalPort "135","445","16500-16519","22233-22236","808","32843-32846","49152-65535","1025-5000" -RemoteAddress $remoteAddresses

If you’re planning a similar hardening project, budget time for testing these two ports. They’re often the difference between a “secure but broken” farm and a secure, reliable one.