Exchange 2010 Security Guide

 

Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2

This guide is written for the IT administrator responsible for securing the Microsoft Exchange Server 2010 deployment and is designed to help the IT administrator understand and manage the overall security environment where Exchange is installed.

In the past, for each version of Microsoft Exchange, the Exchange team has published stand-alone security hardening guides with permission and security information. This approach made sense for locking down services and directories after Exchange 2010 Setup ran. However, starting with Microsoft Exchange Server 2007, Exchange Setup enables only those services that are required by the server role that's being installed. Microsoft Exchange is no longer installed and then hardened for security. It's designed to help you be more secure by default.

Therefore, unlike earlier versions of Microsoft Exchange where IT administrators had to perform multiple procedures to lock down their servers that were running Microsoft Exchange, Exchange 2010 requires no lock-down or hardening.

Scope

Exchange 2010 was developed using Microsoft Security Development Lifecycle (SDL) principles. A security review was performed for each feature and component. Carefully chosen default settings ensure a more secure deployment. The scope of this guide is to inform administrators about security-related features and the features that may affect security considerations. This guide links to security-related topics in Exchange 2010 documentation. These topics are listed in Appendix 1: Additional Security-Related Documentation. This guide doesn't cover any steps to harden the Windows Server operating system.

Contents

What's New

The Exchange 2010 Security Development Lifecycle

Getting Secure—Best Practices

Staying Secure—Best Practices

Network Port Usage and Firewall Hardening

Throttling Parameters and Client Throttling Policies

Role-Based Access Control

Active Directory

Exchange Server Accounts

File System

Services

Certificates

NTLM Considerations

Dual-Factor Authentication

Federation

Secure/Multipurpose Internet Mail Extensions (S/MIME)

Server Role Considerations

Appendix 1: Additional Security-Related Documentation

What's New

Exchange 2010 includes the following new security features:

• Role-Based Access Control   Exchange 2010 includes a new role-based access control model that lets your organization granularly manage permissions assigned to different stakeholders such as recipient administrators, server administrators, records and discovery managers, and organization administrators.

• Throttling Policies   Exchange 2010 introduces throttling mechanisms on Mailbox, Client Access, and Transport servers to protect your organization from denial of service attacks and reduce the impact of such attacks.

• Federated Delegation   Exchange 2010 introduces new federated delegation features that enable you to allow your users to securely collaborate with users in external organizations. Using federated delegation, users can share their calendar and contacts with users in external federated organizations. Cross-forest collaboration is also made possible, without the need to set up and manage Active Directory trust relationships.

• Information Rights Management   Exchange 2010 includes new information protection and control features that enable you to protect sensitive message content at multiple levels while maintaining your organization's ability to decrypt, search, and apply messaging policies to protected content.

• No Security Configuration Wizard   In Exchange 2010, Setup makes the configuration changes necessary to install and enable only those services required for a particular Exchange server role and to limit communication to only those ports required for the services and processes running on each server role. This removes the need for tools such as the Security Configuration Wizard (SCW) to configure these settings.

The Exchange 2010 Security Development Lifecycle

In early 2002, Microsoft introduced the Trustworthy Computing initiative. Since Trustworthy computing was introduced, the development process at Microsoft and in the Microsoft Exchange team has focused on developing software that helps you become more secure. For more information, see Trustworthy Computing.

In Exchange 2010, Trustworthy Computing was implemented in the following core areas:

• Secure by design   Exchange 2010 was designed and developed in compliance with The Trustworthy Computing Security Development Lifecycle. The first step in creating a more secure messaging system was to design threat models and test each feature as it was designed. Multiple security-related improvements were built into the coding process and practices. Build-time tools detect buffer overruns and other potential security threats. No system can guarantee complete security. However, by including secure design principles into the whole design process, Exchange 2010 is more secure than earlier versions have been.

• Secure by default   One goal of Exchange 2010 was to develop a system in which most network communications are encrypted by default. Except for Server Message Block (SMB) communications and some Unified Messaging (UM) communications, the goal was met. By using self-signed certificates, the Kerberos protocol, Secure Sockets Layer (SSL), and other industry standard encryption techniques, almost all Exchange 2010 data is protected on the network. In addition, role-based setup makes it possible to install Exchange 2010 so that only the services, and the permissions related to those services, are installed with a specific and appropriate server role. In earlier versions of Microsoft Exchange, all services for all functionality had to be installed.

• Anti-spam and antivirus functionality   Exchange 2010 includes a suite of anti-spam agents that run at the perimeter network on the Edge Transport server role, and can also be installed on the Hub Transport server role residing on the internal network. Antivirus functionality is further improved by the addition of Microsoft Forefront Protection 2010 for Exchange Server as a Microsoft solution.

• Secure in deployment   As Exchange 2010 was developed, the pre-release version was deployed in the Microsoft IT production environment. Based on the data from that deployment, the Microsoft Exchange Server Best Practices Analyzer has been updated to scan for real-world security configurations, and pre-deployment and post-deployment best practices have been documented in the Exchange 2010 Help.

  In the past, permission management was documented and delivered after the core documentation was finished. However, we know that permissions management isn't an add-in process. It should be built into the overall planning and deployment of your Exchange 2010 deployment. Therefore, we've streamlined our permission documentation and integrated it into the core documentation to provide seamless context for administrators as they plan for and deploy their administrative model. Exchange 2010 includes a new role-based permissions model that allows you to grant granular permissions to administrators and users to enable them to perform tasks with the minimum permissions required.

• Communications   Now that Exchange 2010 is released, the Exchange team is committed to keeping software up-to-date and you informed. By keeping your system up-to-date with Microsoft Update, you can make sure that the latest security updates are installed in your organization. Exchange 2010 also includes anti-spam updates. In addition, by subscribing to the Microsoft Technical Security Notifications, you can keep up with the latest security issues in Exchange 2010.

Getting Secure—Best Practices

Some basic best practices will help you create and maintain a more secure environment. Generally, running analyzer tools periodically and keeping software and antivirus signatures files up to date are the most effective ways to optimize your Exchange 2010 environment for security.

Setup and Installation Recommendations

These best practices will help you create a more secure Exchange 2010 environment:

• Delegate Setup   The first Exchange 2010 server you install in your organization requires that the account you use to run Setup must be a member of the Enterprise Administrators group. The account you use is added to the Organization Management role group created by Exchange 2010 Setup. You can use delegated setup to allow administrators who aren't members of the Organization Management role group to set up subsequent servers. For more details, see Provision Exchange 2010 Server and Delegate Setup.

• File system permissions   Exchange 2010 Setup assigns the minimum required permissions on the file system where Exchange binaries and data are stored. You must not make any changes to the Access Control Lists (ACLs) on the root folders and the Program Files folder on the file system.

• Install paths   We recommend that you install Exchange 2010 binaries on a non-system drive (a volume other than where the operating system is installed). Exchange databases and transaction logs can grow rapidly, and must be located on non-system volumes sized for capacity and performance. Many other logs generated by different Exchange components, such as transport logs, are also stored in the same install path as Exchange binaries and can grow significantly, depending on the configuration and your messaging environment. In Exchange 2010, the maximum size of many log files and the maximum storage space a log file folder can occupy is configurable, and is set to a default of 250 Megabytes. To prevent a potential system outage because of low disk space, we recommend that you assess the logging requirements for each server role and configure the logging options and log file storage locations to meet your requirements.

• Blocking legacy Outlook clients   Based on your requirements, you can configure Outlook client blocking to block legacy Outlook client versions. Certain Exchange 2010 features, such as Outlook Protection Rules and Personal Archives, don't support legacy Outlook clients. For more information about Outlook client blocking, see Configure Outlook Client Blocking.

• Decoupling SMTP addresses from usernames   By default, Exchange generates e-mail addresses and aliases based on the mailbox user's username. Many organizations create an additional e-mail address policy to decouple user e-mail addresses from usernames for added security. For example, if the user Ben Smith's username is bsmith and the domain is contoso.com, the primary e-mail address generated by the default e-mail address policy is bsmith@contoso.com. You can create an additional e-mail address policy to generate e-mail addresses that don't use the user's alias or username. For example, creating an e-mail address policy to use the template %g.%s@domain generates e-mail addresses in the format Firstname.Lastname@domain. For the user Ben Smith, the policy will generate the address Ben.Smith@contoso.com. Or, you can decouple e-mail addresses from usernames by specifying an alias that's different from the username when you create or enable a mailbox.

  Note

  If a user's primary SMTP address doesn't match the UPN on the account, the user can't use their e-mail address to sign in to Microsoft Office Outlook Web App and must provide a username using the DOMAIN\username format. When using Microsoft Outlook, the user must provide the username in DOMAIN\username format if prompted for credentials when Outlook connects to the Autodiscover service.

Microsoft Update

Microsoft Update is a service that offers the same downloads as Microsoft Windows Update—plus the latest updates for other Microsoft programs. It can help you keep your server more secure and performing at its best.

A key feature of Microsoft Update is Windows Automatic Update. This feature automatically installs high-priority updates that are critical to the security and reliability of your computer. Without these security updates, your computer is more vulnerable to attack from cyber-crooks and malicious software (malware).

The most reliable way to receive Microsoft Update is to have the updates delivered automatically to your computer by using Windows Automatic Updates. You can turn on Automatic Updates when you sign up for Microsoft Update.

Windows will then analyze the Microsoft software that's installed on your computer for any current and past high-priority updates it requires and then download and install them automatically. After that, when you connect to the Internet, Windows repeats the update process for any new high-priority updates.

To enable Microsoft Update, see Microsoft Update.

The default mode of Microsoft Update requires that each Exchange server is connected to the Internet to receive automatic updates. If you are running servers that aren't connected to the Internet, you can install Windows Server Update Services (WSUS) to manage the distribution of updates to computers in your organization. You can then configure Microsoft Update on the internal Microsoft Exchange computers to contact your internal WSUS server for updates. For more information, see Microsoft Windows Server Update Services 3.0.

WSUS isn't the only Microsoft Update management solution available. For more information about Microsoft security releases, processes, communications and tools, see the Microsoft Security Update Guide.

Tasks No Longer Required in Exchange 2010

It's no longer necessary to install or run the following tools:

