Data Path Security Reference
Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.
Applies to: Exchange Server 2007, Exchange Server 2007 SP1, Exchange Server 2007 SP2, Exchange Server 2007 SP3
This topic provides information about ports, authentication, and encryption for all data paths used by Microsoft Exchange Server 2007. The Notes sections following each table clarify or define non-standard authentication or encryption methods.
Transport Servers
Exchange 2007 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 to and from other Exchange 2007 servers and services.
Transport server data paths
| Data path | Required ports | Default authentication | Supported authentication | Encryption supported? | Encrypted by default? |
|---|---|---|---|---|---|
Hub Transport server to Hub Transport server |
25/TCP (Transport Layer Security [TLS]) |
Kerberos |
Kerberos |
Yes (TLS) |
Yes |
Hub Transport server to Edge Transport server |
25/TCP (TLS) |
Direct trust |
Direct trust |
Yes (TLS) |
Yes |
Edge Transport server to Hub Transport server |
25/TCP (TLS) |
Direct trust |
Direct trust |
Yes (TLS) |
Yes |
Edge Transport server to Edge Transport server |
25/TCP (TLS), 389/TCP/UDP, and 80/TCP (certificate authentication) |
Anonymous, Certificate |
Anonymous, Certificate |
Yes (TLS) |
Yes |
Mailbox server to Hub Transport server via the Microsoft Exchange Mail Submission Service |
135/TCP (RPC) |
NTLM. If the Hub Transport and the Mailbox server roles are on the same server, Kerberos is used. |
NTLM/Kerberos |
Yes (RPC encryption) |
Yes |
Hub Transport to Mailbox server via MAPI |
135/TCP (RPC) |
NTLM. If the Hub Transport and the Mailbox server roles are on the same server, Kerberos is used. |
NTLM/Kerberos |
Yes (RPC encryption) |
Yes |
Unified Messaging to Hub Transport |
25/TCP (TLS) |
Kerberos |
Kerberos |
Yes (TLS) |
Yes |
Microsoft Exchange EdgeSync service |
50636/TCP (SSL), 50389/TCP (No SSL) |
Basic |
Basic |
Yes (LDAPS) |
Yes |
Active Directory Application Mode (ADAM) directory service on Edge Transport server |
50389/TCP (No SSL) |
NTLM/Kerberos |
NTLM/Kerberos |
No |
No |
Active Directory directory service access from Hub Transport server |
389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon) |
Kerberos |
Kerberos |
Yes (Kerberos encryption) |
Yes |
End user SMTP client (for example, Outlook Express) to Hub Transport |
25/TCP (TLS), 587 (TLS) |
NTLM/Kerberos |
NTLM/Kerberos |
Yes (TLS) |
Yes |
Notes on Transport Servers
All traffic between Hub Transport servers is encrypted by using TLS with self-signed certificates that are installed by default by Exchange 2007 Setup. The traffic between Hub Transport servers is authenticated using Kerberos authentication.
All traffic between Edge Transport servers and Hub Transport servers is authenticated and encrypted. The underlying mechanism for authentication and encryption is mutual TLS. Instead of using X.509 validation, Exchange 2007 uses direct trust to authenticate the certificates. Direct trust means that the presence of the certificate in Active Directory or ADAM validates 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. 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 ADAM with the set of Hub Transport server certificates for the Edge Transport server to validate.
By default, traffic between Edge Transport servers in two different organizations is encrypted. Exchange 2007 Setup creates a self-signed certificate and TLS is enabled by default. This allows any sending system to encrypt the inbound SMTP session to Microsoft Exchange. By default, Exchange 2007 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 located on the same computer. When mail submission is local, Kerberos authentication is used. When mail submission is remote, NTLM authentication is used.
Exchange 2007 also supports Domain Security. Domain Security refers to the set of functionality in Exchange 2007 and Microsoft Office Outlook 2007 that provides a low-cost alternative to S/MIME or other message-level over-the-Internet, security solutions. The purpose of the Domain Security feature set is to provide administrators a way to manage secured message paths between domains over the Internet. After these secured message paths are configured, messages that have successfully traveled over the secured path from an authenticated sender are displayed to users as "Domain Secured" in the Outlook and Outlook Web Access interface. For more information, see Planning for Domain Security.
Many agents may run on the Hub Transport servers and Edge Transport servers. Generally, the anti-spam agents rely on information that is local to the computer that the agents run on. Therefore, very little communication with remote computers is required. The exception is recipient filtering. This requires calls to either ADAM or Active Directory. It is a best practice to run recipient filtering on the Edge Transport server. In this case, the ADAM 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 2007. 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 ADAM directory by using the Microsoft Exchange EdgeSync service.
Journaling and message classification run on Hub Transport servers and rely on Active Directory data to function.
Mailbox Server
In the context of the Mailbox server role, whether the authentication is NTLM or Kerberos relies 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. In many of the "Default Authentication" cells in the "Mailbox Server data paths" table in this section, the authentication is 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 computer account Local System and a two-way authenticated trust must exist.
If the Exchange Business Logic layer consumer is not running as Local System, the authentication method is NTLM. For example, when an Administrator runs an Exchange Management Shell cmdlet that uses the Exchange Business Logic layer, NTLM is used.
The RPC traffic is always encrypted.
The following table provides information about ports, authentication, and encryption for data paths to and from Mailbox servers
Mailbox server data paths
| Data path | Required ports | Default authentication | Supported authentication | Encryption supported? | Encrypted by default? |
|---|---|---|---|---|---|
Cluster Continuous Replication (CCR) and Standby Continuous Replication (SCR) log shipping |
445/TCP |
NTLM/Kerberos |
NTLM/Kerberos |
Yes (IPsec) |
No |
CCR and SCR seeding |
Random port |
NTLM/Kerberos |
NTLM/Kerberos |
Yes (IPsec) |
No |
Volume shadow copy service (VSS) backup |
Local Message Block (SMB) |
NTLM/Kerberos |
NTLM/Kerberos |
No |
No |
Legacy Backup |
Random port |
NTLM/Kerberos |
NTLM/Kerberos |
Yes (IPsec) |
No |
Clustering |
135/TCP (RPC) See "Notes on Mailbox Servers" after this table. |
NTLM/Kerberos |
NTLM/Kerberos |
Yes (IPsec) |
No |
MAPI access |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
Yes (RPC encryption) |
Yes |
Mailbox Assistants |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
No |
No |
Availability Web service (Client Access to Mailbox) |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
Yes (RPC encryption) |
Yes |
Active Directory access |
389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon) |
Kerberos |
Kerberos |
Yes (Kerberos encryption) |
Yes |
Content indexing |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
Yes (RPC encryption) |
Yes |
Admin remote access (Remote Registry) |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
Yes (IPsec) |
No |
Admin remote access (SMB/File) |
445/TCP (SMB) |
NTLM/Kerberos |
NTLM/Kerberos |
Yes (IPsec) |
No |
Recipient Update Service RPC access |
135/TCP (RPC) |
Kerberos |
Kerberos |
Yes (RPC encryption) |
Yes |
Microsoft Exchange Active Directory Topology service access |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
Yes (RPC encryption) |
Yes |
Microsoft Exchange System Attendant service legacy access (Listen to requests) |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
No |
No |
Microsoft Exchange System Attendant service legacy access to Active Directory |
389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon) |
Kerberos |
Kerberos |
Yes (Kerberos encryption) |
Yes |
Microsoft Exchange System Attendant service legacy access (As MAPI client) |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
Yes (RPC encryption) |
Yes |
Offline Address Book (OAB) accessing Active Directory |
135/TCP (RPC) |
Kerberos |
Kerberos |
Yes (RPC encryption) |
Yes |
Recipient update to Active Directory |
389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon) |
Kerberos |
Kerberos |
Yes (Kerberos encryption) |
Yes |
DSAccess to Active Directory |
389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon) |
Kerberos |
Kerberos |
Yes (Kerberos encryption) |
Yes |
Outlook accessing Offline Address Book (OAB) Note Applies to Outlook 2003 or earlier versions. This setting also applies to Office Outlook 2007 clients when the Web Distribution of the Offline Address Book feature is not enabled. |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
Yes (RPC Encryption) |
Yes |
WebDav |
80/TCP, 443/TCP (SSL) |
Basic, NTLM, Negotiate |
Basic, NTLM, Negotiate |
Yes (HTTPS) |
Yes |
Notes on Mailbox Servers
For HTTP authentication where "Negotiate" is listed, Kerberos is tried first, and then NTLM.
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.
Although WebDav applications or clients can connect to the Mailbox server by using 80/TCP or 443/TCP, in most cases the application or clients connect to the Client Access server. The Client Access server then connects to the Mailbox server over 80/TCP or 443/TCP.
The clustering data path listed in the "Mailbox Server data paths" table in this section uses dynamic RPC (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 communicate between cluster nodes.
Client Access Server
Unless noted, client access technologies, such as Microsoft Office Outlook Web Access, POP3, or IMAP4, are described by the authentication and encryption from the client application to the Client Access server.
The following table provides information about port, authentication, and encryption for data paths between Client Access servers and other servers and clients.
Client Access server data paths
| Data path | Required ports | Default authentication | Supported authentication | Encryption supported? | Encrypted by default? |
|---|---|---|---|---|---|
Autodiscover service |
80/TCP, 443/TCP (SSL) |
Basic/Integrated Windows authentication (Negotiate) |
Basic, Digest, NTLM, Negotiate (Kerberos) |
Yes (HTTPS) |
Yes |
Availability service |
80/TCP, 443/TCP (SSL) |
NTLM/Kerberos |
NTLM, Kerberos |
Yes (HTTPS) |
Yes |
Outlook Web Access |
80/TCP, 443/TCP (SSL) |
Forms Based Authentication |
Basic, Digest, Forms Based Authentication, NTLM (v2 only), Kerberos, Certificate |
Yes (HTTPS) |
Yes using self-signed certificate |
POP3 |
110/TCP (TLS), 995/TCP (SSL) |
Basic, NTLM, Kerberos |
Basic, NTLM, Kerberos |
Yes (SSL, TLS) |
Yes |
IMAP4 |
143/TCP (TLS), 993/TCP (SSL) |
Basic, NTLM, Kerberos |
Basic, NTLM, Kerberos |
Yes (SSL, TLS) |
Yes |
Outlook Anywhere (formerly known as RPC over HTTP ) |
80/TCP, 443/TCP (SSL) |
Basic |
Basic or NTLM |
Yes (HTTPS) |
Yes |
Exchange ActiveSync application |
80/TCP, 443/TCP (SSL) |
Basic |
Basic, Certificate |
Yes (HTTPS) |
Yes |
Client Access server to Unified Messaging server |
5060/TCP, 5061/TCP, 5062/TCP, a dynamic port |
By IP address |
By IP address |
Yes (Session Initiation Protocol [SIP] over TLS) |
Yes |
Client Access server to a Mailbox server that is running an earlier version of Exchange Server |
80/TCP, 443/TCP (SSL) |
NTLM/Kerberos |
Negotiate (Kerberos with fallback to NTLM or optionally Basic,) POP/IMAP plain text |
Yes (IPsec) |
No |
Client Access server to Exchange 2007 Mailbox server |
RPC. See "Notes on Client Access Servers" after this table. |
Kerberos |
NTLM/Kerberos |
Yes (RPC encryption) |
Yes |
Client Access server to Client Access server (Exchange ActiveSync) |
80/TCP, 443/TCP (SSL) |
Kerberos |
Kerberos, Certificate |
Yes (HTTPS) |
Yes using self-signed certificate |
Client Access server to Client Access server (Outlook Web Access) |
80/TCP, 443/TCP (SSL) |
Kerberos |
Kerberos |
Yes (HTTPS) |
Yes |
WebDAV |
80/TCP, 443/TCP (SSL) |
HTTP Basic or Outlook Web Access forms-based authentication |
Basic, Outlook Web Access forms-based authentication |
Yes (HTTPS) |
Yes |
Outlook accessing Offline Address Book (OAB) Note Applies to Office Outlook 2007 when the Web Distribution of the Offline Address Book feature is enabled. |
80/TCP, 443/TCP (SSL) |
NTLM/Kerberos |
NTLM/Kerberos |
Yes (HTTPS) |
No |
Notes on Client Access Servers
The Client Access server communicates with the Mailbox server by using many ports. With some exceptions, those ports are determined by the remote procedure call (RPC) service and are not fixed. It is possible to specify the range of dynamic ports that are used by the RPC service. For more information about restricting the range of dynamic ports that are used by the RPC service, see Microsoft Knowledge Base article 154596, How to configure RPC dynamic port allocation to work with firewalls.
Important
We do not support configurations in which a firewall is added between Client Access servers and Mailbox servers that are in the same Active Directory site.
Important
We do not support configurations in which a Client Access server is installed in a perimeter network. The Client Access server must be a member of an Active Directory domain, and the Client Access server computer account must be a member of the Exchange Servers Active Directory security group. The Exchange Servers Active Directory security group has read and write access to all Exchange servers in your organization. Communication between the Client Access server and the Mailbox servers in the organization occurs by using the RPC service. It is because of these requirements that installing a Client Access server in a perimeter network is not supported.
For HTTP authentication where "Negotiate" is listed, Kerberos is tried first, and then NTLM is tried.
When an Exchange 2007 Client Access server is communicating with a Mailbox server that is running Exchange Server 2003, it is a best practice to use Kerberos and disable NTLM authentication and Basic authentication. Additionally, it is a best practice to configure Outlook Web Access to use forms-based authentication with a trusted certificate. In order for Exchange ActiveSync clients to communicate through the Exchange 2007 Client Access 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 a server that is running Exchange 2003 to manage authentication on an Exchange 2003 virtual directory, download and install the hotfix that is referenced in Microsoft Knowledge Base article 937301, 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.
Unified Messaging Server
IP gateways only support certificate-based authentication that uses mutual TLS and IP-based authentication for Session Initiation Protocol (SIP)/TCP connections. IP gateways do not support either NTLM or Kerberos authentication. Therefore, when 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 Unified Messaging, the Unified Messaging server verifies that the IP address is allowed to connect. The IP address is configured on the IP gateway or IP PBX.
The following table provides information about port, authentication, and encryption for data paths between Unified Messaging servers and other servers.
Unified Messaging server data paths
| Data path | Required ports | Default authentication | Supported authentication | Encryption supported? | Encrypted by default? |
|---|---|---|---|---|---|
Unified Messaging Fax |
5060/TCP, 5061/TCP, 5062/TCP, a dynamic port |
By IP address |
By IP address |
SIP over TLS, but media is not encrypted |
Yes for SIP |
Unified Messaging Phone interaction (PBX) |
5060/TCP, 5061/TCP, 5062/TCP, a dynamic port |
By IP address |
By IP address |
SIP over TLS, but Media is not encrypted |
Yes for SIP |
Unified Messaging Web Service |
80/TCP, 443/TCP (SSL) |
Integrated Windows authentication (Negotiate) |
Basic, Digest, NTLM, Negotiate (Kerberos) |
Yes (SSL) |
Yes |
Unified Messaging to Hub Transport |
25/TCP (SSL) |
Kerberos |
Kerberos |
Yes (TLS) |
Yes |
Unified Messaging server to Mailbox server |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
Yes (RPC encryption) |
Yes |
Notes on Unified Messaging Servers
When you create a Unified Messaging (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 that the Unified Messaging server is allowed to communicate with. When the UM IP gateway is created, it is associated 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 is not configured to use the correct IP address, authentication fails and the Unified Messaging servers do not accept connections from that IP gateway's IP address.
For the original release to manufacturing (RTM) version of Exchange 2007, a Unified Messaging server can either communicate on port 5060/TCP (unsecured) or on port 5061/TCP (secured) but not both.
For more information, see Understanding Unified Messaging VoIP Security and Understanding Protocols, Ports, and Services in Unified Messaging.
For More Information
For more information, see Microsoft Knowledge Base article 179442, How to configure a firewall for domains and trusts.