Professional Documents
Culture Documents
Page 1 of 17
Transport Servers
Exchange 2010 includes two server roles that perform message transport functionality: Hub Transport server and Edge Transport server. The following table provides information about ports, authentication, and encryption for data paths between these transport servers and other Exchange 2010 servers and services.
Data path
Required ports
25/TCP (SMTP)
Kerberos
Kerberos
Yes
Hub Transport server to Edge Transport server Edge Transport server to Hub Transport server Edge Transport server to Edge Transport server
25/TCP (SMTP)
Direct trust
Direct trust
Yes
25/TCP (SMTP)
Direct trust
Direct trust
Yes
25/TCP SMTP
Anonymous, Certificate
Anonymous, Certificate
Yes
Mailbox server to Hub Transport server via the 135/TCP (RPC) Microsoft Exchange Mail Submission Service
NTLM. If the Hub Transport and the Mailbox Yes, using server roles are NTLM/Kerberos RPC on the same encryption server, Kerberos is used.
Yes
http://technet.microsoft.com/en-us/library/bb331973(d=printer).aspx
1/5/2012
Page 2 of 17
NTLM. If the Hub Transport and the Mailbox Yes, using server roles are NTLM/Kerberos RPC on the same encryption server, Kerberos is used.
Yes
Unified Messaging server to Hub 25/TCP (SMTP) Transport server Microsoft Exchange EdgeSync service from Hub 50636/TCP (SSL) Transport server to Edge Transport server
Kerberos
Kerberos
Yes
Basic
Basic
Yes
389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), Kerberos 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)
Kerberos
Yes
Active Directory Rights Management 443/TCP (HTTPS) Services (AD RMS) access from Hub Transport server SMTP clients to Hub Transport 587 (SMTP) server (for example, end25/TCP (SMTP) users using Windows Live Mail)
NTLM/Kerberos NTLM/Kerberos
Yes*
NTLM/Kerberos NTLM/Kerberos
Yes
http://technet.microsoft.com/en-us/library/bb331973(d=printer).aspx
1/5/2012
Page 3 of 17
All traffic between Edge Transport servers and Hub Transport servers is authenticated and encrypted. Mutual TLS is the underlying mechanism for authentication and encryption. 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 Transport server to the Exchange organization, the Edge Subscription publishes the Edge Transport server certificate in Active Directory for the Hub Transport servers to validate. The Microsoft Exchange EdgeSync service updates AD LDS with the set of Hub Transport server certificates for the Edge Transport server to validate. EdgeSync uses a secure LDAP connection from the Hub Transport server to subscribed Edge Transport servers over TCP 50636. AD LDS also listens on TCP 50389. Connections to this port don't use SSL. You can use LDAP utilities to connect to the port and check AD LDS data. By default, traffic between Edge Transport 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 Hub Transport servers and Mailbox servers differ when the Hub Transport server roles and Mailbox server roles are installed on the same computer. When mail submission is local, Kerberos 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 Access users as "Domain Secured". For more information, see Understanding Domain Security2. Many agents can run on Hub Transport servers and Edge Transport servers. Generally, antispam 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 Transport server. In this case, the AD LDS directory is on the same computer as the Edge Transport server and no remote communication is required. When recipient filtering has been installed and configured on the Hub Transport 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 Hub Transport 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 SSL as a best practice. Communication with AD RMS servers occurs by using HTTPS, and Kerberos 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 Transport Rules agent on Hub Transport servers.
Mailbox Servers
Whether NTLM or Kerberos authentication is used for Mailbox 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
http://technet.microsoft.com/en-us/library/bb331973(d=printer).aspx
1/5/2012
Page 4 of 17
entries in the Default Authentication column of the Mailbox server data paths table are listed as NTLM/Kerberos. 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 Kerberos from the consumer to the Exchange store. Kerberos is used because the consumer must be authenticated by using the Local System computer account, and a two-way authenticated trust must exist. 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 RPC traffic is always encrypted. The following table provides information about ports, authentication, and encryption for data paths to and from Mailbox servers.
Data path
Required ports
389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)
Kerberos
Kerberos
Yes
Admin remote access (Remote Registry) Admin remote access (SMB/File) Availability Web service (Client Access to Mailbox)
135/TCP (RPC)
NTLM/Kerberos NTLM/Kerberos
No
445/TCP (SMB)
NTLM/Kerberos NTLM/Kerberos
No
135/TCP (RPC)
Yes
Clustering
NTLM/Kerberos NTLM/Kerberos
No
http://technet.microsoft.com/en-us/library/bb331973(d=printer).aspx
1/5/2012
Page 5 of 17
Content indexing
135/TCP (RPC)
Yes, using NTLM/Kerberos NTLM/Kerberos RPC encryption NTLM/Kerberos NTLM/Kerberos Yes NTLM/Kerberos NTLM/Kerberos Yes
Yes
No No
Volume shadow copy Local Message Block (SMB) NTLM/Kerberos NTLM/Kerberos No service (VSS) backup Mailbox Assistants
No
135/TCP (RPC)
NTLM/Kerberos NTLM/Kerberos No
No
MAPI access
135/TCP (RPC)
Yes
135/TCP (RPC)
Yes
Microsoft Exchange System Attendant 135/TCP (RPC) service legacy access (Listen to requests) Microsoft Exchange System Attendant service legacy access to Active Directory Microsoft Exchange System Attendant service
NTLM/Kerberos NTLM/Kerberos No
No
389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)
Kerberos
Kerberos
Yes
135/TCP (RPC)
Yes
http://technet.microsoft.com/en-us/library/bb331973(d=printer).aspx
1/5/2012
Page 6 of 17
legacy access (As MAPI client) Offline address book (OAB) 135/TCP (RPC) accessing Active Directory Recipient Update Service RPC access
Kerberos
Kerberos
Yes
135/TCP (RPC)
Kerberos
Kerberos
Yes
389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)
Kerberos
Kerberos
Yes
Data path
Required ports
Kerberos
Yes
http://technet.microsoft.com/en-us/library/bb331973(d=printer).aspx
1/5/2012
Page 7 of 17
53/TCP/UDP (DNS), 135/TCP (RPC netlogon) Basic/Integrated Basic, Digest, Windows NTLM, 80/TCP, 443/TCP (SSL) authentication Negotiate (Negotiate) (Kerberos)
Autodiscover service
Yes
Yes
Outlook accessing Yes, using 80/TCP, 443/TCP (SSL) NTLM/Kerberos NTLM/Kerberos OAB HTTPS Basic, Digest, Forms Based Authentication, Yes, using NTLM (v2 only), HTTPS Kerberos, Certificate Yes, using SSL, TLS Yes, using SSL, TLS
No
POP3
Yes
IMAP4
Yes
Outlook Anywhere (formerly known 80/TCP, 443/TCP (SSL) Basic as RPC over HTTP ) Exchange ActiveSync application
Basic or NTLM
Yes
Basic, Certificate
Yes
Client Access 5060/TCP, 5061/TCP, server to Unified 5062/TCP, a dynamic Messaging server port
By IP address
By IP address
Yes
Client Access Negotiate server to a (Kerberos with Mailbox server 80/TCP, 443/TCP (SSL) NTLM/Kerberos fallback to that is running an NTLM or earlier version of optionally Exchange Server Basic,)
No
http://technet.microsoft.com/en-us/library/bb331973(d=printer).aspx
1/5/2012
Page 8 of 17
POP/IMAP plain text Client Access server to Exchange 2010 Mailbox server Client Access server to Client Access server (Exchange ActiveSync) Client Access server to Client Access server (Outlook Web Access) Client Access server to Client Access server (Exchange Web Services) Client Access server to Client Access server (POP3) Client Access server to Client Access server (IMAP4)
Kerberos
Yes
Kerberos, Certificate
Kerberos
Kerberos
Yes
443/TCP (HTTPS)
Kerberos
Kerberos
Yes
995 (SSL)
Basic
Basic
Yes
993 (SSL)
Basic
Basic
Yes
Office Communications Server access to Client Access server (when 5075-5077/TCP (IN), Office 5061/TCP (OUT) Communications Server and Outlook Web App integration is enabled) Note:
mTLS (Required)
mTLS (Required)
Yes
Integrated Windows authentication (NTLM) isn't supported for POP3 or IMAP4 client connectivity. For more information, see the "Client Access Features" sections in Discontinued Features3.
http://technet.microsoft.com/en-us/library/bb331973(d=printer).aspx
1/5/2012
Page 9 of 17
Data path
Required ports
http://technet.microsoft.com/en-us/library/bb331973(d=printer).aspx
1/5/2012
Page 10 of 17
389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)
Kerberos
Kerberos
Yes
5060/TCP , 5065/TCP, 5067/TCP (unsecured), 5061/TCP, 5066/TCP, 5068/TCP (secured), a dynamic port from the range By IP address 16000-17000/TCP (control), dynamic UDP ports from the range 1024-65535/UDP (RTP) Integrated Windows authentication (Negotiate)
By IP address, MTLS
No
Unified Messaging Web Service Unified Messaging server to Client Access server
Yes
Yes
Unified Messaging server to Dynamic RPC Client Access server (Play on Phone) Unified Messaging server to Hub Transport server Unified Messaging server to Mailbox server
NTLM/Kerberos
NTLM/Kerberos
Yes
25/TCP (TLS)
Kerberos
Kerberos
Yes
135/TCP (RPC)
NTLM/Kerberos
NTLM/Kerberos
Yes
http://technet.microsoft.com/en-us/library/bb331973(d=printer).aspx
1/5/2012
Page 11 of 17
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 Unified Messaging 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 Unified Messaging VoIP Security and Understanding 6 Protocols, Ports, and Services in Unified Messaging .
5
Client Access, Hub Dynamic Transport, Bin\MSExchangeADTopologyService.exe RPC Mailbox, Unified Messaging Client Access, Hub Transport, Dynamic Bin\Microsoft.Exchange.Management.Monitoring.exe Edge RPC Transport, Unified Messaging Dynamic Bin\Microsoft.Exchange.ServiceHost.exe RPC
All roles
http://technet.microsoft.com/en-us/library/bb331973(d=printer).aspx
1/5/2012
Page 12 of 17
All roles
RPCEPMap RPCEPMap
Bin\Microsoft.Exchange.Service.Host
All roles
Any
Client Access, Hub Dynamic Transport, Any RPC Mailbox, Unified Messaging 143, 993 (TCP) 143, 993 (TCP) 110, 995 (TCP) 110, 995 (TCP) 5075, 5076, 5077 (TCP) 5075, 5076, 5077 (TCP)
Client Access
All
MSExchangeIMAP4 (TCP-In)
Client Access
ClientAccess\PopImap\Microsoft.Exchange.Imap4Service.exe
Client Access
All
Client Access
ClientAccess\PopImap\Microsoft.Exchange.Pop3Service.exe
All
Inetsrv\w3wp.exe
MSExchangeAB-RPC (TCP-In)
Client Access
Bin\Microsoft.Exchange.AddressBook.Service.exe
http://technet.microsoft.com/en-us/library/bb331973(d=printer).aspx
1/5/2012
Page 13 of 17
MSExchangeAB-RpcHttp (TCPIn)
Client Access
Bin\Microsoft.Exchange.AddressBook.Service.exe
RpcHttpLBS (TCP-In)
Client Access
Client MSExchangeRPC - RPC (TCP-In) Access, Mailbox Client Access, Mailbox Client Access, Mailbox Client Access Client Access
RPCEPMap
Bing\Microsoft.Exchange.RpcClientAccess.Service.exe
MSExchangeRPC (TCP-In)
6001 (TCP)
Bing\Microsoft.Exchange.RpcClientAccess.Service.exe
Any
Bin\MSExchangeMailboxReplication.exe
Mailbox
Dynamic Bin\Store.exe RPC RPCEPMap 6001, 6002, 6003, 6004 (TCP) 6001 (TCP)
Bin\Store.exe
Any
MSExchangeIS (TCP-In)
Mailbox
Bin\Store.exe
Bin\MSExchangeMailboxAssistants.exe
http://technet.microsoft.com/en-us/library/bb331973(d=printer).aspx
1/5/2012
Page 14 of 17
MSExchangeMailSubmission RPC (TCP-In) MSExchangeMailSubmission RPCEPMap (TCP-In) MSExchangeMigration - RPC (TCP-In) MSExchangeMigration RPCEPMap (TCP-In) MSExchangerepl - Log Copier (TCP-In)
Mailbox
Mailbox
Bin\MSExchangeMailSubmission.exe
Mailbox
Mailbox
Bin\MSExchangeMigration.exe
Mailbox
Bin\MSExchangeRepl.exe
Mailbox
Bin\MSExchangeRepl.exe
MSExchangeSearch - RPC (TCPMailbox In) MSExchangeThrottling - RPC (TCP-In) MSExchangeThrottling RPCEPMap (TCP-In)
Mailbox
Mailbox
Bin\MSExchangeThrottling.exe
Mailbox
Mailbox
Bin\MSFTED.exe
Bin\Microsoft.Exchange.EdgeSyncSvc.exe
http://technet.microsoft.com/en-us/library/bb331973(d=printer).aspx
1/5/2012
Page 15 of 17
Bin\edgetransport.exe
Hub 25, 587 Any Transport (TCP) Hub 25, 587 Bin\edgetransport.exe Transport (TCP)
Hub Transport, MSExchangeTransportLogSearch Dynamic Bin\MSExchangeTransportLogSearch.exe Edge - RPC (TCP-In) RPC Transport, Mailbox Hub Transport, MSExchangeTransportLogSearch RPCEdge - RPCEPMap (TCP-In) EPMap Transport, Mailbox Unified Any Messaging Unified Any Messaging Unified 5060, Messaging 5061 Unified 5060, Messaging 5061
Bin\MSExchangeTransportLogSearch.exe
Any
SESWorker (TCP-In)
UnifiedMessaging\SESWorker.exe
Any
UMService (TCP-In)
Bin\UMService.exe
5065, UMWorkerProcess (GFW) (TCP- Unified 5066, In) Messaging 5067, 5068 5065, Unified 5066, Messaging 5067, 5068
Any
UMWorkerProcess (TCP-In)
Bin\UMWorkerProcess.exe
http://technet.microsoft.com/en-us/library/bb331973(d=printer).aspx
1/5/2012
Page 16 of 17
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 restricted to processes are distinguished by the word (GFW) in the rule name. A number of Exchange services use remote procedure calls (RPCs) for communication. Server processes that use RPCs contact the RPC Endpoint Mapper to receive dynamic endpoints and register those endpoints in the Endpoint Mapper database. RPC clients contact the RPC Endpoint Mapper to determine the endpoints used by the server process. By default, the RPC Endpoint Mapper listens on port 135 (TCP). When configuring the Windows Firewall for a process that uses RPCs, Exchange 2010 Setup creates two firewall rules for the process. One rule allows communication with the RPC Endpoint Mapper, and the other rule allows communication with the dynamically assigned endpoint. To learn more about RPCs, see How 8 RPC Works . For more information about creating Windows Firewall rules for dynamic RPC, see 9 Allowing Inbound Network Traffic that Uses Dynamic RPC . 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 10 domains and trusts .
Links Table
1 2 3 4 5 6 7 8 9
http://technet.microsoft.com/en-us/library/ee633456.aspx http://technet.microsoft.com/en-us/library/bb124392.aspx http://technet.microsoft.com/en-us/library/aa998911.aspx http://go.microsoft.com/fwlink/?linkid=3052&kbid=937031 http://technet.microsoft.com/en-us/library/bb124092.aspx http://technet.microsoft.com/en-us/library/aa998265.aspx http://go.microsoft.com/fwlink/?LinkId=179177 http://go.microsoft.com/fwlink/?LinkId=69495 http://go.microsoft.com/fwlink/?LinkId=168278 http://go.microsoft.com/fwlink/?linkid=3052&kbid=179442
10
Community Content
Network Ports Diagram Edit
http://technet.microsoft.com/en-us/library/bb331973(d=printer).aspx
1/5/2012
Page 17 of 17
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/
http://technet.microsoft.com/en-us/library/bb331973(d=printer).aspx
1/5/2012