• The URLScan security tool isn't required for IIS 7. In earlier versions of Microsoft Exchange, it was a common practice to install IIS tools such as URLScan to secure an IIS installation. Exchange 2010 requires Windows Server 2008, which includes IIS 7. Many of the security features that were originally available in UrlScan are now available in the IIS 7 Request Filtering features.

• You no longer need to install the Exchange Best Practices Analyzer. In earlier versions of Microsoft Exchange, it was a common practice to install and run the Exchange Best Practices Analyzer before installation and regularly after that. Exchange 2010 Setup includes the Exchange Best Practices Analyzer components and runs them during setup. It isn't required to run the Exchange Best Practices Analyzer before setup.

• You no longer need to use the Security Configuration Wizard (SCW) or the Exchange templates for SCW. Exchange 2010 Setup installs only those services required for a given Exchange server role, and creates Windows Firewall with Advanced Security rules to open only the ports required for the services and processes for that server role. It's no longer required to run the Security Configuration Wizard (SCW) to do this. Unlike Exchange Server 2007, Exchange 2010 isn't included with SCW templates.

Staying Secure—Best Practices

These best practice recommendations will help you keep your Exchange 2010 environment secure.

Keeping Software up to Date

As mentioned in an earlier section, running Microsoft Update is a best practice. In addition to running Microsoft Update on all servers, it's also very important to keep all client computers up to date and to maintain antivirus updates on all computers in your organization.

In addition to Microsoft software, make sure that you run the latest updates for all software that's running in your organization.

Anti-Spam Updates

Exchange 2010 also uses the Microsoft Update infrastructure to keep the anti-spam filters up-to-date. By default, with manual updates, the administrator must visit Microsoft Update to download and install the content filter updates. The content filter update data is updated and available every two weeks.

Manual updates from Microsoft Update include the Microsoft IP Reputation Service or spam signature data. The Microsoft IP Reputation Service and spam signature data is only available with Forefront Security for Exchange Server anti-spam automatic updates.

For more information about how to enable Forefront anti-spam automatic updates, see Understanding Anti-Spam Updates.

Running Antivirus Software

Viruses, worms, and other malicious content transmitted by e-mail systems are a destructive reality faced by most Microsoft Exchange administrators. Therefore, you must develop a defensive antivirus deployment for all messaging systems. This section provides best practices recommendations for the deployment of antivirus software for Exchange 2010.

You should pay additional attention to two important changes in Exchange 2010 when you select an antivirus software vendor:

• Starting with Exchange Server 2007, Microsoft Exchange is based on a 64-bit architecture.

• Exchange 2010 includes transport agent functionality.

These two changes mean that antivirus vendors must provide Exchange 2010-specific software. Antivirus software that's written for earlier versions of Exchange is unlikely to operate correctly with Exchange 2010.

To use a defense-in-depth approach, we recommend that you deploy antivirus software that's designed for messaging systems at either the SMTP gateway or at the Exchange servers that host mailboxes, in addition to antivirus software on the user desktop.

You decide what types of antivirus software to use and where the software is deployed by determining the appropriate balance between the cost and risk you are willing to assume. For example, some organizations run antivirus messaging software at the SMTP gateway, file-level antivirus scanning at the Exchange server, and antivirus client software on the user desktop. This approach provides messaging-specific protection at the client. Other organizations may tolerate higher costs and therefore improve security by running antivirus messaging software at the SMTP gateway, file-level antivirus scanning at the Exchange server, and antivirus client software on the user desktop, together with antivirus software that's compatible with Exchange Virus Scanning Application Programming Interface (VSAPI) 2.5 on the Exchange Mailbox server.

Running Antivirus Software on Edge Transport Servers and Hub Transport Servers

Transport-based antivirus software is implemented as or includes transport agents. Transport agents act on transport events, much like event sinks in earlier versions of Microsoft Exchange. For more details, see Understanding Transport Agents.

Note

Messages that aren't routed through transport, such as items in public folders, Sent Items, and calendar items, which can only be scanned on a Mailbox server, aren't protected by transport-only virus scanning.

Third-party developers can write customized transport agents to take advantage of the underlying MIME-parsing engine for robust transport-level antivirus scanning. For a list of Exchange antivirus and anti-spam partners, see Independent Software Vendors.

In addition, Forefront Protection for Exchange Server is an antivirus software package that's tightly integrated with Exchange 2010 and offers additional antivirus protection for your Exchange environment. For more information, see Microsoft Forefront Protection 2010 for Exchange Server.

The most important position for messaging antivirus software is at the first line of defense in your organization. This is the SMTP gateway through which external messages enter your messaging environment. In Exchange 2010, the first line of defense is the Edge Transport server.

If you use a non–Exchange SMTP server or gateway to receive inbound e-mail before Exchange, you should implement sufficient anti-spam and antivirus functionality on the non–Exchange SMTP hosts.

In Exchange 2010, all messages are routed through a Hub Transport server. This includes messages sent or received from outside the Exchange organization and messages sent within the Exchange organization. Messages sent to a mailbox located on the same Mailbox server as the sender. To better guard against virus outbreaks from inside the organization and to provide a second line of defense, we also recommend that you run transport-based antivirus software on Hub Transport servers.

Running Antivirus Software on Mailbox Servers

In addition to virus scanning on transport servers, a Microsoft Exchange Virus Scanning API (VSAPI) scanning solution running on Mailbox servers may be an important layer of defense in many organizations. You should consider running a VSAPI antivirus solution if any of the following conditions is true:

• Your organization doesn't have complete and reliable desktop antivirus scanning products deployed.

• Your organization wants the additional protection that scanning mailbox databases can provide.

• Your organization has developed custom applications that have programmatic access to an Exchange database.

• Your user community regularly posts messages in public folders.

Antivirus solutions that use Exchange VSAPI run directly within the Exchange information store process. VSAPI solutions are likely the only solutions that can protect against attack vectors that put infected content inside the Exchange information store while bypassing the standard client and transport scanning. For example, VSAPI is the only solution that scans data that's submitted to a database by CDO (Collaboration Data Objects), WebDAV, and Exchange Web Services (EWS). In addition, when a virus outbreak does occur, frequently a VSAPI solution provides the quickest way to remove and eliminate viruses from an infected mail database.

Exchange Server and File System Antivirus

If you deploy file-system antivirus software to protect your Exchange servers, consider the following:

• You must exclude Exchange server directories where the Exchange mailbox and public folder databases are stored, from file system antivirus scanners. For details, see File-Level Antivirus Scanning on Exchange 2010.

• File system antivirus scanners only protect files. To protect e-mail messages, you should also consider implementing Exchange-aware antivirus or messaging security products such as including Microsoft Forefront, or suitable partner or third-party products. For details about anti-spam and antivirus protection, see Understanding Anti-Spam and Antivirus Functionality. For details, see Forefront Protection 2010 for Exchange Server: Overview.

• You must keep antivirus and anti-spam signatures up-to-date for effective protection.

• Reports from antivirus and anti-spam software or services should be reviewed regularly to ensure protection is enabled and performing as required, detect incidents quickly, and take any required action.

Using Exchange Hosted Services

Spam and virus filtering is improved by or is also available as a service from Microsoft Exchange Hosted Services. Exchange Hosted Services is a set of four distinct hosted services:

• Hosted Filtering, which helps organizations protect themselves from e-mail-borne malware

• Hosted Archive, which helps organizations satisfy compliance and retention requirements

• Hosted Encryption, which helps organizations encrypt data to preserve confidentiality

• Hosted Continuity, which helps organizations preserve access to e-mail during and after outages

These services integrate with any on-premises Exchange servers that are managed in house. For more information, see Forefront Online Protection for Exchange.

Using Attachment Filtering

In Exchange 2010, attachment filtering lets you apply filters on Edge Transport servers to control the attachments that users receive. Attachment filtering is increasingly important in today's environment where many attachment types contain harmful viruses or unsuitable material that may cause significant damage to the user's computer or to the organization by damaging important documentation or releasing sensitive information to the public.

You can use the following types of attachment filtering to control attachments that enter or leave your organization through an Edge Transport server:

Filtering based on file name or file name extension   You can filter attachments by specifying the exact file name or file name extension to be filtered. An example of an exact file name filter is BadFilename.exe. An example of a file name extension filter is *.exe.

Filtering based on file MIME content type   You can also filter attachments by specifying the MIME content type to be filtered. MIME content types indicate what the attachment is, whether it's a JPEG image, an executable file, a Microsoft Office Excel 2010 file, or some other file type. Content types are express as type/subtype. For example, the JPEG image content type is express as image/jpeg.

If an attachment matches one of these filtering criteria, you can configure the following actions to be performed on the attachment:

• Block whole message and attachment

• Strip attachment but allow message through

• Silently delete message and attachment

For more details, see Understanding Attachment Filtering.

Note

You can't use the Attachment Filter agent to filter attachments based on their content. You can use transport rules to inspect the message and attachment content, and take actions such as deleting or rejecting the message, or IRM-protecting the message and attachments. For details, see Understanding Transport Rules.

File Filtering Using Forefront Protection for Exchange Server

The file filtering functionality that's provided by Forefront Protection for Exchange Server includes advanced features aren't available in the Attachment Filter agent included with Exchange 2010.

For example, container files, which are files that contain other files, can be scanned for offending file types. Forefront Protection for Exchange Server filtering can scan the following container files and act upon embedded files:

• PKZip (.zip)

• GNU Zip (.gzip)

• Self-extracting compressed file archives (.zip)

• Compressed files (.zip)

• Java archive (.jar)

• TNEF (winmail.dat)

• Structured storage (.doc, .xls, .ppt, and more)

