1 of 14 14/11/2011 2:45 PM Applies to: Exchange Server 2010 SP1 Topic Last Modified: 2011-04-22 This topic provides information about ports, authentication, and for all data paths used by Microsoft Exchange Server 2010. The Notes sections following each table clarify or define non-standard authentication or methods. Exchange 2010 includes two server roles that perform message transport functionality: server and Edge server. The following table provides information about ports, authentication, and for data paths between these transport servers and other Exchange 2010 servers and services. server data paths Data path Required ports Encrypted Default Supported Encryption by authentication authentication supported? default? server to server 25/TCP (SMTP) Layer Security (TLS) server to Edge server 25/TCP (SMTP) Direct trust Direct trust TLS Edge server to server 25/TCP (SMTP) Direct trust Direct trust TLS Edge server to Edge server 25/TCP SMTP Anonymous, Certificate Anonymous, Certificate TLS server to server via the Microsoft Exchange Mail Submission Service 135/TCP () NTLM. If the and the server roles are NTLM/ on the same server, is used. to server via MAPI 135/TCP () NTLM. If the NTLM/ and the server roles are
xchange Network Port Reference: Exchange 2010 SP1 Help 2 of 14 14/11/2011 2:45 PM on the same server, is used. server to server 25/TCP (SMTP) TLS Microsoft Exchange EdgeSync service from server to Edge server 50636/TCP () Basic Basic LDAP over (LDAPS) Active Directory access from server 389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (), 53/TCP/UDP (DNS), 135/TCP ( netlogon) Active Directory Rights Management 443/TCP (HTTPS) Services (AD RMS) access from server NTLM/ NTLM/ * SMTP clients to server (for 587 (SMTP) example, 25/TCP (SMTP) end-users using Windows Live Mail) NTLM/ NTLM/ TLS All traffic between servers is encrypted by using TLS with self-signed certificates that are installed by Exchange 2010 Setup. Note: In Exchange 2010, TLS can be disabled on servers for internal SMTP communication with other servers in the same Exchange organization. We don't recommend doing this unless absolutely required. For more information, see Disabling TLS Between Active Directory Sites to Support WAN Optimization 1. All traffic between Edge servers and servers is authenticated and encrypted. Mutual TLS is the underlying mechanism for authentication and. Instead of using X.509 validation, Exchange 2010 uses direct trust to authenticate the certificates. Direct trust means that the presence of the certificate in Active Directory or Active Directory Lightweight Directory Services (AD LDS) acts as validation for the certificate. Active Directory is considered a trusted storage mechanism. When direct trust is used, it doesn't matter if the certificate is self-signed or signed by a certification authority (CA). When you subscribe an Edge server to the Exchange organization, the Edge
xchange Network Port Reference: Exchange 2010 SP1 Help 3 of 14 14/11/2011 2:45 PM Subscription publishes the Edge server certificate in Active Directory for the servers to validate. The Microsoft Exchange EdgeSync service updates AD LDS with the set of server certificates for the Edge server to validate. EdgeSync uses a secure LDAP connection from the server to subscribed Edge servers over TCP 50636. AD LDS also listens on TCP 50389. Connections to this port don't use. You can use LDAP utilities to connect to the port and check AD LDS data. By default, traffic between Edge servers in two different organizations is encrypted. Exchange 2010 Setup creates a self-signed certificate, and TLS is enabled by default. This allows any sending system to encrypt the inbound SMTP session to Exchange. By default, Exchange 2010 also tries TLS for all remote connections. Authentication methods for traffic between servers and servers differ when the server roles and server roles are installed on the same computer. When mail submission is local, authentication is used. When mail submission is remote, NTLM authentication is used. Exchange 2010 also supports Domain Security. Domain Security refers to the functionality in Exchange 2010 and Microsoft Outlook 2010 that provides a low-cost alternative to S/MIME or other message-level over-the-internet, security solutions. Domain Security provides you with a way to manage secure message paths between domains over the Internet. After these secure message paths are configured, messages that have successfully traveled over the secure path from an authenticated sender are displayed to Outlook and Outlook Web users as "Domain Secured". For more information, see Understanding Domain Security 2. Many agents can run on servers and Edge servers. Generally, anti-spam agents rely on information that's local to the computer on which the agents run. Therefore, little communication with remote computers is required. Recipient filtering is the exception. Recipient filtering requires calls to either AD LDS or Active Directory. As a best practice, run recipient filtering on the Edge server. In this case, the AD LDS directory is on the same computer as the Edge server and no remote communication is required. When recipient filtering has been installed and configured on the server, recipient filtering accesses Active Directory. The Protocol Analysis agent is used by the Sender Reputation feature in Exchange 2010. This agent also makes various connections to outside proxy servers to determine inbound message paths for suspect connections. All other anti-spam functionality uses data gathered, stored, and accessed only on the local computer. Frequently, the data, such as safelist aggregation or recipient data for recipient filtering, is pushed to the local AD LDS directory by using the Microsoft Exchange EdgeSync service. Information Rights Management (IRM) agents on servers make connections to Active Directory Rights Management Services (AD RMS) servers in the organization. AD RMS is a Web service that's secured by using as a best practice. Communication with AD RMS servers occurs by using HTTPS, and or NTLM is used for authentication, depending on the AD RMS server configuration. Journal rules, transport rules, and message classifications are stored in Active Directory and accessed by the Journaling agent and the Rules agent on servers. Whether NTLM or authentication is used for servers depends on the user or process context that the Exchange Business Logic layer consumer is running under. In this context, the consumer is any application or process that uses the Exchange Business Logic layer. As a result, many entries in the Default Authentication column of the server data paths table are listed as NTLM/. The Exchange Business Logic layer is used to access and communicate with the Exchange store. The Exchange Business Logic layer is also called from the Exchange store to communicate with external applications and processes. If the Exchange Business Logic layer consumer is running as Local System, the authentication method is always from the consumer to the Exchange store. is used because the consumer must be authenticated by using the Local System computer account, and a two-way authenticated trust must exist.
xchange Network Port Reference: Exchange 2010 SP1 Help 4 of 14 14/11/2011 2:45 PM If the Exchange Business Logic layer consumer isn't running as Local System, the authentication method is NTLM. For example, NTLM is used when you run an Exchange Management Shell cmdlet that uses the Exchange Business Logic layer. The traffic is always encrypted. The following table provides information about ports, authentication, and for data paths to and from servers. server data paths Data path Required ports Default Supported Encryption authentication authentication supported? Encrypted by default? Active Directory access 389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (), 53/TCP/UDP (DNS), 135/TCP ( netlogon) Admin remote access (Remote Registry) 135/TCP () NTLM/ NTLM/ IPsec No Admin remote access (SMB/File) 445/TCP (SMB) NTLM/ NTLM/ IPsec No Availability Web service ( to ) 135/TCP () NTLM/ NTLM/ Clustering 135/TCP () See Notes on Servers after this table. NTLM/ NTLM/ IPsec No Content indexing 135/TCP () NTLM/ NTLM/ Log shipping 64327 (customizable) NTLM/ NTLM/ No Seeding 64327 (customizable) NTLM/ NTLM/ No Volume shadow copy service (VSS) backup Local Message Block (SMB) NTLM/ NTLM/ No No The Clustering data path listed in the preceding table uses dynamic over TCP to communicate cluster status and activity between the different cluster nodes. The Cluster service (ClusSvc.exe) also uses UDP/3343 and randomly allocated high TCP ports to
5 of 14 14/11/2011 2:45 PM communicate between cluster nodes. For intra-node communications, cluster nodes communicate over User Datagram Protocol (UDP) port 3343. Each node in the cluster periodically exchanges sequenced, unicast UDP datagrams with every other node in the cluster. The purpose of this exchange is to determine whether all nodes are running correctly and to monitor the health of network links. Port 64327/TCP is the default port used for log shipping. Administrators can specify a different port for log shipping. For HTTP authentication where Negotiate is listed, is tried first, and then NTLM. Unless noted, client access technologies, such as Outlook Web App, POP3, or IMAP4, are described by the authentication and from the client application to the server. The following table provides information about port, authentication, and for data paths between servers and other servers and clients. server data paths Data path Required ports Default authentication Encrypted Supported Encryption by authentication supported? default? Active Directory access 389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (), 53/TCP/UDP (DNS), 135/TCP ( netlogon) Autodiscover service 80/TCP, 443/TCP () Basic/Integrated Windows authentication (Negotiate) Basic, Digest, NTLM, Negotiate () HTTPS Availability service 80/TCP, 443/TCP () NTLM/ NTLM, HTTPS Outlook accessing OAB 80/TCP, 443/TCP () NTLM/ NTLM/ HTTPS No Outlook Web App 80/TCP, 443/TCP () Forms Based Authentication Basic, Digest, Forms Based Authentication, NTLM (v2 only),, Certificate HTTPS a self-signed certificate POP3 110/TCP (TLS), 995/TCP () Basic, Basic,, TLS IMAP4 143/TCP (TLS), 993/TCP () Basic, Basic,, TLS
6 of 14 14/11/2011 2:45 PM Outlook Anywhere (formerly known as over HTTP 80/TCP, 443/TCP () Basic Basic or NTLM ) HTTPS Exchange ActiveSync application 80/TCP, 443/TCP () Basic Basic, Certificate HTTPS server to server 5060/TCP, 5061/TCP, 5062/TCP, a dynamic port By IP address By IP address Session Initiation Protocol (SIP) over TLS server to a server that is running an earlier version of Exchange Server 80/TCP, 443/TCP () NTLM/ Negotiate ( with fallback to NTLM or optionally Basic,) POP/IMAP plain text IPsec No server to Exchange 2010 server. See Notes on Servers. NTLM/ server to server (Exchange ActiveSync) 80/TCP, 443/TCP (), Certificate HTTPS a self-signed certificate server to server (Outlook Web ) 80/TCP, 443/TCP (HTTPS) server to server (Exchange Web Services) 443/TCP (HTTPS) server to server (POP3) 995 () Basic Basic
xchange Network Port Reference: Exchange 2010 SP1 Help 7 of 14 14/11/2011 2:45 PM server to server (IMAP4) 993 () Basic Basic Office Communications Server access to server (when Office Communications Server and Outlook Web App integration is enabled) 5075-5077/TCP (IN), 5061/TCP (OUT) mtls (Required) mtls (Required) Note: Integrated Windows authentication (NTLM) isn't supported for POP3 or IMAP4 client connectivity. For more information, see the " Features" sections in Discontinued Features 3. In Exchange 2010, MAPI clients such as Microsoft Outlook connect to servers. The servers use many ports to communicate with servers. With some exceptions, those ports are determined by the service and aren't fixed. For HTTP authentication where Negotiate is listed, is tried first, and then NTLM. When an Exchange 2010 server communicates with a server running Exchange Server 2003, it's a best practice to use and disable NTLM authentication and Basic authentication. Additionally, it's a best practice to configure Outlook Web App to use forms-based authentication with a trusted certificate. For Exchange ActiveSync clients to communicate through the Exchange 2010 server to the Exchange 2003 back-end server, Windows Integrated Authentication must be enabled on the Microsoft- Server-ActiveSync virtual directory on the Exchange 2003 back-end server. To use Exchange System Manager on an Exchange 2003 server to manage authentication on an Exchange 2003 virtual directory, download and install the hot fix referenced in Microsoft Knowledge Base article 937031, Event ID 1036 is logged on an Exchange 2007 server that is running the CAS role when mobile devices connect to the Exchange 2007 server to access mailboxes on an Exchange 2003 back-end server 4. Note: Although the Knowledge Base article is specific to Exchange 2007, it's also applicable to Exchange 2010. When a server proxies POP3 requests to another server, the communication occurs over port 995/TCP, regardless of whether the connecting client uses POP3 and requests TLS (on port 110/TCP) or connects on port 995/TCP using. Similarly, for IMAP4 connections, port 993/TCP is used to proxy requests regardless of whether the connecting client uses IMAP4 and requests TLS (on port 443/TCP) or connects on port 995 using IMAP4 with IP gateways and IP PBXs support only certificate-based authentication that uses mutual TLS for encrypting SIP traffic and IP-based authentication for Session Initiation Protocol (SIP)/TCP connections. IP gateways don't support either NTLM or authentication. Therefore, when
xchange Network Port Reference: Exchange 2010 SP1 Help 8 of 14 14/11/2011 2:45 PM you use IP-based authentication, the connecting IP address or addresses are used to provide authentication mechanism for unencrypted (TCP) connections. When IP-based authentication is used in (UM), the UM server verifies that the IP address is allowed to connect. The IP address is configured on the IP gateway or IP PBX. IP gateways and IP PBXs support mutual TLS for encrypting SIP traffic. After you successfully import and export the required trusted certificates, the IP gateway or IP PBX will request a certificate from the UM server, and then it will request a certificate from the IP gateway or IP PBX. Exchanging the trusted certificate between the IP gateway or IP PBX and the UM server enables the IP gateway or IP PBX and UM server to communicate over an encrypted connection by using mutual TLS. The following table provides information about port, authentication, and for data paths between UM servers and other servers. server data paths Data path Required ports Default authentication Supported authentication Encrypted Encryption by supported? default? Active Directory access 389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (), 53/TCP/UDP (DNS), 135/TCP ( netlogon) Phone interaction (IP PBX/VoIP Gateway) 5060/TCP, 5065/TCP, 5067/TCP (unsecured), 5061/TCP, 5066/TCP, 5068/TCP (secured), a dynamic port from the range 16000-17000/TCP (control), dynamic UDP ports from the range 1024-65535/UDP (RTP) By IP address By IP address, MTLS SIP/TLS, SRTP No Web Service 80/TCP, 443/TCP () Integrated Windows authentication (Negotiate) Basic, Digest, NTLM, Negotiate () server to server 5075, 5076, 5077 (TCP) Integrated Windows authentication (Negotiate) Basic, Digest, NTLM, Negotiate () server to server (Play on Phone) NTLM/ NTLM/
9 of 14 14/11/2011 2:45 PM server to server 25/TCP (TLS) TLS server to server 135/TCP () NTLM/ NTLM/ When you create a UM IP gateway object in Active Directory, you must define the IP address of the physical IP gateway or IP PBX (Private Branch exchange). When you define the IP address on the UM IP gateway object, the IP address is added to a list of valid IP gateways or IP PBXs (also called SIP peers) that the UM server is allowed to communicate with. When you create the UM IP gateway, you can associate it with a UM dial plan. Associating the UM IP gateway with a dial plan allows the servers that are associated with the dial plan to use IP-based authentication to communicate with the IP gateway. If the UM IP gateway has not been created or it isn't configured to use the correct IP address, authentication fails and the UM servers don't accept connections from that IP gateway's IP address. Also, when you implement mutual TLS and IP gateway or IP PBX and UM servers, the UM IP gateway must be configured to use the FQDN. After you configure the UM IP gateway with an FQDN, you must also add a host record to the DNS forward lookup zone for the UM IP gateway. In Exchange 2010, a UM server can either communicate on port 5060/TCP (unsecured) or on port 5061/TCP (secured), and can be configured to use both. For more information, see Understanding VoIP Security 5 and Understanding Protocols, Ports, and Services in 6. Windows Firewall with Advanced Security is a stateful, host-based firewall that filters inbound and outbound traffic based on firewall rules. Exchange 2010 Setup creates Windows Firewall rules to open the ports required for server and client communication on each server role. Therefore, you no longer need to use the Security Configuration Wizard (SCW) to configure these settings. To learn more about Windows Firewall with Advanced Security, see Windows Firewall with Advanced Security and IPsec 7. This table lists the Windows Firewall rules created by Exchange Setup, including the ports opened on each server role. You can view these rules using the Windows Firewall with Advanced Security MMC snap-in. Rule name Server roles Port Program MSExchangeADTopology -,,, Bin\MSExchangeADTopologyService.exe
10 of 14 14/11/2011 2:45 PM MSExchangeMonitoring -,, Edge, Bin\Microsoft.Exchange.Management.Monitor MSExchangeServiceHost - All roles Bin\Microsoft.Exchange.ServiceHost.exe MSExchangeServiceHost - EPMap All roles -EPMap Bin\Microsoft.Exchange.Service.Host MSExchangeEPMap (GFW) All roles -EPMap Any MSExchange (GFW),,, Any MSExchange - IMAP4 (GFW) 143, 993 (TCP) All MSExchangeIMAP4 143, 993 (TCP) \PopImap \Microsoft.Exchange.Imap4Service.exe MSExchange - POP3 (FGW) 110, 995 (TCP) All MSExchange - POP3 110, 995 (TCP) \PopImap \Microsoft.Exchange.Pop3Service.exe MSExchange - OWA (GFW) 5075, 5076, All 5077 (TCP) MSExchangeOWAAppPool 5075, 5076, Inetsrv\w3wp.exe 5077 (TCP) MSExchangeAB- Bin\Microsoft.Exchange.AddressBook.Service.
11 of 14 14/11/2011 2:45 PM MSExchangeAB-EPMap -EPMap Bin\Microsoft.Exchange.AddressBook.Service. MSExchangeAB-RpcHttp 6002, 6004 (TCP) Bin\Microsoft.Exchange.AddressBook.Service. RpcHttpLBS System32\Svchost.exe MSExchange -, Bing\Microsoft.Exchange.Rpc.Ser MSExchange - PRCEPMap, -EPMap Bing\Microsoft.Exchange.Rpc.Ser MSExchange, 6001 (TCP) Bing\Microsoft.Exchange.Rpc.Ser MSExchangeReplication (GFW) 808 (TCP) Any MSExchangeReplication 808 (TCP) Bin\MSExchangeReplication.exe MSExchangeIS - Bin\Store.exe MSExchangeIS EPMap -EPMap Bin\Store.exe MSExchangeIS (GFW) 6001, 6002, Any 6003, 6004 (TCP) MSExchangeIS 6001 (TCP) Bin\Store.exe MSExchangeAssistants - Bin\MSExchangeAssistants.exe MSExchangeAssistants - EPMap -EPMap Bin\MSExchangeAssistants.exe MSExchangeMailSubmission - Bin\MSExchangeMailSubmission.exe
12 of 14 14/11/2011 2:45 PM MSExchangeMailSubmission - EPMap -EPMap Bin\MSExchangeMailSubmission.exe MSExchangeMigration - Bin\MSExchangeMigration.exe MSExchangeMigration - EPMap -EPMap Bin\MSExchangeMigration.exe MSExchangerepl - Log Copier 64327 (TCP) Bin\MSExchangeRepl.exe MSExchangerepl - Bin\MSExchangeRepl.exe MSExchangerepl - -EPMap -EPMap Bin\MSExchangeRepl.exe MSExchangeSearch - Bin\Microsoft.Exchange.Search.ExSearch.exe MSExchangeThrottling - Bin\MSExchangeThrottling.exe MSExchangeThrottling - EPMap -EPMap Bin\MSExchangeThrottling.exe MSFTED - Bin\MSFTED.exe MSFTED - EPMap -EPMap Bin\MSFTED.exe MSExchangeEdgeSync - Bin\Microsoft.Exchange.EdgeSyncSvc.exe MSExchangeEdgeSync - EPMap -EPMap Bin\Microsoft.Exchange.EdgeSyncSvc.exe MSExchangeWorker - Bin\edgetransport.exe MSExchangeWorker - EPMap -EPMap Bin\edgetransport.exe MSExchangeWorker (GFW) 25, 587 (TCP) Any
13 of 14 14/11/2011 2:45 PM MSExchangeWorker 25, 587 (TCP) Bin\edgetransport.exe MSExchangeLogSearch -, Edge, Bin\MSExchangeLogSearch.exe MSExchangeLogSearch - EPMap, Edge -EPMap Bin\MSExchangeLogSearch.exe, SESWorker (GFW) Any Any SESWorker Any \SESWorker.exe UMService (GFW) 5060, 5061 Any UMService 5060, 5061 Bin\UMService.exe UMWorkerProcess (GFW) 5065, 5066, 5067, 5068 Any UMWorkerProcess 5065, 5066, 5067, 5068 Bin\UMWorkerProcess.exe UMWorkerProcess - Bin\UMWorkerProcess.exe On servers that have Internet Information Services (IIS) installed, Windows opens the HTTP (port 80, TCP) and HTTPS (port 443, TCP) ports. Exchange 2010 Setup doesn't open these ports. Therefore, these ports don't appear in the preceding table. On Windows Server 2008 and Windows Server 2008 R2, Windows Firewall with Advanced Security allows you to specify the process or service for which a port is opened. This is more secure because it restricts usage of the port to the process or service specified in the rule. Exchange Setup creates firewall rules with the process name specified. In some cases, an additional rule that isn't restricted to the process is also created for compatibility purposes. You can disable or remove the rules that aren't restricted to the processes and keep the corresponding rules restricted to processes if your deployment supports them. The rules not
14 of 14 14/11/2011 2:45 PM restricted to processes are distinguished by the word (GFW) in the rule name. A number of Exchange services use remote procedure calls (s) for communication. Server processes that use s contact the Endpoint Mapper to receive dynamic endpoints and register those endpoints in the Endpoint Mapper database. clients contact the Endpoint Mapper to determine the endpoints used by the server process. By default, the Endpoint Mapper listens on port 135 (TCP). When configuring the Windows Firewall for a process that uses s, Exchange 2010 Setup creates two firewall rules for the process. One rule allows communication with the Endpoint Mapper, and the other rule allows communication with the dynamically assigned endpoint. To learn more about s, see How Works 8. For more information about creating Windows Firewall rules for dynamic, see Allowing Inbound Network Traffic that Uses 9. Note: You can't modify the Windows Firewall rules created by Exchange 2010 Setup. You can create custom rules based on them, and then disable or delete them. For more information, see Microsoft Knowledge Base article 179442, How to configure a firewall for domains and trusts 10. Links Table 1 http://technet.microsoft.com/en-us/library/ee633456.aspx 2 http://technet.microsoft.com/en-us/library/bb124392.aspx 3 http://technet.microsoft.com/en-us/library/aa998911.aspx 4 http://go.microsoft.com/fwlink/?linkid=3052&kbid=937031 5 http://technet.microsoft.com/en-us/library/bb124092.aspx 6 http://technet.microsoft.com/en-us/library/aa998265.aspx 7 http://go.microsoft.com/fwlink/?linkid=179177 8 http://go.microsoft.com/fwlink/?linkid=69495 9 http://go.microsoft.com/fwlink/?linkid=168278 10 http://go.microsoft.com/fwlink/?linkid=3052&kbid=179442 Community Content Network Ports Diagram Some time ago I've created a network diagram; the diagram is available in PDF and Visio format. http://eightwone.com/2011/04/05/exchange-2010-sp1-network-ports-diagram-v03/ 11/1/2011 Michel de Rooij 2011 Microsoft. All rights reserved.