• MIME (.eml0

• SMIME (.eml)

• UUEncode (.uue)

• Unix tape archive (.tar)

• RAR archive (.rar)

• MACBinary (.bin)

Note

The Attachment Filter agent included with Exchange 2010 detects file types even if they've been renamed. Attachment filtering also makes sure that compressed Zip and LZH files don't contain blocked attachments by performing a file name extension match against the files in the compressed Zip or LZH file. Forefront Protection for Exchange Server file filtering has the additional capability of determining whether a blocked attachment has been renamed within a container file.

You can also filter files by file size. Also, you can configure Forefront Protection for Exchange Server to quarantine filtered files or to send e-mail notifications based Exchange on file filter matches.

For more information, see Protecting Your Microsoft Exchange Organization with Microsoft Forefront Security for Exchange Server.

Running the Exchange Best Practices Analyzer

The Exchange Best Practices Analyzer is one of the most effective tools that you can run regularly to help verify that your Exchange environment is secure. The Exchange Best Practices Analyzer automatically examines your Microsoft Exchange deployment and determines whether it's configured according to Microsoft best practices. In Exchange 2010, the Exchange Best Practices Analyzer is installed as part of Exchange Setup and can be run from the Tools section of the Exchange Management Console (EMC). With the appropriate network access, the Exchange Best Practices Analyzer examines all your Active Directory Domain Services (AD DS) servers and Exchange servers. The Exchange Best Practices Analyzer includes permissions inheritance checks. Also, it tests for validation of RBAC permissions. This include tests to ensure all users can access the Exchange Control Panel (ECP), all default RBAC roles created by Exchange Setup are configured properly, and there's at least one administrative account present within the Exchange organization.

Network Port Usage and Firewall Hardening

Windows Server 2008 includes Windows Firewall with Advanced Security, a stateful packet inspection firewall that's enabled by default. Windows Firewall with Advanced Security provides the following functionality:

• Filtering of all IP version 4 (IPv4) and IP version 6 (IPv6) traffic entering or leaving the computer. By default, all incoming traffic is blocked unless it's a response to a previous outgoing request from the computer (solicited traffic), or it's specifically allowed by a rule created to allow that traffic. By default, all outgoing traffic is allowed, except for service hardening rules that prevent standard services from communicating in unexpected ways. You can choose to allow traffic based on port numbers, IPv4 or IPv6 addresses, the path and name of an application, or the name of a service that's running on the computer, or other criteria.

• Protecting network traffic entering or exiting the computer by using the IPsec protocol to verify the integrity of the network traffic, to authenticate the identity of the sending and receiving computers or users, and to optionally encrypt traffic to provide confidentiality.

Exchange 2010 is designed to run with the Windows Server Firewall with Advanced Security enabled. Exchange Setup creates the required firewall rules to allow Exchange services and processes to communicate. It creates only the rules required for the services and processes installed on a given server role. For more details about network port usage and firewall rules created for each Exchange 2010 server role, see Exchange Network Port Reference.

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 2010 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 which are also created by Exchange 2010 Setup and are restricted to processes, if your deployment supports them. Rules that aren't restricted to processes are distinguished by the word (GFW) in the rule name. We recommend that you perform sufficient testing of the rules in your environment before you disable the rules that aren't restricted to a process.

The following table lists the Windows Firewall rules created by Exchange Setup, including the ports opened on each server role.

Windows Firewall rules

Rule name	Server roles	Port
MSExchangeRPCEPMap (GFW) (TCP-In)	All roles	RPC-EPMap
MSExchangeRPC (GFW) (TCP-In)	Client Access, Hub Transport, Mailbox, Unified Messaging	Dynamic RPC
MSExchange - IMAP4 (GFW) (TCP-In)	Client Access	143, 993 (TCP)
MSExchange - POP3 (GFW) (TCP-In)	Client Access	110, 995 (TCP)
MSExchange - OWA (GFW) (TCP-In)	Client Access	5075, 5076, 5077 (TCP)
MSExchangeMailboxReplication (GFW) (TCP-In)	Client Access	808 (TCP)
MSExchangeIS (GFW) (TCP-In)	Mailbox	6001, 6002, 6003, 6004 (TCP)
MSExchangeTransportWorker (GFW) (TCP-In)	Hub Transport	25, 587 (TCP)
SESWorker (GFW) (TCP-In)	Unified Messaging	Any
UMService (GFW) (TCP-In)	Unified Messaging	5060, 5061 (TCP)
UMWorkerProcess (GFW) (TCP-In)	Unified Messaging	5065, 5066, 5067, 5068

Important

When modifying the default port used by an Exchange 2010 service, you must also modify the corresponding Windows Firewall with Advanced Security firewall rule to allow communication over the nondefault port you decide to use. Exchange 2010 doesn't change firewall rules when you change default ports used for a service.

Throttling Parameters and Client Throttling Policies

Exchange 2010 includes throttling parameters on Transport, Client Access Server and Mailbox server roles to control different parameters of connections related to each protocol. Exchange 2010 also includes client throttling policies to control the load on Client Access servers. These throttling parameters and policies help you to control the load and protect Exchange 2010 servers from denial of service attacks targeted at different protocols.

Throttling Parameters on Transport Servers

On Exchange 2010 Transport servers, message throttling parameters are implemented on the server and on Send and Receive connectors to control message processing rates, SMTP connection rates, and SMTP session time-out values. Together, these throttling parameters protect transport servers from being overwhelmed by accepting and delivering lots of messages, providing protection from rogue SMTP clients and denial of service attacks.

You can configure the following throttling policies on Exchange 2010 Transport servers using the Set-TransportServer cmdlet.

Transport server throttling parameters

Parameter	Description
MaxConcurrentMailboxDeliveries	The MaxConcurrentMailboxDeliveries parameter specifies the maximum number of delivery threads that the Hub Transport server can have open at the same time to deliver messages to mailboxes. The store driver on the Hub Transport server is responsible for delivering messages to and from Mailbox servers. This limit applies to the delivery of messages to any mailboxes in the Exchange organization. Default   20 deliveries
MaxConcurrentMailboxSubmissions	The MaxConcurrentMailboxSubmissions parameter specifies the maximum number of delivery threads that the Hub Transport server can have open at the same time to accept messages from mailboxes. The store driver on the Hub Transport server is responsible for delivering messages to and from Mailbox servers. This limit applies to the acceptance of new messages from any mailboxes in the Exchange organization. Default   20 submissions
MaxConnectionRatePerMinute	The MaxConnectionRatePerMinute parameter specifies the maximum rate at which new inbound connections can be opened to the Hub Transport server or the Edge Transport server. These connections are opened to any Receive connectors that exist on the server. Default   1,200 connections per minute.
MaxOutboundConnections	The MaxOutboundConnections parameter specifies the maximum number of concurrent outbound connections that the Hub Transport server or Edge Transport server can have open at the same time. The outbound connections occur by using the Send connectors that exist on the server. The value that's specified by the MaxOutboundConnections parameter applies to all Send connectors that exist on the transport server. Default   1,000 connections. If you enter a value of unlimited, no limit is imposed on the number of outbound connections. This value can also be configured using the EMC.
MaxPerDomainOutboundConnections	The MaxPerDomainOutboundConnections parameter specifies the maximum number of connections that an Internet-facing Hub Transport server or Edge Transport server can have open to any single remote domain. The outbound connections to remote domains occur by using Send connectors that exist on the server. Default   20 connections per domain If you enter a value of unlimited, no limit is imposed on the number of outbound connections per domain. This value can also be configured using the EMC.
PickupDirectoryMaxMessagesPerMinute	The MaxPerDomainOutboundConnections parameter specifies the rate of message processing for both the Pickup directory and Replay directory. Each directory can independently process message files at the rate that's specified by the PickupDirectoryMaxMessagesPerMinute parameter. Defaults   By default, the Pickup directory can process 100 messages per minute, and the Replay directory can process 100 messages per minute at the same time. The Pickup directory and the Replay directory scan for new message files once every 5 seconds, or 12 times per minute. This 5-second polling interval isn't configurable. This means the maximum number of messages that can be processed during each polling interval is the value that you assign to the PickupDirectoryMaxMessagesPerMinute parameter divided by 12 (PickupDirectoryMaxMessagesPerMinute/12). By default, a maximum of just over eight messages can be processed during each 5-second polling interval.

Throttling Parameters on Send Connectors

The following throttling parameters are available on Send connectors. Use the Send-Connector cmdlet to configure these parameters.

Send connector throttling parameters

Parameter	Description
ConnectionInactivityTimeOut	The ConnectionInactivityTimeOut parameter specifies the maximum time that an open SMTP connection with a destination messaging server can remain idle before the connection is closed. Default   10 minutes.
SmtpMaxMessagesPerConnection	The SmtpMaxMessagesPerConnection parameter specifies the maximum number of messages this Send connector server can send per connection. Default   20 messages

Throttling Parameters on Receive Connectors

You can configure the following throttling parameters on Receive connectors on Exchange 2010 Transport servers to control connection parameters such as inactivity timeouts, maximum number of connections and the number of SMTP protocol errors allowed during a connection. Use the Set-ReceiveConnector cmdlet to configure these parameters.

Receive connector throttling parameters

Parameter	Description
ConnectionInactivityTimeOut	The ConnectionInactivityTimeOut parameter specifies the maximum time that an open SMTP connection with a source messaging server can remain idle before the connection is closed. Default on Hub Transport servers   5 minutes. Default on Edge Transport servers   1 minute.
ConnectionTimeOut	The ConnectionTimeOut parameter specifies the maximum time that an SMTP connection with a source messaging server can remain open, even if the source messaging server is transmitting data. Default on Hub Transport servers   10 minutes Default on Edge Transport servers   5 minutes. The value specified by the ConnectionTimeout parameter must be larger than the value specified by the ConnectionInactivityTimeout parameter.
MaxInboundConnection	The MaxInboundConnection parameter specifies the maximum number of inbound SMTP connections that this Receive connector allows at the same time. Default   5,000
MaxInboundConnectionPercentagePerSource	The MaxInboundConnectionPercentagePerSource parameter specifies the maximum number of SMTP connections that a Receive connector allows at the same time from a single source messaging server. The value is expressed as the percentage of available remaining connections on a Receive connector. The maximum number of connections that are permitted by the Receive connector is defined by the MaxInboundConnection parameter. Default   2 percent
MaxInboundConnectionPerSource	The MaxInboundConnectionPerSource parameter specifies the maximum number of SMTP connections that a Receive connector allows at the same time from a single source messaging server. Default   100 connections
MaxProtocolErrors	The MaxProtocolErrors parameter specifies the maximum number of SMTP protocol errors that a Receive connector allows before the Receive connector closes the connection with the source messaging server. Default   5 errors

Throttling Parameters for the POP3 Service

The following throttling parameters are available for the Microsoft Exchange POP3 service on Client Access servers. Use the Set-POPSettings cmdlet to configure these parameters. For details, see Set Connection Limits for POP3.

POP3 service throttling parameters

Parameter	Description
MaxCommandSize	The MaxCommandSize parameter specifies the maximum size of a single command. The possible values are from 40 through 1024 bytes. Default   40 bytes.
MaxConnectonFromSingleIP	The MaxConnectionFromSingleIP parameter specifies the number of connections that the specified server accepts from a single IP address. The possible values are from 1 through 25,000. Default   2,000 connections
MaxConnections	The MaxConnections parameter specifies the total number of connections that the specified server accepts. This includes authenticated and unauthenticated connections. The possible values are from 1 through 25,000. Default   2,000 connections.
MaxConnectionsPerUser	The MaxConnectionsPerUser parameter specifies the maximum number of connections that the Client Access server accepts from a particular user. The possible values are from 1 through 25,000. Default   16 connections.
PreAuthenticationConnectionTimeOut	The PreAuthenticatedConnectionTimeout parameter specifies the time to wait before closing an idle connection that isn't authenticated. The possible values are from 10 through 3,600 seconds. Default   60 seconds.

Throttling Parameters for the IMAP4 Service

The following throttling parameters are available for the Microsoft Exchange IMAP4 service on Client Access servers. Use the Set-IMAPSettings cmdlet to configure these parameters. For details, see Set Connection Limits for IMAP4.

IMAP4 service throttling parameters

Parameter	Description
AuthenticationConnectionTimeOut	The AuthenticatedConnectionTimeout parameter specifies the period of time to wait before closing an idle authenticated connection. The possible values are from 30 through 86400 seconds. Default   1,800 seconds
MaxCommandSize	The MaxCommandSize parameter specifies the maximum size of a single command. The default size is 40 bytes. The possible values are from 40 through 1024 bytes. Default   40 bytes.
MaxConnectionFromSingleIP	The MaxConnectionFromSingleIP parameter specifies the number of connections that the specified server accepts from a single IP address. The possible values are from 1 through 25,000. Default   2,000 connections
MaxConnections	The MaxConnections parameter specifies the total number of connections that the specified server accepts. This includes authenticated and unauthenticated connections. The possible values are from 1 through 25,000. Default   2,000 connections
MaxConnectionsPerUser	The MaxConnectionsPerUser parameter specifies the maximum number of connections that the Client Access server accepts from a particular user. The possible values are from 1 through 25,000. Default   16 connections.
PreAuthenticatedConnectionTimeOut	The PreAuthenticatedConnectionTimeout parameter specifies the time to wait before closing an idle connection that isn't authenticated. The possible values are from 10 through 3600 seconds. Default   60 seconds

Client Throttling Policies

In Exchange 2010, you can use client throttling policies to manage Client Access server performance by controlling parameters such as the number of concurrent connections for each client access protocol, the percentage of time that a client session can use to run LDAP operations, RPC operations, and client access operations. There's a default client throttling policy that's generally sufficient to manage the load placed on Client Access servers. You can modify the default policy parameters or create custom policies that meet the requirements for your deployment.

Throttling policies are available for the following user groups and access methods:

• Anonymous access

• Cross-premises access (CPA)

• Exchange ActiveSync (EAS)

• Exchange Web Services (EWS)

• IMAP

• POP

• Outlook Web App (OWA)

• RPC Client Access (RCA)

The following throttling settings are available in client throttling policies for each of these user groups (Anonymous access and CPA) and access methods (EAS, EWS, IMAP, OWA, POP, and RCA).

Client throttling policy settings

Throttling setting	Anonymous Access	CPA	EAS	EWS	IMAP	OWA	POP	RCA
Max Concurrency	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Percent Time in AD	Yes	N. A.	Yes	Yes	Yes	Yes	Yes	Yes
Percent Time in CAS	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Percent Time in Mailbox RPC	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes

CPA   Cross-Premises Access

EAS   Exchange ActiveSync

EWS   Exchange Web Services

OWA   Outlook Web App

In addition to these throttling settings based on user groups and access methods, the following throttling settings are available in a client throttling policy.

Client throttling policy parameters

Parameter	Description
CPUStartPercent	The CPUStartPercent parameter specifies the per-process CPU percentage at which users governed by this policy begin to be backed off. Valid values are from 0 through 100. Use $null to turn off CPU percentage-based throttling for this policy.
EASMaxDeviceDeletesPerMonth	The EASMaxDeviceDeletesPerMonth parameter specifies a limit to the number of Exchange ActiveSync partnerships that a user can delete per month. By default, each user can delete a maximum of 20 partnerships per calendar month. When the limit is reached, the partnership deletion attempt fails and an error message is displayed to the user.
EASMaxDevices	The EASMaxDevices parameter specifies a limit to the number of Exchange ActiveSync partnerships that a user can have at one time. By default, each user can create 10 Exchange ActiveSync partnerships with their Exchange account. After users exceed the limit, they must delete one of their existing partnerships before they can create any more new partnerships. An e-mail error message describing the limitation is sent to the user when the limit is exceeded. Also, an event is logged in the Application log when a user exceeds the limit.
EWSFastSearchTimeOutInSeconds	The EWSFastSearchTimeoutInSeconds parameter specifies the amount of time that searches made using Exchange Web Services continue before they time out. If the search takes more than the time indicated by the policy value, the search stops and an error is returned. The default value of this setting is 60 seconds.
EWSFindCountLimit	The EWSFindCountLimit parameter specifies the maximum result size of FindItem or FindFolder calls that can exist in memory on the Client Access server at the same time for this user in this current process. If an attempt is made to find more items or folders than your policy limit allows, an error is returned. However, the limit isn't strictly enforced if the call is made within the context of an indexed page view. Specifically, in this scenario, the search results are truncated to include the number of items and folders that fit within the policy limit. You can then continue paging into your results set via further FindItem or FindFolder calls.
EWSMaxSubscriptions	The EWSMaxSubscriptions parameter specifies the maximum number of active push and pull subscriptions that a user can have on a specific Client Access server at the same time. If a user tries to create more subscriptions than the configured maximum, the subscription fails, and an event is logged in Event Viewer.
ExchangeMaxCmdlets	The ExchangeMaxCmdlets parameter specifies the number of cmdlets that can be run within a specific time period before their execution is slowed down. The value specified by this parameter should be less than the value specified by the PowerShellMaxCmdlets parameter. The time period used for this limit is specified by the PowerShellMaxCmdletsTimePeriod parameter. We recommend that you set values for both parameters at the same time.
ForwardeeLimit	The ForwardeeLimit parameter specifies the limits for the number of recipients that can be configured in Inbox Rules when using the forward or redirect action. This parameter doesn't limit the number of messages that can be forwarded or redirected to the recipients that are configured.
MessageRateLimit	The MessageRateLimit parameter specifies the number of messages per minute that can be submitted to transport. For messages submitted through the Mailbox server role (Outlook Web App, Exchange ActiveSync, or Exchange Web Services), this results in the deferral of messages until the quota for the user is available. Specifically, messages appear in the Outbox or Drafts folder for longer periods of time when users submit messages at a rate greater than the MessageRateLimit parameter. For POP or IMAP clients submitting messages directly to transport using SMTP, clients receive a transient error if they submit at a rate that exceeds the MessageRateLimit parameter. Exchange tries to connect and send the messages at a later time.
PowerShellMaxCmdletQueueDepth	The PowerShellMaxCmdletQueueDepth parameter specifies the number of operations allowed to be run by the user. This value directly affects the behavior of the PowerShellMaxCmdlets and PowerShellMaxConcurrency parameters. For example, the PowerShellMaxConcurrency parameter consumes at least two operations defined by the PowerShellMaxCmdletQueueDepth parameter but additional operations are also consumed by per cmdlet execution. The number of operations depends on the cmdlets that are run. We recommend that the value for the PowerShellMaxCmdletQueueDepth parameter be at least three times larger than the value of the PowerShellMaxConcurrency parameter. This parameter won't affect Exchange Control Panel operations or Exchange Web Services operations.
PowerShellMaxCmdlets	The PowerShellMaxCmdlets parameter specifies the number of cmdlets that can be run within a specific time period before their execution is stopped. The value specified by this parameter should be more than the value specified by the ExchangeMaxCmdlets parameter. The time period used for this limit is specified by the PowerShellMaxCmdletsTimePeriod parameter. Both values should be set at the same time.
PowerShellMaxCmdletsTimePeriod	The PowerShellMaxCmdletsTimePeriod parameter specifies the time period, in seconds, that the throttling policy uses to determine whether the number of cmdlets being run exceeds the limits specified by the PowerShellMaxCmdlets and ExchangeMaxCmdlets parameters.
PowerShellMaxConcurrency	The PowerShellMaxConcurrency parameter specifies different information depending on context: In the context of Remote PowerShell, the PowerShellMaxConcurrency parameter specifies the maximum number of Remote PowerShell sessions that a Remote PowerShell user can have open at the same time. In the context of Exchange Web Services, the PowerShellMaxConcurrency parameter specifies the number of concurrent cmdlet executions that a user can have at the same time. This parameter value doesn't necessarily correlate to the number of browsers opened by the user
RecipientRateLimit	The RecipientRateLimit parameter specifies the limits on the number of recipients that a user can address in a 24-hour period.

For more details about Exchange 2010 throttling policies, see Understanding Client Throttling Policies.

Role-Based Access Control

Role-Based Access Control (RBAC) is the new permissions model in Exchange 2010 that allows you to control, at both broad and granular levels, what administrators and users can do. With RBAC, it's no longer required to modify Access Control Lists (ACLs) on Active Directory objects such as Organizational Units and containers to allow granular delegation of permissions to groups such as helpdesk operators or for functions such as recipient management. Active Directory

For more details, see Understanding Role Based Access Control. For a list of default RBAC management roles included in Exchange 2010, see Built-in Management Roles. For a list of default role groups, see Built-in Role Groups.

Role groups created by Exchange 2010 Setup or by you are created in Active Directory as universal security groups in the Microsoft Exchange Security Groups OU. You can add members to a role group by using the New-RoleGroupMember cmdlet or by using the Exchange Control Panel (ECP). When you add a member to a role group, the user or group is added to the corresponding Active Directory security group. You can use a Restricted Group policy to restrict membership for critical RBAC role groups such as Discovery Management. When you implement a Restricted Group policy, the group membership is monitored by Active Directory domain controllers and any users not included in the policy are automatically removed.

Important

If you use Restricted Groups to restrict group membership for RBAC role groups, any changes you make to a role group using Exchange 2010 tools must also be made in the Restricted Group policy in Active Directory. For details, see Group Policy Security Settings.

Active Directory

Exchange Server stores configuration data in the Configuration partition and recipient data in the Domain partition of Active Directory Domain Services (AD DS). For details about permissions required to set up an Exchange 2010 organization, see Exchange 2010 Deployment Permissions Reference. Communication with Active Directory domain controllers is secured by using Kerberos authentication and encryption.

Exchange 2010 provides a new authorization layer inside Exchange, known as Role Based Access Control (RBAC), instead of relying on applying access control entries (ACEs) for every account that requires the appropriate permissions. In earlier versions of Microsoft Exchange, Exchange Setup relied on ACEs within Active Directory for Exchange administrators to be able to manage objects within the domain partition. Exchange administrators are granted the ability to perform certain operations within a specific scope through RBAC. The Exchange server runs the authorized actions on behalf of the administrator or users by using the permissions granted within Active Directory through the Exchange Windows Permissions and Exchange Trusted Subsystem security groups. For more information on RBAC, see Understanding Role Based Access Control.

In Exchange 2010, /PrepapareDomain doesn't apply any ACEs for the Exchange Windows Permissions universal security group to the AdminSDHolder container in Active Directory. If /PrepareDomain detects any ACEs granted to the Exchange Windows Permissions universal security group, the ACEs are removed. This has the following implications:

• Members of the Exchange Windows Permissions universal security group can't modify membership of protected security groups such as Enterprise Admins and Domain Admins. This has the following implications.

• Members of the Exchange Windows Permissions universal security group can't force password reset of an account protected by the AdminSDHolder.

• Members of the Exchange Windows Permissions universal security group can't alter the permissions of any group or account protected by the AdminSDHolder.

As a best practice, we recommend that you don't mailbox-enable accounts protected by the AdminSDHolder and do maintain separate accounts for Active Directory administrators: one account for Active Directory administration, and one account for regular day-to-day use, including e-mail. For details, see the following topics:

• Description and Update of the Active Directory AdminSDHolder Object

• Exchange 2010 and Resolution of the AdminSDHolder Elevation Issue

Exchange Server Accounts

Exchange 2010 Setup creates a new organizational unit (OU) in the root domain called Microsoft Exchange Security Groups. The following table shows the new universal security groups.

Microsoft Exchange security groups

Security group	Description
Exchange All Hosted Organizations	This group contains all the Exchange Hosted Organization Mailboxes groups. It's used for applying Password Setting Objects to all hosted mailboxes. This group shouldn't be deleted.
Exchange Servers	This group contains all the Exchange servers. This group should not be deleted. We strongly discourage making any membership changes to this group.
Exchange Trusted Subsystem	This group contains Exchange servers Exchange run Exchange cmdlets on behalf of users via Management service. Its members will have permission to read and modify all Exchange configuration, and also user accounts and groups. This group shouldn't be deleted.
Exchange Windows Permissions	This group contains Exchange servers that run Exchange cmdlets on behalf of users via Management service. Its members will have permission to read and modify all Windows accounts and groups. This group should not be deleted. We strongly discourage making any membership changes to this group, and suggest monitoring group membership.
ExchangeLegacyInterop	This group is for interoperability with Exchange 2003 servers within the same forest. This group should not be deleted.

In addition to these security groups, setup also creates the following security groups that correspond to RBAC role groups with the same name.

Security groups that correspond to RBAC role groups

Security group	RBAC role group
Delegated Setup	Delegated Setup
Discovery Management	Discovery Management
Help Desk	Help Desk
Hygiene Management	Hygiene Management
Organization Management	Organization Management
Public Folder Management	Public Folder Management
Recipient Management	Recipient Management
Records Management	Records Management
Server Management	Server Management
UM Management	UM Management
View-Only Organization Management	View-Only Organization Management

Also, when you create a new role group, Exchange 2010 creates a security group with the same name as the role group. For details, see the following topics:

• Built-in Role Groups

• Create a Role Group

Users are added or removed from these security groups when you add or remove users from role groups using the Add-RoleGroupMember or Remove-RoleGroupMember cmdlets, or by using the Role Based Access Control (RBAC) User Editor in the ECP.

File system

Exchange 2010 Setup creates directories with minimum permissions required for Exchange 2010 to function. We don't recommend any additional hardening of permissions to the default access control lists (ACLs) on directories created by setup.

Services

Exchange 2010 Setup doesn't disable any Windows services by default. The following table lists services enabled by default on each server role. Only the services required for operation of a particular Exchange 2010 server role are enabled by default.

Services installed by Exchange Setup

Service name	Service short name	Security context	Description and dependencies	Default startup type	Server roles	Required (R) or optional (O)
Microsoft Exchange Active Directory Topology	MSExchangeADTopology	Local System	Provides Active Directory topology information to Exchange services. If this service is stopped, most Exchange services cannot start. This service has no dependencies.	Automatic	Mailbox, Hub Transport, Client Access, Unified Messaging	R
Microsoft Exchange ADAM	ADAM_MSExchange	Network Service	Stores configuration data and recipient data on the Edge Transport server. This service represents the named instance of Active Directory Lightweight Directory Service (AD LDS) that's automatically created by Setup during Edge Transport server installation. This service depends on the COM+ Event System service.	Automatic	Edge Transport	R
Microsoft Exchange Address Book	MSExchangeAB	Local System	Manages client address book connections. This service depends on the Microsoft Exchange Active Directory Topology service.	Automatic	Client Access	R
Microsoft Exchange Anti-spam Update	MSExchangeAntispamUpdate	Local System	Provides the Microsoft Forefront Protection 2010 for Exchange Server anti-spam update service. On Hub Transport servers, this service depends on the Microsoft Exchange Active Directory Topology service. On Edge Transport servers, this service depends on the Microsoft Exchange ADAM service.	Automatic	Hub Transport, Edge Transport	O
Microsoft Exchange Credential Service	MSExchangeEdgeCredential	Local System	Monitors credential changes in AD LDS and installs the changes on the Edge Transport server. This service depends on the Microsoft Exchange ADAM service.	Automatic	Edge Transport	R
Microsoft Exchange EdgeSync	MSExchangeEdgeSync	Local System	Connects to an AD LDS instance on subscribed Edge Transport servers over a secure LDAP channel to synchronize data between a Hub Transport server and an Edge Transport server. This service depends on the Microsoft Exchange Active Directory Topology service. If Edge Subscription isn't configured, this service can be disabled.	Automatic	Hub Transport	O
Microsoft Exchange File Distribution	MSExchangeFDS	Local System	Distributes offline address book (OAB) and custom Unified Messaging prompts. This service depends on the Microsoft Exchange Active Directory Topology and Workstation services.	Automatic	Client Access, Unified Messaging	R
Microsoft Exchange Forms-Based Authentication	MSExchangeFBA	Local System	Provides forms-based authentication to Outlook Web App and the Exchange Control Panel. If this service is stopped, Outlook Web App and the Exchange Control Panel won't authenticate users. This service has no dependencies.	Automatic	Client Access	R
Microsoft Exchange IMAP4	MSExchangeIMAP4	Network Service	Provides IMAP4 service to clients. If this service is stopped, clients won't be able to connect to this computer using the IMAP4 protocol. This service depends on the Microsoft Exchange Active Directory Topology service.	Manual	Client Access	O
Microsoft Exchange Information Store	MSExchangeIS	Local System	Manages the Exchange Information Store. This includes mailbox databases and public folder databases. If this service is stopped, mailbox databases and public folder databases on this computer are unavailable. If this service is disabled, any services that explicitly depend on it will fail to start. This service is dependent on the RPC, Server, Windows Event Log, and Workstation services.	Automatic	Mailbox	R
Microsoft Exchange Mail Submission Service	MSExchangeMailSubmission	Local System	Submits messages from the Mailbox server to Exchange 2010 Hub Transport servers. This service depends on the Microsoft Exchange Active Directory Topology service.	Automatic	Mailbox	R
Microsoft Exchange Mailbox Assistants	MSExchangeMailboxAssistants	Local System	Performs background processing of mailboxes in the Exchange store. This service depends on the Microsoft Exchange Active Directory Topology service.	Automatic	Mailbox	R
Microsoft Exchange Mailbox Replication Service	MSExchangeMailboxReplication	Local System	Processes mailbox moves and move requests. This service depends on the Microsoft Exchange Active Directory Topology and Net.Tcp Port Sharing service.	Automatic	Client Access	O
Microsoft Exchange Monitoring	MSExchangeMonitoring	Local System	Allows applications to call the Exchange diagnostic cmdlets. This service has no dependencies.	Manual	All	O
Microsoft Exchange POP3	MSExchangePOP3	Network Service	Provides POP3 service to clients. If this service is stopped, clients can't connect to this computer using the POP3 protocol. This service depends on the Microsoft Exchange Active Directory Topology service.	Manual	Client Access	O
Microsoft Exchange Protected Service Host	MSExchangeProtectedServiceHost	Local System	Provides a host for several Exchange services that must be protected from other services. This service depends on the Microsoft Exchange Active Directory Topology service.	Automatic	Hub Transport, Client Access	R
Microsoft Exchange Replication Service	MSExchangeRepl	Local System	Provides replication functionality for mailbox databases on Mailbox servers in a database availability group (DAG). This service depends on the Microsoft Exchange Active Directory Topology service.	Automatic	Mailbox	O
Microsoft Exchange RPC Client Access	MSExchangeRPC	Network Service	Manages client RPC connections for Exchange. This service depends on the Microsoft Exchange Active Directory Topology service.	Automatic	Mailbox, Client Access	O (Mailbox), R (Client Access)
Microsoft Exchange Search Indexer	MSExchangeSearch	Local System	Drives indexing of mailbox content, which improves the performance of content search. This service depends on the Microsoft Exchange Active Directory Topology and Microsoft Search (Exchange Server) services.	Automatic	Mailbox	O
Microsoft Exchange Server Extension for Windows Server Backup	WSBExchange	Local System	Enables Windows Server Backup users to back up and recover application data for Microsoft Exchange. This service has no dependencies.	Manual	Mailbox	O
Microsoft Exchange Service Host	MSExchangeServiceHost	Local System	Provides a host for several Exchange services. On internal server roles, this service depends on the Microsoft Exchange Active Directory Topology service. On Edge Transport servers, this service depends on the Microsoft Exchange ADAM service.	Automatic	All	R
Microsoft Exchange Speech Engine	MSSpeechService	Network Service	Provides speech processing services for Unified Messaging. This service depends on the Windows Management Instrumentation (WMI) service.	Automatic	Unified Messaging	R
Microsoft Exchange System Attendant	MSExchangeSA	Local System	Forwards directory lookups to a global catalog server for legacy Outlook clients, generates e-mail addresses and OABs, updates free/busy information for legacy clients, and maintains permissions and group memberships for the server. If this service is disabled, any services that explicitly depend on it will fail to start. This service is dependent on the RPC, Server, Windows Event Log, and Workstation services.	Automatic	Mailbox	R
Microsoft Exchange Throttling	MSExchangeThrottling	Network Service	Limits the rate of user operations. This service depends on the Microsoft Exchange Active Directory Topology service.	Automatic	Mailbox	R
Microsoft Exchange Transport	MSExchangeTransport	Network Service	Provides SMTP server and transport stack. On Hub Transport servers, this service depends on the Microsoft Exchange Active Directory Topology service. On Edge Transport servers, this service depends on the Microsoft Exchange ADAM service.	Automatic	Hub Transport, Edge Transport	R
Microsoft Exchange Transport Log Search	MSExchangeTransportLogSearch	Local System	Provides remote search capability for Microsoft Exchange Transport log files. On Hub Transport servers, this service depends on the Microsoft Exchange Active Directory Topology service. On Edge Transport servers, this service depends on the Microsoft Exchange ADAM service.	Automatic	Hub Transport, Mailbox, Edge Transport	O
Microsoft Exchange Unified Messaging	MSExchangeUM	Local System	Enables Microsoft Exchange Unified Messaging features. This allows voice and fax messages to be stored in Exchange and gives users telephone access to e-mail, voice mail, calendar, contacts, or an auto attendant. If this service is stopped, Unified Messaging isn't available. This service depends on the Microsoft Exchange Active Directory Topology and the Microsoft Exchange Speech Engine service.	Automatic	Unified Messaging	R
Microsoft Search (Exchange Server)	msftesql-Exchange	Local System	This is a Microsoft Exchange-customized version of Microsoft Search. This service is dependent on the RPC service.	Manual	Hub Transport, Mailbox	O

Certificates

Exchange 2010 Setup creates self-signed certificates to secure communication over different protocols such as HTTP, SMTP, POP3 and IMAP4. The self-signed certificates created by Setup are valid for five years. This ensures that the self-signed certificates don't have to be renewed for a significant part of an Exchange 2010 deployment and messaging services aren't affected by the expiration of self-signed certificates.

For external client access mechanisms and protocols, such as Outlook Web App, POP3, IMAP4, Outlook Anywhere, and AutoDiscover, we recommend that you:

• Use certificates signed by a commercial certification authority (CA) that's trusted by clients accessing those services.

• Use the New Exchange Certificate wizard or the New-ExchangeCertificate cmdlet to create certificate signing requests for commercial CAs. Certificate requests generated using these tools ensure that all Exchange certificate requirements are met.

• Consider the certificate requirements for each protocol or service for which you want to allow external client access.

  • On Client Access servers, certificates are used to protect HTTP traffic (Outlook Anywhere, Outlook Web App, AutoDiscover, Exchange ActiveSync, and Exchange Web Services) by using Secure Sockets Layer, and POP3 and IMAP4 traffic by using SSL or Transport Layer Security (TLS). For details, see Managing SSL for a Client Access Server.

  • On transport servers, certificates are used to protect SMTP traffic by using TLS. For details, see Understanding TLS Certificates.

  • On Unified Messaging servers, certificates are used to protect Voice over Internet Protocol (VoIP) traffic. For details, see Understanding Unified Messaging VoIP Security.

  • For Federation, certificates are used to encrypt SAML tokens exchanged with the Microsoft Federation Gateway (MFG) and with federated partner organizations. For details, see Understanding Federation.

• Monitor certificate validity dates and renew certificates from CAs in a timely manner to avoid service disruption.

• When storing certificates exported with the associated private key, protect the exported file by using appropriate access controls on the folder/file where it's stored. Depending on your organization's security requirements, consider enabling auditing of file access for folders where certificate files with private keys are stored.

NTLM Considerations

The NTLM protocol is significantly less secure than the Kerberos protocol. In Exchange 2010, the POP3 and IMAP4 protocols don't support NTLM authentication when SecureLogin is specified as the LoginType. For details, see Configuring Authentication for POP3 and IMAP4. Exchange 2010 services that use Windows Integrated Authentication can use either NTLM or Kerberos protocols. Kerberos is used for Client Access server communication to an Exchange 2010 Mailbox server, and between Client Access servers for Outlook Web App, Exchange ActiveSync, and Exchange Web Services. For details about services that use NTLM to authenticate, see Exchange Network Port Reference.

Dual Factor Authentication

Dual factor authentication mechanisms use another authenticator in addition to the user's logon credentials (username and password), such as randomly generated tokens, or a digital certificate on a smartcard along with a PIN. Many organizations deploy dual factor authentication to allow secure access to the organization's network.

Exchange 2010 doesn't include native support for dual factor authentication. Exchange 2010 uses Internet Information Server (IIS) 7 for client access through HTTP (AutoDiscover, Outlook Web App, Outlook Anywhere, Exchange ActiveSync, and Exchange Web Services). Many dual factor authentication products that integrate with IIS are available from partners and third parties, and work with Exchange client access services such as Outlook Web App. Before deploying dual factor authentication products for Exchange services, we recommend that you test them adequately to ensure they meet your organization's security requirements and provide the functionality you require.

Federation

Exchange 2010 introduces new federation features to enable secure collaboration between federated Exchange organizations. Exchange 2010 organizations can create a federation trust with the Microsoft Federation Gateway, and then establish organization relationships with other federated organizations to share availability information and Calendars. Organizations can also allow users to share their availability information, Calendar and Contacts with users in external federated organizations by using Sharing Policies. For more details about Federation Trusts and Federated Sharing, see Understanding Federation and Understanding Federated Delegation.

After you establish a Federation Trust with MFG, sharing between two federated organizations doesn't occur unless you create an Organization Relationship. By default, however, sharing between your users and users in external federated organizations is enabled by using the Default Sharing Policy assigned to users. The policy allows Calendar sharing with free/busy information only to users in all external federated organizations. If you don't want to allow users to share their calendar and free/busy information with users in all external federated domains, you must disable the Default Sharing Policy or change the domain name specified in the policy to only those domains you want to allow sharing with. You must make this change before you create a Federation Trust with MFG. For more details, see Disable a Sharing Policy and Configure Sharing Policy Properties.

You can disable all Federation features for an organization, including Federated Delegation, by removing the organization's Federation Trust with MFG. For more details, see Remove a Federation Trust.

Secure/Multipurpose Internet Mail Extensions (S/MIME)

Secure/Multipurpose Internet Mail Extensions (S/MIME) is a standard for public key encryption and signing of MIME data which provides authentication, message integrity, nonrepudiation, and data privacy for messaging data. Users can sign or encrypt messages, or both, using S/MIME certificates. For more information about S/MIME, see Understanding S/MIME.

S/MIME is a client-side technology without any interoperability requirements for e-mail servers. From a message transfer perspective, S/MIME signed or encrypted messages are transferred no differently than clear text (not encrypted) messages. Actual rendering of message is done on the client-side after certificate and message validation checks. For Outlook Web App, S/MIME support is provided by using an ActiveX control. Although Outlook Web App supports most popular browsers such as Microsoft Internet Explorer, Mozilla FireFox and Safari, ActiveX controls are an Internet Explorer feature. Outlook Web App users using other browsers can't access S/MIME features and may have to use another e-mail client which supports S/MIME. For more details about S/MIME support in Outlook Web App, see Outlook Web App and S/MIME.

For more details about S/MIME support in Outlook, see Overview of certificates and cryptographic e-mail messaging in Outlook.

Whereas S/MIME offers security benefits to an organization, when you evaluate the technology, you should consider the following:

• S/MIME encrypted messages are opaque to your organization. Messaging security software such as antivirus and anti-spam can't inspect message content, including message body and any attachments.

• Because message content and attachments are encrypted, your organization's messaging policies, including transport rules, can't be applied to S/MIME-encrypted messages.

• Modifying S/MIME-signed messages to comply with your organization's messaging policies, for example to apply a disclaimer or personalized signature, invalidates the message.

• Encrypted messaging content can't be inspected for any content violations, and your organization can't protect sensitive information. This includes any personally identifiable information (PII), from leaving the organization.

• S/MIME-encrypted messages can't be indexed by Exchange Search and are therefore not searchable by discovery.

• To meet local regulations or discovery requirements during litigation, your organization may be required to produce copies of all encrypted messages that are not encrypted.

Exchange 2010 offers Information Rights Management (IRM) features that allow your organization to apply persistent protection to sensitive messaging content so only specified recipients can access IRM-protected messages. Your organization can also implement controls on how such content is used after it's delivered to recipients. For example, you can prevent messages from being printed, replied to, or forwarded inside or outside the organization. Also, your organization can still decrypt the IRM-protected content for scanning by antivirus and anti-spam software and other transport agents, applying messaging policies using transport rules, and enable archiving and discovery of IRM-protected messages. IRM features are also available in all web browsers supported by Outlook Web App and in Windows Mobile devices. For more details about IRM, see Understanding Information Rights Management.

Server Role Considerations

This section lists security-related considerations for the Exchange 2010 server role.

Mailbox Server Considerations

In Exchange 2010, architectural changes have been made to the Exchange store and connectivity from MAPI clients such as Outlook. MAPI clients connect to the Client Access Server, isolating the Mailbox server from client traffic. Mailbox servers communicate only with Client Access servers that use RPCSec, and with Active Directory Domain Services (AD DS) servers in your organization. Mailbox servers don't require Internet connectivity.

Storage

Storage is a critical component of Mailbox servers. You must plan your Mailbox server storage sub-system to ensure satisfactory performance and adequate storage space is available for your deployment. For more details about planning for Mailbox server storage, see Mailbox Server Storage Design.

After Mailbox server deployment, you should monitor the following the following:

• Availability of storage sub-system.

• Availability of sufficient free disk space on volumes that contain the mailbox database and transaction logs. A mailbox or Public Folder database is unmounted when the volume storing the database or transaction logs for it run out of free disk space.

You can use Microsoft Federation Gateway Systems Center Operations Manager to monitor storage availability and disk free space. For more details, see Systems Center Operations Manager 2007.

When planning for and monitoring storage, if you plan to use the following features, you must consider their storage requirements:

• Journaling   When you use journaling to keep messages for long-term archival, depending on whether you use standard (per-mailbox database) or premium journaling (journal rules), messages sent to and from all recipients in a mailbox database or the recipients specified in a journal rule are delivered in a journal report to the journaling mailbox or recipient specified. The result can be a large number of journal reports delivered to a journaling mailbox. When planning storage for Mailbox servers, you must consider journaling mailbox sizes. You can control journaling mailbox sizes by configuring sufficient mailbox quotas for a journaling mailbox. For more details about journaling and mailbox quotas, see the following topics:

  • Understanding Journaling

  • Configure Storage Quotas for a Mailbox

• Litigation Hold   When you place a mailbox on litigation hold, items deleted by the user by using the Recover Deleted Items functionality in Outlook and Outlook Web App and messages deleted by automated processes such as MRM are retained till litigation hold is removed. In Exchange 2010, the Recoverable Items warning quota and Recoverable Items quota are set to 20 GB and 30 GB. For more details, see the following topics:

  • Understanding Litigation Hold

  • Understanding Recoverable Items

High Availability

High Availability of Mailbox servers is critical in ensuring messaging service availability. Exchange 2010 includes Database Availability Groups (DAGs) for high availability of Mailbox servers. DAGs can provide availability when your Exchange deployment experiences a failure of the storage sub-system, the server, or network connectivity, or an outage of a whole datacenter. For more details about planning and implementing a highly available Exchange 2010 deployment, see High Availability and Site Resilience.

By default, in Exchange 2010, replication (log shipping) traffic between DAG members located in different Active Directory sites is encrypted. You can encrypt replication traffic between servers in the same Active Directory site by setting the NetworkEncryption property of the DAG to Enabled. Use the Set-DatabaseAvailabilityGroup cmdlet to modify this property for a DAG.

Replication occurs over a single TCP port, by default TCP port 64327. You can modify the port used for replication. For details, see Configure Database Availability Group Properties.

Parameters for high availability

Parameter	Description
NetworkEncryption	The NetworkEncryption parameter specifies whether network encryption is enabled. Valid values include: Disabled   disabled on all networks Enabled   enabled on all networks InterSubnetOnly   Enabled for inter-subnet communication only SeedOnly   enabled only for seeding Default   InterSubnetOnly
ReplicationPort	The ReplicationPort parameter specifies a Transmission Control Protocol (TCP) port for replication (log shipping and seeding) activity. Default   If this parameter isn't specified, the default port for replication is TCP 64327.

Mailbox Permissions and Access

By default, Exchange 2010 doesn't allow administrators to access mailboxes. If your organization uses applications or services that require access to a mailbox, you must assign appropriate mailbox permissions to accounts used by such applications or services. We recommend that you don't configure such applications or services to use administrator credentials.

Although all mailboxes can potentially contain sensitive information valuable to an organization, the following mailboxes deserve special attention from a security perspective, and permissions to access these mailboxes must be controlled and monitored to meet your organization's security requirements.

• Discovery mailboxes   Discovery mailboxes are used by the Exchange 2010 Multi-Mailbox Search feature. This allows discovery managers who are members of the Discovery Management role group to search messages in all mailboxes in an Exchange 2010 organization. Messages returned by a discovery search are copied to the specified Discovery mailbox. Exchange 2010 Setup creates a default Discovery Search Mailbox. For more details, see Understanding Multi-Mailbox Search.

• Journaling mailboxes   When you configure journaling for a mailbox database or create Journal Rules to journal messages to and from specified recipients, journal reports are delivered to the specified journaling mailbox. For more details, see the following topics:

  • Understanding Journaling

  • Create and Configure a Journaling Mailbox

In addition to protecting these mailboxes, notice that an administrator can use transport rules to inspect message content and also deliver a copy of the message to another recipient, even as a Bcc recipient. The permissions required to manage transport rules are listed in the Transport rules entry in the Messaging Policy and Compliance Permissions topic. We recommend that you use adequate controls to monitor and control the creation and modification of transport rules and that you also regularly audit transport rule actions for all rules.

Client Access Server Considerations

In Exchange 2010, the following clients connect to Client Access servers to access mailboxes:

• Outlook clients using MAPI

• Outlook clients using Outlook Anywhere

• Web browsers using Outlook Web App,

• Mobile devices using Exchange ActiveSync

• POP3 & IMAP4 clients

• Applications that use Exchange Web Services (EWS)

By default, these client access methods are secured by using encrypted data paths. Also by default, Outlook clients connecting to a Client Access server using MAPI use RPC encryption. Outlook Web App, Outlook Anywhere and Exchange ActiveSync access is secured by using Secure Sockets Layer (SSL).

For external client access, you must obtain and install certificates signed by a certification authority (CA) trusted by the client. For more details, see Managing SSL for a Client Access Server.

By default, POP3 and IMAP4 services are disabled on Exchange 2010 Client Access servers. If you enable them, we recommend that you use Transport Layer Security (TLS) or Secure Sockets Layer (SSL) to help secure communication by using these protocols. For more details, see the following topics:

• Understanding POP3 and IMAP4

• Configuring TLS and SSL for POP3 and IMAP4 Access

we recommend that you use appropriate firewalls and access controls when you publish Client Access servers for external access. Microsoft Forefront Threat Management Gateway (TMG) 2010 includes publishing wizards to easily and securely publish Exchange 2010 Client Access servers for external access. For more details, see Forefront Threat Management Gateway (TMG) 2010.

Important

Locating Client Access servers on perimeter networks isn't supported.

On Client Access servers, Internet Information Server (IIS) is used to provide HTTP protocol access to services such as Outlook Web App, Exchange ActiveSync, Outlook Anywhere, AutoDiscover, Exchange Control Panel (ECP), Exchange Web Services and Offline Address Book (OAB). Remote PowerShell also uses IIS, And all RPS requests, including requests by the Exchange Management Console (EMC), are logged in IIS logs. IIS logs can grow to consume a large amount of disk space. IIS, a Windows Server component, doesn't include a mechanism to clear older logs based on the size of the directory in which the log files reside. As a best practice, IIS logs should be moved to a non-system volume, so growth of log files doesn't result in the system volume running out of disk space, which can cause a service outage. You should monitor log file growth and implement a mechanism to manually archive or delete logs as required. For details, see Configuring Logging in IIS 7.

Transport Server Considerations

Exchange 2010 offers two transport server roles that are designed for different purposes.

• Edge Transport   The Edge Transport server role is a non-domain joined transport server, usually located in perimeter networks, that transfers messages between your Exchange organization and external SMTP hosts. Although designed for perimeter networks, you can also locate Edge Transport servers on the internal network and join the server to an Active Directory domain as a member server.

• Hub Transport   The Hub Transport server role transfers messages within the organization, including messages between Exchange servers, messages from SMTP clients such as users using POP3 and IMAP4, and application servers and devices.

By default, in Exchange 2010, SMTP communication is secured using TLS.

SMTP communication between Hub Transport servers   Hub Transport servers in an Exchange organization use TLS to help secure SMTP communication within the organization. We recommend that you keep TLS enabled on Hub Transport servers. In Exchange 2010, organizations using non-Exchange devices or appliances to perform TLS encryption can offload TLS from Hub Transport servers to such appliances. For more details, see Disabling TLS Between Active Directory Sites to Support WAN Optimization.

SMTP communication between Hub Transport and Edge Transport servers   All traffic between Hub Transport servers and Edge Transport servers is authenticated and encrypted. The underlying mechanism for authentication and encryption is mutual TLS. Instead of using X.509 validation to validate certificates, Exchange 2010 uses direct trust to authenticate certificates. Direct trust means the presence of the certificate in Active Directory or Active Directory Lightweight Directory Services (AD LDS) validates the certificate. Active Directory is considered a trusted storage mechanism. When direct trust is used, it doesn't matter whether the certificate is self-signed or signed by a certification authority (CA).When you subscribe an Edge Transport server to an Active Directory site, the Edge Subscription publishes the Edge Transport server's certificate in Active Directory. Hub Transport servers consider the published certificate valid. The Microsoft EdgeSync service updates AD LDS on Edge Transport servers that have Hub Transport server certificates, which are considered valid by the Edge Transport server.

SMTP communication between Edge Transport servers and external hosts   In Exchange 2010, SMTP communication between Edge Transport servers and anonymous external hosts is secured by default using opportunistic TLS. You don't require a certificate issued by a trusted CA and no configuration steps are necessary. Receive Connectors offer TLS negotiation for inbound SMTP connections. Send Connectors also tries TLS negotiation for all outbound SMTP connections. Opportunistic TLS doesn't perform certificate validation, allowing the use of self-signed certificates. For details, see TLS Functionality and Related Terminology in Exchange 2010.

Note

By default, Hub Transport servers can't communicate with external SMTP hosts as no Receive Connectors exist on Hub Transport servers that allow anonymous hosts to communicate. You can configure Hub Transport servers to communicate with anonymous hosts. For details, see Configure Internet Mail Flow Directly Through a Hub Transport Server. We don't recommend this topology because it increases security risks by exposing to the Internet the Exchange 2010 server and all roles installed on that server. We recommend that you implement a perimeter network-based SMTP gateway, such as the Edge Transport server, instead.

SMTP communication between Hub or Edge Transport servers and smart hosts   In Exchange 2010, you can configure a Send Connector to route mail for remote domains, including Internet mail, to a SMTP gateway generally residing on the perimeter network. Although it's possible to create a Send Connector to route e-mail to a smart host without using any authentication, we recommend that you use appropriate authentication for such connectors. If you use Basic authentication, we recommend using Basic authentication over TLS. If you select the externally secured option, it's assumed that authentication is performed using a non-Exchange mechanism such as IPsec. When you configure the connector with the address of a smart host, you can use either the smart host's IP address or its fqdn. We recommend using the smarthost's IP address because it offers protection against DNS poisoning, versus the convenience of using the FQDN.

Using Domain Security for SMTP communication with partners    In Exchange 2010, you can use Domain Security to help secure message communication paths with partner domains. Domain Security uses mutual TLS to provide session-based encryption and authentication. For mutual TLS authentication, the source and destination hosts verify the connection by performing X.509 certificate validation. Transport servers communicating with partner domains configured for Domain Security require a certificate signed by a trusted third party or an internal certification authority. If using an internal CA, the certificate revocation list (CRL) must be published and reachable by the partner host. For details, see the following topics:

• Understanding Domain Security

• White Paper: Domain Security in Exchange 2007

Exchange 2010 uses the default SMTP port (TCP port 25) for SMTP communication. Exchange Setup creates the required firewall rules in Windows Firewall with Advanced Security to allow communication over default ports. If you specify a different port for a connector, Exchange doesn't modify firewall rules or automatically create a new rule to allow communication over the nondefault port. You must manually modify firewall configuration to allow communication over nondefault ports. When you configure a receive connector for a nondefault port, the SMTP clients submitting messages to the connector must also be configured to use the nondefault port.

In Exchange 2010, you can locate the Hub Transport server role on an Exchange 2010 Mailbox server. This includes a Mailbox server that's a member of a Database Availability Group (DAG). We recommend that you don't locate the Hub Transport server role on a Mailbox server, especially in topologies where no Edge Transport servers are deployed, in order to isolate Mailbox servers from the Internet. You can locate Hub Transport server role on Client Access servers. You must follow the sizing guidelines for each server role when collocating server roles on the same server.

When specifying a smart host for a Send Connector on a Hub Transport or an Edge Transport server, we recommend that you use IP addresses instead of the fully qualified domain name (FQDN) of a smart host, to protect from DNS poisoning and spoofing. This also minimizes the effect of any DNS outages on the transport infrastructure. DNS servers used in perimeter networks must be used only for outbound resolution. The perimeter DNS servers may contain records for Hub Transport servers. You can also use Hosts files on Edge Transport servers to avoid creating records for Hub Transport servers on DNS servers located in perimeter networks.

In addition to the steps discussed in this section, you should consider using sufficient message size restrictions on connectors, and message throttling settings on transport servers. For more details, see the following topics:

• Understanding Message Size Limits

• Understanding Message Throttling

Unified Messaging Considerations

When planning to deploy Unified Messaging (UM) server role, you must consider the different communication channels used by UM to communicate with IP gateways or IP PBX.

By default, when you create a UM dial plan, it will communicate in an unsecured mode. Also, the Unified Messaging servers associated with the UM dial plan will send and receive data from IP gateways, IP PBXs, and other Exchange 2010 computers by using no encryption. In unsecured mode, both the Real-Time Transport Protocol (RTP) media channel and SIP signaling information won't be encrypted.

You can configure a Unified Messaging server to use mutual TLS to encrypt the SIP and RTP traffic sent and received from other devices and servers. When you add a Unified Messaging server to a UM dial plan and configure the dial plan to use SIP secured mode, only the SIP signaling traffic will be encrypted, and the RTP media channels will still use TCP. TCP isn't encrypted. However, if you add a Unified Messaging server to a UM dial plan and configure the dial plan to use secured mode, both the SIP signaling traffic and the RTP media channels are encrypted. A secure signaling media channel that uses Secure Real-Time Transport Protocol (SRTP) also uses mutual TLS to encrypt the VoIP data.

If the IP gateway or IP PBX you use supports IPsec, you can also use IPsec to help secure the communication between a UM server and the IP gateway or IP PBX.

For more details, see Understanding Unified Messaging VoIP Security.

UM also submits messages such as missed call notifications and voice mail messages to Hub Transport servers. By default, this communication occurs over SMTP using TLS encryption.

You can configure a UM mailbox policy for PIN-less access. This allows a caller to access voice mail without having to enter a PIN, based on the CallerID of the call. Spoofing of CallerID is insignificant. We recommend that you not enable PIN-less access to voice mail. Also, we recommend that you review the default PIN settings and configure them to meet your organization's security requirements. The following settings can be configured for a UM mailbox policy using the Set-UMMailboxPolicy cmdlet.

Parameters to control user PIN for voice mail access

Parameter	Description
AllowCommonPatterns	The AllowCommonPatterns parameter specifies whether to allow obvious PINs. Examples of obvious PINs include subsets of the telephone number, sequential numbers, or repeated numbers. If set to $false, sequential and repeated numbers and the suffix of the mailbox extension are rejected. If set to $true, only the suffix of the mailbox extension is rejected.
AllowPinlessVoiceMailAccess	The AllowPinlessVoiceMailAccess parameter specifies whether users associated with the UM mailbox policy are required to use a PIN to access their voice mail. A PIN is still required to access their e-mail and calendar. Default   disabled ($false).
LogonFailusresBeforePINReset	The LogonFailuresBeforePINReset parameter specifies the number of sequential unsuccessful logon attempts before the mailbox PIN is automatically reset. To disable this feature, set this parameter to Unlimited. If this parameter isn't set to Unlimited, it must be set to less than the value of the MaxLogonAttempts parameter. The range is from 0 through 999. Default   5 failures.
MaxLogonAttempts	The MaxLogonAttempts parameter specifies the number of times users can try unsuccessfully to log on, in sequence, before the UM mailboxes are locked. The range is from 1 through 999. Default   15 attempts.
MinPINLength	The MinPINLength parameter specifies the minimum number of digits required in a PIN for UM-enabled users. The range is from 4 through 24. Default   6 digits
PINHistoryCount	The PINHistoryCount parameter specifies the number of previous PINs that are remembered and aren't allowed during a PIN reset. This number includes the first time that the PIN was set. The range is from 1 through 20. Default   5 PINs
PINLifetime	The PINLifetime parameter specifies the number of days until a new password is required. The range is from 1 through 999. If you specify Unlimited, the users' PINs won't expire. Default   60 days

In Exchange 2010, voice mail messages can be marked as protected. Voice mail messages are protected using Information Rights Management (IRM). You can configure voice mail protection settings by configuring the following parameter in a UM mailbox policy. For more details, see the following topics:

• Understanding Protected Voice Mail

• Understanding Information Rights Management

Protected voice mail parameters

Parameter	Description
ProtectAuthenticatedVoicemail	The ProtectAuthenticatedVoiceMail parameter specifies whether Unified Messaging servers that answer Outlook Voice Access calls for UM-enabled users associated with the UM mailbox policy create protected voice mail messages. If the value is set to Private, only messages marked as private are protected. If the value is set to All, every voice mail message is protected. Default   None (No protection is applied to voice mail messages)
ProtectUnauthenticatedVoiceMail	The ProtectUnauthenticatedVoiceMail parameter specifies whether the Unified Messaging servers that answer calls for UM-enabled users associated with the UM mailbox policy create protected voice mail messages. This also applies when a message is sent from a UM auto attendant to a UM-enabled user associated with the UM mailbox policy. If the value is set to Private, only messages marked as private are protected. If the value is set to All, every voice mail message is protected. Default   None (No protection is applied to voice mail messages)
RequireProtectedPlayOnPhone	The RequireProtectedPlayOnPhone parameter specifies whether users associated with the UM mailbox policy can only use Play on Phone for protected voice mail messages or whether users can use multimedia software to play the protected message. Default   $false. Users are able to use both methods to listen to protected voice mail messages.

Important

For UM servers to continue to answer calls, it's critical that they have access to Active Directory. We recommend that you monitor Active Directory availability

Appendix 1: Additional Security-Related Documentation

This section contains links to additional security-related Exchange documentation.

Anti-Spam and Antivirus Functionality

• Understanding Anti-Spam and Antivirus Functionality

• Managing Anti-Spam and Antivirus Features

• Anti-Spam Cmdlets

Certificates

• Understanding TLS Certificates

• Managing SSL for a Client Access Server

• Configure SSL for Exchange ActiveSync

• Configure SSL for Outlook Anywhere

• Configuring TLS and SSL for POP3 and IMAP4 Access

• Configure Outlook Web App Virtual Directories to Use SSL

• Create a New Exchange Certificate

• Import an Exchange Certificate

• View Exchange Certificate Properties

• Assign Services to a Certificate

Client Authentication and Security

• Configuring Authentication for Exchange ActiveSync

• Configuring Authentication for POP3 and IMAP4

• Setting Up Forms-Based Authentication for Outlook Web App

• Setting Up Standard Authentication Methods for Outlook Web App

Outlook Web App

• Managing Outlook Web App Security

• Configure Outlook Web App Virtual Directories to Use SSL

• Setting Up Forms-Based Authentication for Outlook Web App

• Setting Up Standard Authentication Methods for Outlook Web App

• Configure Outlook Web App to Work with Active Directory Federation Services

• Outlook Web App and S/MIME

Outlook Anywhere

• Managing Outlook Anywhere Security

POP3 and IMAP

• Managing POP3 and IMAP4 Security

• Configure Authentication for POP3

• Configure Authentication for IMAP4

• Configuring TLS and SSL for POP3 and IMAP4 Access

Permissions

• Exchange 2010 Deployment Permissions Reference

• Understanding Role Based Access Control

• Understanding Split Permissions

• Understanding Permissions Coexistence with Exchange 2003

• Understanding Permissions Coexistence with Exchange 2007

• Understanding Multiple-Forest Permissions

• Feature Permissions

• Managing Administrator and Specialist Users

• Managing End Users

• Management Roles and Role Entries

• Management Role Scopes

• Management Role Assignments

• Managing Split Permissions

• Permissions to Manage Mailbox Servers

• Securing Unified Messaging Servers

Protecting Mail Flow

• Understanding Domain Security

• Using PKI on the Edge Transport Server for Domain Security

• Using Domain Security: Configuring Mutual TLS

• Test PKI and Proxy Configuration

Messaging Policy and Compliance

• Understanding Information Rights Management

• Understanding Journaling

• Protecting Journal Reports

• Understanding Messaging Records Management

• Understanding Retention Tags and Retention Policies

• Understanding Multi-Mailbox Search

• Understanding Mailbox Audit Logging

• Managing Mailbox Audit Logging

Federation

• Understanding Federation

• Trusted Root Certification Authorities for Federation Trusts

 © 2010 Microsoft Corporation. All rights reserved.