Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Topic Last Modified: 2007-09-17

In the past, for each version of Microsoft Exchange Server, 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 Setup ran. However, in Microsoft Exchange Server 2007 with server role-based setup, Microsoft Exchange enables only those services that are required by the server role that is being installed. Microsoft Exchange is no longer installed and then hardened for security. It's designed to be secure-by-default.

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

What's Covered in This Guide?

This guide is written for the IT administrator who is responsible for securing the Exchange 2007 deployment. It's designed to help the IT administrator understand and manage the overall security environment where Exchange is installed. The following information is included in this guide:

The Exchange 2007 Security Development Life Cycle

In early 2002, Microsoft introduced the Trustworthy Computing initiative. Since Trustworthy Computing was introduced, the development process at Microsoft and in the Exchange Server team has focused on developing software that is secure-by-default. For more information, see Trustworthy Computing.

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

  • Secure by design   Exchange 2007 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 before the code is checked into the final product. Of course, it is impossible to design against all unknown security threats. No system can guarantee complete security. However, by including secure design principles into the whole design process, Exchange 2007 is more secure than earlier versions have been.

  • Secure by default   One goal of Exchange 2007 was to develop a system in which most network communications are encrypted by default. Except for Server Message Block (SMB) cluster communications and some Unified Messaging (UM) communications, this goal was met. By using self-signed certificates, the Kerberos protocol, Secure Sockets Layer (SSL), and other industry standard encryption techniques, almost all Exchange 2007 data is protected on the network. In addition, role-based setup makes it possible to install Exchange 2007 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 Exchange Server, all services for all functionality had to be installed. 

    Note:
    To encrypt SMB and UM communications, Internet Protocol security (IPsec) must be deployed. Future versions of this guide may include information about how to encrypt SMB and UM communications.
  • Anti-spam and antivirus functionality   Exchange 2007 includes a suite of anti-spam agents that run at the perimeter network. Antivirus functionality is further improved by the addition of Microsoft Forefront Security for Exchange Server as a Microsoft solution.

  • Secure in deployment   As Exchange 2007 was developed, the pre-release version was deployed in the Microsoft IT production environment. Based on data from that deployment, the Microsoft Exchange Best Practice 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 2007 Help. 

    In the past, permission management was documented and delivered after the core product documentation was finished. However, we know that permission management is not an add-in process. It should be built into the overall planning and deployment phases of your Exchange 2007 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.

  • Communications   Now that Exchange 2007 has released, the Exchange team is committed to keeping the 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 2007 also includes anti-spam updates. In addition, by subscribing to the Microsoft Technical Security Notifications, you can stay abreast of the latest security issues in Exchange 2007.

Return to top

Best Practices

Let's look at some basic best practices that will help you create and maintain a more secure environment. Generally, just keeping software and antivirus signature files up-to-date, and running analyzer tools periodically are the most effective ways to optimize your Exchange 2007 environment for security. 

This section describes some best practices for getting secure and staying secure in an Exchange 2007 environment.

Getting Secure

The following tools are provided by Microsoft to help create a secure environment. Run the following tools before you install Exchange 2007:

  • Microsoft Update

  • Exchange Best Practices Analyzer

  • Microsoft Baseline Security Analyzer

  • Internet Information Services (IIS) Lockdown Tool and URLScan, only for environments in which you are running Windows Server 2003 after you have upgraded from Windows 2000 Server.

  • Exchange templates for the Security Configuration Wizard (SCW)

Microsoft Update

Microsoft Update is a new service that offers the same downloads as Windows Update—plus the latest updates for other Microsoft programs. It can help keep your computer 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 (or 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 is installed on your computer for any current and past high-priority updates it requires and then download and install them automatically. After that, whenever you connect to the Internet, Windows repeats this update process for any new high-priority updates.

Note:
If you're already using Automatic Updates, Microsoft Update will continue to operate it as you've set it up.

To enable Microsoft Update, see Microsoft Update. 

The default mode of Microsoft Update requires that each Exchange computer is connected to the Internet to receive automatic updates. If you are running servers that are not 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 Exchange Server computers to contact your internal WSUS server for updates. For more information, see Microsoft Windows Server Update Services 3.0. 

WSUS is not the only Microsoft Update management solution available. For more information about which Microsoft Update management solution best meets your needs, see MBSA, MU, WSUS, Essentials 2007 or SMS 2003?.

Anti-Spam Updates

Exchange 2007 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 for download every two weeks.

Manual updates from Microsoft Update do not 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.

Note:
Forefront Anti-spam Automatic Updates is a premium feature that requires either an Exchange Enterprise client access license (CAL) for each user mailbox, or a Forefront Security for Exchange Server license.

For more information about how to enable Forefront Anti-spam Automatic Updates, see Anti-Spam Updates.

Microsoft Exchange Best Practices Analyzer

The Exchange Best Practices Analyzer is one of the most effective tools that you can regularly run to help verify that your Exchange environment is secure. The Exchange Best Practices Analyzer automatically examines your Microsoft Exchange deployment and determines whether the configuration is set according to Microsoft best practices. You can install the Exchange Best Practices Analyzer on a client computer that is running Microsoft .NET Framework 1.1. With the appropriate network access, the Exchange Best Practices Analyzer examines all your Active Directory directory service and Exchange servers.

For more information, including best practices, see the "Running Exchange Best Practices Analyzer" section later in this guide and Microsoft Exchange Best Practices Analyzer v2.8.

Microsoft Baseline Security Analyzer

Microsoft Baseline Security Analyzer (MBSA) is a tool that was designed for the IT professional to help small and medium-sized businesses determine their security state in compliance with Microsoft security recommendations. Improve your security management process by using MBSA to detect common security misconfigurations and missing security updates on your computer systems. 

You can download the MBSA at Microsoft Baseline Security Analyzer.

IIS Lockdown Tool and URLScan

By default, IIS version 6.0 and IIS version 7.0, which is installed with Windows Server and Windows Server 2008 respectively, have security-related configuration settings that are similar to those made by the IIS Lockdown Tool. Therefore, you do not have to run the IIS Lockdown Tool on Web servers that are running IIS version 6.0 or IIS version 7.0. However, if you are upgrading from an earlier version of IIS to IIS version 6.0 or IIS version 7.0, we recommend that you run the IIS Lockdown Tool to enhance the security of your Web server. 

We recommend that you do not run URLScan with IIS version 6.0 or IIS version 7.0 because the risk of misconfiguration is much more than the benefit that URLScan provides.

For more information, see How To : Use IISLockdown.exe.

Exchange 2007 Templates for the Security Configuration Wizard

The Security Configuration Wizard (SCW) is a tool that was introduced with Windows Server 2003 Service Pack 1. Use the SCW to minimize the attack surface for servers by disabling Windows functionality that is not required for Exchange 2007 server roles. The SCW automates the security best practice of reducing attack surface for a server. The SCW uses a role-based metaphor to solicit services that are required for the applications on a server. This tool reduces the susceptibility of Windows environments to exploitation of security vulnerabilities.

For more information about how to create Exchange 2007 templates for the SCW, see the section, "Using the Security Configuration Wizard to Secure Windows for Exchange Server Roles," later in this guide.

Staying Secure

This section provides best practice recommendations for keeping your Exchange 2007 environment secure.

Running the Exchange Best Practices Analyzer

As mentioned in the previous section, the Exchange Best Practices Analyzer is one of the most effective tools that you can regularly run to help verify that your Exchange environment is secure.

For most environments, we recommend running the Exchange Best Practices Analyzer at least one time per quarter. However, it is a best practice to run it one time per month on all servers that are running Exchange Server is installed.

Additionally, you should run the Exchange Best Practices Analyzer in the following scenarios:

  • Whenever you make significant configuration changes to an Exchange server. For example, you should run it after you add or remove connectors or create an EdgeSync connection to an Edge Transport server.

  • Immediately after you have installed a new Exchange server role or removed an Exchange server role.

  • After you install a Windows service pack or Exchange Server service pack.

  • After you install third-party software on a computer that is running Microsoft Exchange.

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 practice recommendations for the deployment of antivirus software for Exchange 2007 and Microsoft Office Outlook 2007.

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

  • Exchange 2007 is based on a 64-bit architecture.

  • As described in more detail later in this topic, Exchange 2007 includes new transport agent functionality.

These two changes mean that antivirus vendors must provide Exchange 2007–specific software. Antivirus software that is written for earlier versions of Exchange Server is unlikely to operate correctly with Exchange 2007.

To use a defense-in-depth approach, we recommend that you deploy antivirus software that is designed for messaging systems at either the Simple Mail Transfer Protocol (SMTP) gateway or at the Exchange servers that host mailboxes, in addition antivirus software on the user desktop.

You decide what types of antivirus software to use and where the software is deployed by finding the appropriate balance between the cost that you are willing to tolerate and the risk that 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 gateway, general file-level protection at the mail server, and 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 is 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

The most important position for messaging antivirus software is at the first line of defense in your organization. In Exchange 2007, the first line of defense is at the perimeter network on the Edge Transport server.

To better guard against virus outbreaks from inside the organization and to provide as a second line of defense, we also recommend that you run transport-based antivirus software on the Hub Transport servers inside your organization.

In Exchange 2007, agents act on transport events, much like event sinks in earlier versions of Microsoft Exchange. Third-party developers can write customized agents to take advantage of the underlying Exchange MIME-parsing engine for robust transport-level antivirus scanning.

Many third-party software vendors provide Exchange 2007–specific agents that take advantage of the Exchange transport MIME-parsing engine. Contact your antivirus vendor for more information.

In addition, Microsoft Forefront Security for Exchange Server includes a transport antivirus agent for Exchange 2007. For more information about how to install and configure the Forefront Security for Exchange Server antivirus agent, see Protecting Your Microsoft Exchange Organization with Microsoft Forefront Security for Exchange Server.

Note:
Objects that are not routed through transport, such as items in public folders, Sent Items, and calendar items, which can only be scanned on a Mailbox server, are not protected by transport-only virus scanning.
Running Antivirus Software on Other Computers in the Organization

You can run file-level virus scanning on the following two classes of computers:

  • User desktops

  • Servers

In addition to file-level virus scanning, consider running a Microsoft VSAPI solution on your Exchange Mailbox server.

Desktop Virus Scanning

We strongly recommend that your users run the latest version of Outlook. If you run outdated e-mail clients on the desktop, you take a serious risk because of the object model and attachment-handling behavior in older e-mail clients. By default therefore, Microsoft Office Outlook 2003 and Office Outlook 2007 are the only MAPI clients from which Exchange 2007 accepts connections. For more information about the risks associated with running older versions of e-mail clients, see Taking Steps to Secure Outlook.

After you have upgraded to Outlook 2003 or Outlook 2007, verify that you have installed a file-level antivirus software product on all desktop computers. In addition, take the following steps:

  • Develop a plan to make sure that antivirus signature files are automatically updated on all desktops.

  • Make sure that you develop and maintain an end-to-end update management solution in your organization to battle viruses.

Server Virus Scanning

Consider adopting a general policy to run file-level scanning on all desktop and server computers in your organization. Therefore, all Exchange Server computers should have some form of file-level antivirus scanning running on them. For each server role, you must perform additional configuration to file-level scanning so that certain directories, file types, and processes are not scanned. For example, we recommend that you never run file-level antivirus software against the Exchange store databases. For specific configuration information, see File-Level Antivirus Scanning on Exchange 2007.

Mailbox Database Scanning with VSAPI

A Microsoft Virus Scanning API (VSAPI) scanning solution may be an important layer of defense for many organizations. You should consider running a VSAPI antivirus solution if either of the following conditions is true:

  • Your organization does not have complete and reliable desktop antivirus scanning products deployed.

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

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

  • Your user community routinely posts messages into 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 is submitted to a database by CDO (Collaboration Data Objects), WebDAV, and Exchange Web services.

In addition, when a virus outbreak does occur, frequently a VSAPI antivirus solution provides the quickest way to remove and eliminate viruses from an infected mail store.

For more specific information about how to run Forefront Security for Exchange Server, which includes a VSAPI scanning engine, see Protecting Your Microsoft Exchange Organization with Microsoft Forefront Security for Exchange Server.

Using Exchange Hosted Services

Spam and virus filtering is enhanced 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 them satisfy retention requirements for compliance

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

  • Hosted Continuity, which helps them preserve access to e-mail during and after emergency situations

These services integrate with any on-premise Exchange servers that are managed in-house or Hosted Exchange e-mail services that are offered through service providers. For more information about Exchange Hosted Services, see Microsoft Exchange Hosted Services.

More Antivirus Information

For a detailed white paper about how MSIT deployed an Exchange 2007 server antivirus solution, see Microsoft Exchange Server 2007 Edge Transport and Messaging Protection.

Forefront Security for Exchange Server provides a multiple scanning engine antivirus solution for Exchange Transport server roles and a VSAPI solution for the Exchange Mailbox server. For best practices about an end-to-end antivirus solution, see Protecting Your Microsoft Exchange Organization with Microsoft Forefront Security for Exchange Server.

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 across all computers in your organization.

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

Blocking Legacy Outlook Clients

Older versions of Outlook contained vulnerabilities that can potentially increase the spread of viruses. As a best practice, you should allow Exchange 2007 to only accept MAPI connections from the Outlook 2007,, Outlook 2003, and Outlook 2002 clients. By restricting the versions of Outlook clients that can connect to Exchange, you can greatly reduce the risk of virus and other malware attacks. As a best practice, we recommend that you reduce and standardize the software versions that run in your organization.

For more information about how to remove Outlook client access to Exchange 2007, see All versions of Outlook are allowed to access the server.

Running Attachment Filtering

In Exchange 2007, attachment filtering lets you apply filters at the server level to control the attachments that users receive. Attachment filtering is increasingly important in today's environment, where many attachments 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.

Note:
As a best practice, don't remove attachments from digitally signed, encrypted, or rights-protected e-mail messages. If you remove attachments from such messages, you invalidate the digitally signed messages and make encrypted and rights-protected messages unreadable.
Types of Attachment Filtering in Exchange 2007

You can use the following types of attachment filtering to control attachments that enter or leave your organization:

  • 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 is a JPEG image, an executable file, a Microsoft Office Excel 2003 file, or some other file type. Content types are expressed as type/subtype. For example, the JPEG image content type is expressed as image/jpeg.

    To view a complete list of all file name extensions and content types that attachment filtering can filter on, run the following command:

    Copy Code 
    Get-AttachmentFilterEntry | FL
    To run the Get-AttachmentFilterEntry cmdlet on a computer that is joined to a domain, you the account you use must be delegated Exchange View-Only Administrators role.

    To run the Get-AttachmentFilterEntry cmdlet on a computer that has the Edge Transport server role installed, you must log on by using an account that is a member of the local Administrators group on that computer.

    For more information about permissions, delegating roles, and the rights that are required to administer Exchange 2007, see Permission Considerations.

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

  • Block whole message and attachment   An attachment that matches an attachment filter together with its whole e-mail message can be blocked from entering the messaging system. If an attachment and e-mail message are blocked, the sender receives a delivery status notification (DSN) message that states that the message contains an unacceptable attachment file name.

  • Strip attachment but allow message through   An attachment that matches an attachment filter can be removed whereas the e-mail message and any other attachments that do not match the filter are allowed through. If an attachment is stripped, it is replaced with a text file that explains why the attachment was removed. This action is the default setting.

  • Silently delete message and attachment   An attachment that matches an attachment filter together with its whole e-mail message can be blocked from entering the messaging system. If an attachment and e-mail message are blocked, neither the sender nor the recipient receives notification.

    Caution:
    You cannot retrieve e-mail messages and attachments that are blocked or attachments that are stripped. When you configure attachment filters, make sure that you carefully examine all possible file name matches and verify that legitimate attachments will not be affected by the filter.

For more information, see How to Configure Attachment Filtering.

File Filtering by Using Forefront Security for Exchange Server

The file filtering functionality that is provided by Forefront Security for Exchange Server includes advanced features that are unavailable in the default Attachment Filter agent that is included with Exchange Server 2007 Standard Edition.

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

  • PKZip (.zip)

  • GNU Zip (.gzip)

  • Self-extracting ZIP archives

  • Zip files (.zip)

  • Java archive (.jar)

  • TNEF (winmail.dat)

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

  • MIME (.eml)

  • SMIME (.eml)

  • UUEncode (.uue)

  • Unix tape archive (.tar)

  • RAR archive (.rar)

  • MACBinary (.bin)

Note:
The default Attachment Filter agent that is included with Exchange 2007 Standard Edition detects file types even if they have been renamed. Attachment filtering also makes sure that compressed Zip and LZH files do not contain blocked attachments by performing a file name extension match against the files in the compressed Zip or LZH file. Forefront Security for Exchange Server file filtering has the additional capability of determining if a blocked attachment has been renamed within a container file.

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

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

Enforcing Strong Passwords in Your Organization

Most users log on to their local computer and to remote computers by using a combination of their user name and a password typed at the keyboard. Although alternative technologies for authentication, such as biometrics, smartcards, and one-time passwords, are available for all popular operating systems, most organizations still rely on traditional passwords and will continue to do this for years to come. Therefore, it is very important that organizations define and enforce password policies for their computers. This includes mandating the use of strong passwords. Strong passwords meet several requirements for complexity that make passwords more difficult for an attacker to determine. Among these requirements are requirements for password length and character categories. By establishing strong password policies for your organization, you can help prevent an attacker from impersonating users and so help prevent the loss, exposure, or corruption of sensitive information.

For more information, see Enforcing Strong Password Usage Throughout Your Organization.

Decoupling Windows Usernames and SMTP Addresses

By default, when you create a mailbox for a user, the resulting SMTP address for that user is username@contoso.com, where username is the Windows user account name.

It is a best practice to create a new SMTP address for users to obfuscate the Windows user names from malicious users.

For example, consider the user Kweku Ako-Adjei, with a Windows user name of KwekuA. To obfuscate the Windows user name, the administrator can create an SMTP address of Kweku.Ako-Adjei@contoso.com.

Using a separate SMTP address is not considered a very strong security measure. However, it does create one more hurdle for malicious users who may try to hack into your organization by using a known username.

For more information about how to add SMTP addresses for existing users, see How to Create an E-Mail Address Policy.

Managing Client Access Security

The Client Access server role provides access to Microsoft Outlook Web Access, Microsoft Exchange ActiveSync, Outlook Anywhere, Post Office Protocol version 3 (POP3), and Internet Message Access Protocol version 4rev1 (IMAP4). In addition, it supports the Autodiscover service and the Availability service. Each of these protocols and services has unique security needs.

Managing Authentication

One of the most important security-related tasks that you can perform for the Client Access server role is to configure an authentication method. The Client Access server role is installed with a default self-signed digital certificate. A digital certificate does two things:

  • It authenticates that its holder is who or what they claim to be.

  • It protects data exchanged online from theft or tampering.

Although the default, self-signed certificate is supported for Exchange ActiveSync and Outlook Web Access, it is not the most secure method of authentication. In addition, it is not supported for Outlook Anywhere. For additional security, consider configuring your Exchange 2007 Client Access server to use a trusted certificate from either a third-party commercial certification authority (CA) or a trusted Windows Public Key Infrastructure (PKI) CA. You can configure authentication separately for Exchange ActiveSync, Outlook Web Access, Outlook Anywhere, POP3, and IMAP4.

For more information about how to configure authentication, see the following topics:

Enhancing Secure Communications Between the Client Access Server and Other Servers

After you optimize the security of your communications between clients and the Exchange 2007 server, you must optimize the security of the communications between the Exchange 2007 server and other servers in your organization. By default, HTTP, Exchange ActiveSync, POP3, and IMAP4 communication between the Client Access server and other servers, such as Exchange 2007 servers that have the Mailbox server role installed, domain controllers, and global catalog servers, is encrypted.

For more information about how to manage security for the various components of your Client Access server, see the following topics:

Return to top

Understanding Domain Security

Exchange 2007 includes a new feature set that is named "Domain Security." Domain Security refers to the set of functionality in Exchange 2007 and Outlook 2007 that provides a relatively low-cost alternative to S/MIME or other message-level security solutions. The purpose of the Domain Security feature set is to provide administrators a way to manage secured message paths over the Internet with business partners. After these secured message paths are configured, messages that have successfully traveled over the secured path from an authenticated sender are displayed to users as "Domain Secured" in the Outlook and Outlook Web Access interface.

Domain Security uses Transport Layer Security (TLS) with mutual authentication to provide session-based authentication and encryption. TLS with mutual authentication differs from TLS as it is usually implemented. Typically, when TLS is implemented, the client verifies that the connection securely connects to the intended server by validating the server’s certificate. This is received as part of TLS negotiation. In this scenario, the client authenticates the server before the client transmits data. However, the server doesn't authenticate the session with the client.

With mutual TLS authentication, each server verifies the connection with the other server by validating a certificate that is provided by that other server. In this scenario, where messages are received from external domains over verified connections in an Exchange 2007 environment, Outlook 2007 will display a "Domain Secured" icon.

For more information about how to plan for and deploy Domain Security in your organization, see White Paper: Domain Security in Exchange 2007.

Return to top

Protecting Exchange Data Paths

By default, nearly all data paths used by Exchange 2007 are protected. This section provides details about ports, authentication, and encryption for all data paths used by Exchange 2007. The Notes sections following each table clarify or define non-standard authentication or encryption methods.

Transport Servers

The following table provides information about ports, authentication, and encryption for data paths between Hub Transport servers and Edge Transport servers, and to and from other Exchange 2007 servers and services.

Transport server data paths

Data path Required ports Default authentication Supported authentication Encryption supported? Encrypted by default?

Hub Transport server to Hub Transport server

25/TCP (Secure Sockets Layer [SSL]), 587/TCP (SSL)

Kerberos

Kerberos

Yes (TLS)

Yes

Hub Transport server to Edge Transport server

25/TCP (SSL)

Direct trust

Direct trust

Yes (TLS)

Yes

Edge Transport server to Hub Transport server

25/TCP (SSL)

Direct trust

Direct trust

Yes (TLS)

Yes

Edge Transport server to Edge Transport server

25/TCP (SSL), 389/TCP/UDP, and 80/TCP (certificate authentication)

Anonymous, Certificate

Anonymous, Certificate

Yes (TLS)

No

Mailbox server to Hub Transport server via the Microsoft Exchange Mail Submission Service

135/TCP (RPC)

NTLM. If connecting with a service account (local), Kerberos is used.

NTLM/Kerberos

Yes (RPC encryption)

Yes

Hub Transport to Mailbox server via MAPI

135/TCP (RPC)

NTLM. If connecting with a service account (local), Kerberos is used.

NTLM/Kerberos

Yes (RPC encryption)

Yes

Microsoft Exchange EdgeSync service

50636/TCP (SSL), 50389/TCP (No SSL)

Basic

Basic

Yes (LDAPS)

Yes

Active Directory Application Mode (ADAM) directory service on Edge Transport server

50389/TCP (No SSL)

NTLM/Kerberos

NTLM/Kerberos

No

No

Active Directory directory service access from Hub Transport server

389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)

Kerberos

Kerberos

Yes (Kerberos encryption)

Yes

Notes on Transport Servers

All traffic between Hub Transport servers is encrypted by using TLS with self-signed certificates that are installed by default by Exchange 2007 Setup.

All traffic between Edge Transport servers and Hub Transport servers is authenticated and encrypted. The underlying mechanism for authentication and encryption is mutual TLS. Instead of using X.509 validation, Exchange 2007 uses direct trust to authenticate the certificates. Direct trust means that the presence of the certificate in Active Directory or ADAM validates the certificate. Active Directory is considered a trusted storage mechanism. When direct trust is used, it doesn't matter if the certificate is self-signed or signed by a certification authority. When you subscribe an Edge Transport server to the Exchange organization, the Edge Subscription publishes the Edge Transport server certificate in Active Directory for the Hub Transport servers to validate. The Microsoft Exchange EdgeSync service updates ADAM with the set of Hub Transport server certificates for the Edge Transport server to validate.

By default, traffic between Edge Transport servers in different organizations is encrypted. By default, Exchange 2007 Setup creates a self-signed certificate and TLS is enabled. This allows any sending system to encrypt the inbound SMTP session to Microsoft Exchange. Also by default, Exchange 2007 tries TLS for all remote connections.

Authentication methods for traffic between Hub Transport servers and Mailbox servers differ when the Hub Transport server roles and Mailbox server roles are located on the same computer. When mail submission is local, Kerberos authentication is used. When mail submission is remote, NTLM authentication is used.

Exchange 2007 also supports Domain Security. Domain Security refers to the set of functionality in Exchange 2007 and Outlook 2007 that provides a low-cost alternative to S/MIME or other message-level over-the-Internet, security solutions. The purpose of the Domain Security feature set is to provide administrators a way to manage secured message paths between domains over the Internet. After these secured message paths are configured, messages that have successfully traveled over the secured path from an authenticated sender are displayed to users as "Domain Secured" in the Outlook and Outlook Web Access interface. For more information, see Planning for Domain Security.

Many agents may run on the Hub Transport servers and Edge Transport servers. Generally, the anti-spam agents rely on information that is local to the computer that the agents run on. Therefore, very little communication with remote computers is required. The exception is recipient filtering. This requires calls to either ADAM or Active Directory. It is a best practice to run recipient filtering on the Edge Transport server. In this case, the ADAM directory is on the same computer as the Edge Transport server and no remote communication is required. When recipient filtering has been installed and configured on the Hub Transport server, recipient filtering accesses Active Directory.

The Protocol Analysis agent is used by the Sender Reputation feature in Exchange 2007. This agent also makes various connections to outside proxy servers to determine inbound message paths for suspect connections.

All other anti-spam functionality uses data that is collected, stored, and accessed only on the local computer. Frequently, the data, such as safelist aggregation or recipient data for recipient filtering, is pushed to the local ADAM directory by using the Microsoft Exchange EdgeSync service.

Journaling and message classification run on Hub Transport servers and rely on Active Directory data to function.

Mailbox Server

In the context of the Mailbox server role, whether the authentication is NTLM or Kerberos relies on the user or process context that the Exchange Business Logic layer consumer is running under. In this context, the consumer is any application or process that uses the Exchange Business Logic layer. In many of the "Default Authentication" cells in the "Mailbox Server data paths" table in this section, the authentication is listed as "NTLM/Kerberos."

The Exchange Business Logic layer is used to access and communicate with the Exchange store. The Exchange Business Logic layer is also known as from the Exchange store to communicate with external applications and processes.

If the Exchange Business Logic layer consumer is running as Local System, the authentication method is always Kerberos from the consumer to the Exchange store. Kerberos is used because the consumer must be authenticated by using the computer account Local System and a two-way authenticated trust must exist.

If the Exchange Business Logic layer consumer is not running as Local System, the authentication method is NTLM. For example, when an Administrator runs an Exchange Management Shell cmdlet that uses the Exchange Business Logic layer, NTLM is used.

The RPC traffic is always encrypted.

The following table provides information about ports, authentication, and encryption for data paths to and from Mailbox servers

Mailbox server data paths

Data path Required ports Default authentication Supported authentication Encryption supported? Encrypted by default?

Log shipping (Local Continuous Replication and Cluster Continuous Replication)

445/Random port (Seeding)

NTLM/Kerberos

NTLM/Kerberos

Yes (IPsec)

No

Volume shadow copy service (VSS) backup

Local Message Block (SMB)l

NTLM/Kerberos

NTLM/Kerberos

No

No

Legacy Backup/Seeding

Random port

NTLM/Kerberos

NTLM/Kerberos

Yes (IPsec)

No

Clustering

135 /TCP (RPC) See "Notes on Mailbox Servers" after this table.

NTLM/Kerberos

NTLM/Kerberos

Yes (IPsec)

No

MAPI access

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Yes (RPC encryption)

Yes

Mailbox Assistants

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

No

No

Availability Web service (Client Access to Mailbox)

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Yes (RPC encryption)

Yes

Active Directory access

389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)

Kerberos

Kerberos

Yes (Kerberos encryption)

Yes

Content indexing

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Yes (RPC encryption)

Yes

Admin remote access (Remote Registry)

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Yes (IPsec)

No

Admin remote access (SMB/File)

445/TCP (SMB)

NTLM/Kerberos

NTLM/Kerberos

Yes (IPsec)

No

Recipient Update Service RPC access

135/TCP (RPC)

Kerberos

Kerberos

Yes (RPC encryption)

Yes

Microsoft Exchange Active Directory Topology service access

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Yes (RPC encryption)

Yes

Microsoft Exchange System Attendant service legacy access (Listen to requests)

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

No

No

Microsoft Exchange System Attendant service legacy access to Active Directory

389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)

Kerberos

Kerberos

Yes (Kerberos encryption)

Yes

Microsoft Exchange System Attendant service legacy access (As MAPI client)

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Yes (RPC encryption)

Yes

Offline Address Book (OAB) accessing Active Directory

135/TCP (RPC)

Kerberos

Kerberos

Yes (RPC encryption)

Yes

Recipient update to Active Directory

389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)

Kerberos

Kerberos

Yes (Kerberos encryption)

Yes

DSAccess to Active Directory

389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)

Kerberos

Kerberos

Yes (Kerberos encryption)

Yes

Outlook accessing Offline Address Book (OAB)

80/TCP, 443/TCP (SSL)

NTLM/Kerberos

NTLM/Kerberos

Yes (HTTPS)

No

WebDav

80/TCP, 443/TCP (SSL)

Basic, NTLM, Negotiate

Basic, NTLM, Negotiate

Yes (HTTPS)

Yes

Notes on Mailbox Servers

For HTTP authentication where "Negotiate" is listed, Kerberos is tried first, and then NTLM.

For intra-node communications, cluster nodes communicate over User Datagram Protocol (UDP) port 3343. Each node in the cluster periodically exchanges sequenced, unicast UDP datagrams with every other node in the cluster. The purpose of this exchange is to determine whether all nodes are running correctly and to monitor the health of network links.

Although WebDav applications or clients can connect to the Mailbox server by using 80/TCP or 443/TCP, in most cases the application or clients connect to the Client Access server. The Client Access server then connects to the Mailbox server over 80/TCP or 443/TCP.

The clustering data path listed in the "Mailbox Server data paths" table in this section uses dynamic RPC (TCP) to communicate cluster status and activity between the different cluster nodes. The cluster service (ClusSvc.exe) also uses UDP/3343 and randomly allocated high TCP ports to communicate between cluster nodes.

Client Access Server

Unless noted, client access technologies, such as Office Outlook Web Access, POP3, or IMAP4, are described by the authentication and encryption from the client application to the Client Access server.

The following table provides information about port, authentication, and encryption for data paths between Client Access servers and other servers and clients.

Client Access server data paths

Data path Required ports Default authentication Supported authentication Encryption supported? Encrypted by default?

Autodiscover service

80/TCP, 443/TCP (SSL)

Basic/Integrated Windows authentication (Negotiate)

Basic, Digest, NTLM, Negotiate (Kerberos)

Yes (HTTPS)

Yes

Availability service

80/TCP, 443/TCP (SSL)

NTLM/Kerberos

NTLM, Kerberos

Yes (HTTPS)

Yes

Outlook Web Access

80/TCP, 443/TCP (SSL)

Forms Based Authentication

Basic, Digest, Forms Based Authentication, NTLM (v2 only), Kerberos, Certificate

Yes (HTTPS)

Yes, using self-signed certificate

POP3

110/TCP (TLS), 995/TCP (SSL)

Basic, NTLM, Kerberos

Basic, NTLM, Kerberos

Yes (SSL, TLS)

Yes

IMAP4

143/TCP (TLS), 993/TCP (SSL)

Basic, NTLM, Kerberos

Basic, NTLM, Kerberos

Yes (SSL, TLS)

Yes

Outlook Anywhere (formerly known as RPC over HTTP )

80/TCP, 443/TCP (SSL)

Basic

Basic or NTLM

Yes (HTTPS)

Yes

Exchange ActiveSync application

80/TCP, 443/TCP (SSL)

Basic

Basic, Certificate

Yes (HTTPS)

Yes

Client Access server to Unified Messaging server

5060/TCP, 5061/TCP, 5062/TCP, a dynamic port

By IP address

By IP address

Yes (Session Initiation Protocol [SIP] over TLS)

Yes

Client Access server to a Mailbox server that is running an earlier version of Exchange Server

80/TCP, 443/TCP (SSL)

NTLM/Kerberos

Negotiate (Kerberos with fallback to NTLM or optionally Basic,) POP/IMAP plain text

Yes (IPsec)

No

Client Access server to Exchange 2007 Mailbox server

RPC. See "Notes on Client Access Servers" after this table.

Kerberos

NTLM/Kerberos

Yes (RPC encryption)

Yes

Client Access server to Client Access server (Exchange ActiveSync)

80/TCP, 443/TCP (SSL)

Kerberos

Kerberos, Certificate

Yes (HTTPS)

Yes, using self-signed certificate

Client Access server to Client Access server (Outlook Web Access)

80/TCP, 443/TCP (SSL)

Kerberos

Kerberos

Yes (HTTPS)

Yes

WebDAV

80/TCP, 443/TCP (SSL)

HTTP Basic or Outlook Web Access forms-based authentication

Basic, Outlook Web Access forms-based authentication

Yes (HTTPS)

Yes

Notes on Client Access Servers

The Client Access server communicates to the Mailbox server by using many ports. With some exceptions, those ports are determined by the RPC service and are not fixed.

For HTTP authentication where "Negotiate" is listed, Kerberos is tried first, and then NTLM is tried.

When an Exchange 2007 Client Access server is communicating with a Mailbox server that is running Exchange Server 2003, it is a best practice to use Kerberos and disable NTLM authentication and Basic authentication. Additionally, it is a best practice to configure Outlook Web Access to use forms-based authentication with a trusted certificate. For Exchange ActiveSync clients to communicate through the Exchange 2007 Client Access server to the Exchange 2003 back-end server, Integrated Windows Authentication must be enabled on the Microsoft-Server-ActiveSync virtual directory on the Exchange 2003 back end server. To use Exchange System Manager on the Exchange 2003 server to manage authentication on an Exchange 2003 virtual directory, download and install the hot fix referenced in Microsoft Knowledge Base article 937301, Event ID 1036 is logged on an Exchange 2007 server that is running the CAS role when mobile devices connect to the Exchange 2007 server to access mailboxes on an Exchange 2003 back-end server. 

For more information, see Managing Client Access Security.

Unified Messaging Server

IP gateways only support certificate-based authentication that uses mutual TLS and IP-based authentication for Session Initiation Protocol (SIP)/TCP connections. IP gateways do not support either NTLM or Kerberos authentication. Therefore, when you use IP-based authentication, the connecting IP address or addresses are used to provide authentication mechanism for unencrypted (TCP) connections. When IP-based authentication is used in Unified Messaging, the Unified Messaging server verifies that the IP address is allowed to connect. The IP address is configured on the IP gateway or IP PBX.

The following table provides information about port, authentication, and encryption for data paths between Unified Messaging servers and other servers.

Unified Messaging server data paths

Data path Required ports Default authentication Supported authentication Encryption supported? Encrypted by default?

Unified Messaging Fax

5060/TCP, 5061/TCP, 5062/TCP, a dynamic port

By IP address

By IP address

SIP over TLS, but media is not encrypted

Yes for SIP

Unified Messaging Phone interaction (PBX)

5060/TCP, 5061/TCP, 5062/TCP, a dynamic port

By IP address

By IP address

SIP over TLS, but Media is not encrypted

Yes for SIP

Unified Messaging Web Service

80/TCP, 443/TCP (SSL)

Integrated Windows authentication (Negotiate)

Basic, Digest, NTLM, Negotiate (Kerberos)

Yes (SSL)

Yes

Unified Messaging to Hub Transport

25/TCP (SSL)

Kerberos

Kerberos

Yes (TLS)

Yes

Unified Messaging server to Mailbox server

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Yes (RPC encryption)

Yes

Notes on Unified Messaging Servers

When you create a Unified Messaging (UM) IP gateway object in Active Directory, you must define the IP address of the physical IP gateway or IP PBX (Private Branch eXchange). When you define the IP address on the UM IP Gateway object, the IP address is added to a list of valid IP gateways that the Unified Messaging server is allowed to communicate with. When the UM IP gateway is created, it is associated with a UM dial plan. Associating the UM IP gateway with a dial plan allows the Unified Messaging servers that are associated with the dial plan to use IP-based authentication to communicate with the IP gateway. If the UM IP gateway has not been created or it is not configured to use the correct IP address, authentication fails and the Unified Messaging servers do not accept connections from that IP gateway's IP address.

With the release to manufacturing (RTM) version of Exchange 2007, a Unified Messaging server can communicate on port 5060/TCP, which is unsecured, or on port 5061/TCP, which is secured, but not on both. With Exchange 2007 Service Pack 1 (SP1), a Unified Messaging server listens on port 5060/TCP and on port 5061/TCP at the same time.

For more information, see Understanding Unified Messaging VoIP Security and Understanding Protocols, Ports, and Services in Unified Messaging.

Return to top

Using the Security Configuration Wizard to Secure Windows for Exchange Server Roles

This section explains how to use the Security Configuration Wizard (SCW) to minimize the attack surface for servers by disabling Windows functionality that is not required for Exchange 2007 server roles.

Using the Security Configuration Wizard

Exchange 2007 provides an SCW template for each Exchange 2007 server role. By using this template with the SCW, you can configure the Windows operating system to lock down services and ports that are not needed for each Exchange server role. When you run the SCW, you create a custom security policy for your environment. You can apply the custom policy to all Exchange servers in your organization. You can configure the following functionality by using the SCW:

  • Server role   The SCW uses the server role information to enable services and open ports in the local firewall.

  • Client features   Servers also act as clients to other servers. Select only the client features that are required for your environment.

  • Administration options   Select the options that are required for your environment, such as backup and error reporting.

  • Services   Select the services that are required for the server, and set the startup mode for services that are not specified by the policy. Unspecified services are not installed on the selected server and are not listed in the security configuration database. The security policy that you configure might be applied to servers that are running different services than the server where the policy is created. You can select the policy setting that determines the action to perform when an unspecified service is found on a server that this policy is applied to. You can set the action not to change the startup mode of the service or disable the service.

  • Network security   Select the ports to open for each network interface. Access to ports can be restricted based on the local network interface or based on remote IP addresses and subnets.

  • Registry settings   Use the registry settings to configure protocols that are used to communicate with other computers.

  • Audit policy   The audit policy determines which success and failure events are logged and the file system objects that are audited.

Using the Exchange Server 2007 SCW Template

After you install an Exchange server role, follow these steps to configure a security policy by using the SCW:

  1. Install the SCW.

  2. Register the SCW extension.

  3. Create a custom security policy and apply the policy to the local server.

  4. If you have more than one Exchange server in your organization running a given role, you can apply your custom security policy to each Exchange server.

The following sections provide procedures for each of the previous steps.

To perform the following procedures, the account you use must be delegated the following:

  • Exchange Server Administrator role and local Administrators group for the target server

To perform the following procedures on a computer that has the Edge Transport server role installed, you must log on by using an account that is a member of the local Administrators group on that computer.

For more information about permissions, delegating roles, and the rights that are required to administer Exchange 2007, see Permission Considerations.

Installing the Security Configuration Wizard

You must perform this procedure on each Exchange 2007 server to which you want to apply a SCW security policy by using the SCW.

To install the Security Configuration Wizard

  1. In Control Panel, click Add or Remove Programs.

  2. Click Add/Remove Windows Components to start the Windows Components Wizard.

  3. In the Windows Components dialog box, select the Security Configuration Wizard check box, and then click Next.

  4. Wait for the installation to complete, and then click Finish.

To open the SCW after you perform this procedure, click Start, point to All Programs, point to Administrative Tools, and then click Security Configuration Wizard.

Registering Exchange Server Role SCW Extensions

The Exchange Server role extensions enable you to use the SCW to create a security policy that is specific to the functionality that is required for each Microsoft Exchange server role. The extensions are provided with Exchange 2007 and must be registered before you can create a custom security policy.

You must perform the registration procedure on each Exchange 2007 server to which you want to apply an SCW security policy. Two extension files are required for the various Exchange 2007 server roles. For the Mailbox, Hub Transport, Unified Messaging, and Client Access server roles, register the Exchange2007.xml extension file. For the Edge Transport server role, register the Exchange2007Edge.xml extension file.

Note:
The Exchange 2007 SCW extension files are located in the %Exchange%\Scripts directory. The default Exchange installation directory is Program Files\Microsoft\Exchange Server. This directory location may be different if you selected a custom directory location during server installation.
Important:
If you have installed Exchange 2007 in a custom installation directory, SCW registration still works. However, to enable the SCW, you must perform manual workarounds to recognize the custom installation directory. For more information, see Microsoft Knowledge Base article 896742, After you run the Security Configuration Wizard in Windows Server 2003 SP1, Outlook users may not be able to be unable to connect to their accounts.
To register the Security Configuration Wizard extension on a computer running the Mailbox, Hub Transport, Unified Messaging, or Client Access server role

  1. Open a Command Prompt window. Type the following command to use the SCW command-line tool to register the Exchange 2007 extension with the local security configuration database:

    Copy Code 
    scwcmd register /kbname:Ex2007KB /kbfile:"%programfiles%\Microsoft\Exchange Server\scripts\Exchange2007.xml"

  2. To verify that the command has completed successfully, you can view the SCWRegistrar_log.xml file that is located in the %windir%\security\msscw\logs directory.

To register the Security Configuration Wizard extension on a computer running the Edge Transport server role

  1. Open a Command Prompt window. Type the following command to use the SCW command-line tool to register the Exchange 2007 extension with the local security configuration database:

    Copy Code 
    scwcmd register /kbname:Ex2007EdgeKB /kbfile:"%programfiles%\Microsoft\Exchange Server\scripts\ Exchange2007Edge.xml"

  2. To verify that the command has completed successfully, you can view the SCWRegistrar_log.xml file that is located in the %windir%\security\msscw\logs directory.

Creating a New Exchange Server Role SCW Policy

Use this procedure to create a custom security policy for your specific environment. After you create a custom policy, you use the policy to apply the same level of security to each Exchange 2007 server that is running the same server role or roles in your organization.

Note:
Some of the steps in the following procedure don't provide specific configuration details for all the pages in the Security Configuration Wizard. In these cases, we recommend that you keep the default selections if you are not sure which services or features to enable. As with all content in the Exchange 2007 Help file, the most up-to-date information about how to use the SCW with Exchange 2007 can be found at the Exchange Server TechCenter.
To use the Security Configuration Wizard to create a custom security policy

  1. Click Start, point to All Programs, point to Administrative Tools, and then click Security Configuration Wizard to start the tool. Click Next on the welcome screen.

  2. On the Configuration Action page, select Create a new security policy, and then click Next.

  3. On the Select Server page, verify that the correct server name appears in the Server (use DNS name, NetBIOS name, or IP address): field. Click Next.

  4. On the Processing Security Configuration Database page, wait for the progress bar to complete, and then click Next.

  5. On the Role-Based Service Configuration page, click Next.

  6. On the Select Server Roles page, select the Exchange 2007 roles that you have installed on the computer, and then click Next.

  7. On the Select Client Features page, select each client feature that is required on your Exchange server, and then click Next.

  8. On the Select Administration and Other Options page, select each administration feature that is required on your Exchange server, and then click Next.

  9. On the Select Additional Services page, select each service that is required to be enabled on the Exchange server, and then click Next.

  10. On the Handling Unspecified Services page, select the action to perform when a service that is currently not installed on the local server is found. You can select to take no action by selecting Do not change the startup mode of the service, or you can select to automatically disable the service by selecting Disable the service. Click Next.

  11. On the Confirm Service Changes page, review the changes that this policy will make to the current service configuration. Click Next.

  12. On the Network Security page, verify that Skip this section is not selected, and then click Next.

  13. On the Open Ports and Approve Applications page, if you are running the SCW on an Edge Transport server, you must add two ports for LDAP communication to Active Directory Application Mode (ADAM).

    1. Click Add. On the Add Port or Application page, in the Port number: field, enter 50389. Select the TCP check box, and then click OK.

    2. Click Add. On the Add Port or Application page, in the Port number: field, enter 50636. Select the TCP check box, and then click OK.

  14. (Edge Transport server only) On the Open Ports and Approve Applications page, you must configure the ports for each network adapter.

    1. Select Port 25, and then click Advanced. On the Port Restrictions page, click the Local Interface Restrictions tab. Select Over the following local interfaces:, select both the internal network adapter and external network adapter check boxes, and then click OK.

    2. Select Port 50389, and then click Advanced. On the Port Restrictions page, click the Local Interface Restrictions tab. Select Over the following local interfaces:, select only the internal network adapter check box, and then click OK.

    3. Select Port 50636, and then click Advanced. On the Port Restrictions page, click the Local Interface Restrictions tab. Select Over the following local interfaces:, select only the internal network adapter check box, and then click OK.

    Note:
    You can also configure remote address restrictions for each port.

  15. On the Open Ports and Approve Applications page, click Next.

  16. On the Confirm Port Configuration page, verify that the incoming port configuration is correct, and then click Next.

  17. On the Registry Settings page, select the Skip this section check box, and then click Next.

  18. On the Audit Policy page, select the Skip this section check box, and then click Next.

  19. On the Internet Information Services (IIS) page, select the Skip this section check box, and then click Next.

  20. On the Save Security Policy page, click Next.

  21. On the Security Policy File Name page, enter a file name for the security policy and an optional description. Click Next. If a restart of the server is required after the policy is applied, a dialog box will appear. Click OK to close the dialog box.

  22. On the Apply Security Policy page, select Apply later or Apply now, and then click Next.

  23. On the Completing the Security Configuration Wizard page, click Finish.

How to Apply an Existing SCW Policy to an Exchange Server Role

After you have created the policy, you can then apply it to multiple computers that are running the same role in your organization.

To use the Security Configuration Wizard to apply an existing policy

  1. Click Start, point to All Programs, point to Administrative Tools, and then click Security Configuration Wizard to start the tool. Click Next on the welcome screen.

  2. On the Configuration Action page, select Apply an existing security policy. Click Browse, select the XML file for your policy, and then click Open. Click Next.

  3. On the Select Server page, verify that the correct server name appears in the Server (use DNS name, NetBIOS name, or IP address): field. Click Next.

  4. On the Apply Security Policy page, click View Security Policy if you want to view the policy details, and then click Next.

  5. On the Applying Security Policy page, wait until the progress bar indicates Application complete, and then click Next.

  6. On the Completing the Security Configuration Wizard page, click Finish.

Return to top

Appendix 1: Services and Port Executables Enabled by the Exchange 2007 SCW Registration Files

The Security Configuration Wizard (SCW) uses XML registration files to help you configure the Windows operating system to operate with other applications. The registration files that the SCW uses define the security configuration that is required to operate a specific application. At a minimum, the security configuration defines the services and ports that are required for a specific application.

This topic describes the services and ports that are enabled for each Exchange 2007 server role when you run the SCW with the default Exchange 2007 registration files.

Registration Files

Exchange 2007 includes two registration files for SCW. The general Exchange 2007 registration file is called Exchange2007.xml. It defines the security configuration for all Microsoft Exchange server roles, except the Edge Transport server role. The registration file for the Edge Transport server role is called Exchange2007Edge.xml. It defines the security configuration for Edge Transport servers.

The registration files are installed in the %Programfiles%\Microsoft\Exchange Server\Scripts directory when you install Exchange 2007.

Services that are enabled set the service startup value to either Automatic or Manual.

Ports that are enabled specify executable files (.exe) that are trusted by Windows Firewall to open ports for the specific application.

The Exchange 2007 registration files that are used by the SCW specify the port executables according to their default location. In most cases, the default location is at %Programfiles%\Microsoft\Exchange Server\bin. If you have installed Exchange into a different location, you must edit the <Path> value in the <Port> section of the Exchange 2007 registration files to indicate the correct installed location.

Mailbox Server Role

The following services are enabled by the Exchange 2007 registration file (Exchange2007.xml) for the Mailbox server role.

The Microsoft Search (Exchange Server) service and Microsoft Exchange Monitoring are set to start manually. All other services are set to start automatically.

Service short name Service name

MSExchangeIS

Microsoft Exchange Information Store

MSExchangeADTopology

Microsoft Exchange Active Directory Topology

MSExchangeRepl

Microsoft Exchange Replication Service

MSExchangeMailboxAssistants

Microsoft Exchange Mailbox Assistants

MSExchangeSearch

Microsoft Exchange Search Indexer

MSExchangeServiceHost

Microsoft Exchange Service Host

MSExchangeMonitoring

Microsoft Exchange Monitoring

MSExchangeSA

Microsoft Exchange System Attendant

MSExchangeMailSubmission

Microsoft Exchange Mail Submission Service

msftesql-Exchange

Microsoft Search (Exchange Server)

The following ports are enabled.

Port name Associated executable file

MSExchangeADTopologyPorts

MSExchangeADTopologyService.exe

MSExchangeISPorts

Store.exe

MSExchangeReplPorts

Microsoft.Exchange.Cluster.ReplayService.exe

MSExchangeMailboxAssistantsPorts

MSExchangeMailboxAssistants.exe

MSExchangeSearchPorts

Microsoft.Exchange.Search.ExSearch.exe

MSExchangeServiceHostPorts

Microsoft.Exchange.ServiceHost.exe

MSExchangeMonitoringPorts

Microsoft.Exchange.Monitoring.exe

MSExchangeSAPorts

Mad.exe

MSExchangeMailSubmissionPorts

MSExchangeMailSubmission.exe

msftesql-ExchangePorts

Msftesql.exe

MSExchangeTransportLogSearchPorts

MSExchangeTransportLogSearch.exe

Clustered Mailbox Server Role

The services and ports that are enabled on the Mailbox server role and described in the Mailbox Server Role section earlier in this topic are enabled on the clustered mailbox server role.

Additionally, the Microsoft Cluster Service is set to start automatically.

Service short name Service name

ClusSvc

Microsoft Cluster Service

The following ports are also enabled.

Note:
The default path for cluster-specific executables is %windir%\Cluster. The default path for the Powershell.exe is %windir%\system32\windowspowershell\v1.0.

Port name Associated executable file

ExSetupPorts

ExSetup.exe

clussvcPorts

Clussvc.exe

CluAdminPorts

CluAdmin.exe

resrcmonPorts

Resrcmon.exe

msftefdPorts

Msftefd.exe

powershellPorts

Powershell.exe

Hub Transport Server Role

The following services are enabled by the Exchange 2007 registration file (Exchange2007.xml) for the Hub Transport server role.

Microsoft Exchange Monitoring is set to start manually. All other services are set to start automatically.

Service short name Service name

MSExchangeADTopology

Microsoft Exchange Active Directory Topology service

MSExchangeTransport

Microsoft Exchange Transport service

MSExchangeAntispamUpdate

Microsoft Exchange Anti-spam Update service

MSExchangeEdgeSync

Microsoft Exchange EdgeSync service

MSExchangeTransportLogSearch

Microsoft Exchange Transport Log Search service

MSExchangeMonitoring

Microsoft Exchange Monitoring

The following ports are enabled.

Port name Associated executable file

MSExchangeADTopologyPorts

MSExchangeADTopologyService.exe

MSExchangeTransportPorts

MSExchangeTransport.exe

EdgeTransportPorts

EdgeTransport.exe

MSExchangeAntispamUpdatePorts

Microsoft.Exchange.AntispamUpdateSvc.exe

MSExchangeEdgeSyncPorts

Microsoft.Exchange.EdgeSyncSvc.exe

MSExchangeTransportLogSearchPorts

MSExchangeTransportLogSearch.exe

MSExchangeMonitoringPorts

Microsoft.Exchange.Monitoring.exe

Edge Transport Server Role

The following services are enabled by the registration file for the Edge Transport server role (Exchange2007Edge.xml).

Microsoft Exchange Monitoring and the Microsoft Exchange Transport Log Search service are set to start manually. All other services are set to start automatically.

Service short name Service name

MSExchangeTransport

Microsoft Exchange Transport service

MSExchangeAntispamUpdate

Microsoft Exchange Anti-spam Update service

ADAM_MSExchange

Microsoft Exchange ADAM

EdgeCredentialSvc

Microsoft Exchange Credential Service

MSExchangeTransportLogSearch

Microsoft Exchange Transport Log Search service

MSExchangeMonitoring

Microsoft Exchange Monitoring

The following ports are enabled.

Note:
The default path for Dsadmin.exe is %windir%\ADAM.

Port name Associated executable file

MSExchangeTransportPorts

MSExchangeTransport.exe

EdgeTransportPorts

EdgeTransport.exe

MSExchangeAntispamUpdatePorts

Microsoft.Exchange.AntispamUpdateSvc.exe

ADAM_MSExchangePorts

Dsamain.exe

EdgeCredentialSvcPorts

EdgeCredentialSvc.exe

MSExchangeTransportLogSearchPorts

MSExchangeTransportLogSearch.exe

MSExchangeMonitoringPorts

Microsoft.Exchange.Monitoring.exe

Client Access Server Role

The following services are enabled by the Exchange 2007 registration file (Exchange2007.xml) for the Client Access server role.

Microsoft Exchange Monitoring, the Microsoft Exchange POP3 service, and the Microsoft Exchange IMAP4 service are set to start manually. All other services are set to start automatically.

Service short name Service name

MSExchangeADTopology

Microsoft Exchange Active Directory Topology service

MSExchangePOP3

Microsoft Exchange POP3 service

MSExchangeIMAP4

Microsoft Exchange IMAP4 service

MSExchangeFDS

Microsoft Exchange File Distribution service

MSExchangeServiceHost

Microsoft Exchange Service Host

MSExchangeMonitoring

Microsoft Exchange Monitoring

The following ports are enabled.

Note:
The default path for the Pop3Service.exe and the Imap4Service.exe files is %Programfiles%\Microsoft\Exchange Server\ClientAccess\PopImap.

Port name Associated executable file

MSExchangeADTopologyPorts

MSExchangeADTopologyService.exe

MSExchangePOP3Ports

Microsoft.Exchange.Pop3Service.exe

MSExchangeIMAP4Ports

Microsoft.Exchange.Imap4Service.exe

MSExchangeFDSPorts

MSExchangeFDS.exe

MSExchangeServiceHostPorts

Microsoft.Exchange.ServiceHost.exe

MSExchangeMonitoringPorts

Microsoft.Exchange.Monitoring.exe

Unified Messaging Server Role

The following services are enabled by the Exchange 2007 registration file (Exchange2007.xml) for the Unified Messaging server role.

Microsoft Exchange Monitoring is set to start manually. All other services are set to start automatically.

Service name Friendly name

MSExchangeADTopology

Microsoft Exchange Active Directory Topology service

MSSpeechService

Microsoft Exchange Speech Engine

MSExchangeUM

Microsoft Exchange Unified Messaging

MSExchangeFDS

Microsoft Exchange File Distribution Service

MSExchangeMonitoring

Microsoft Exchange Monitoring

The following ports are enabled.

Note:
The default path for the SpeechService.exe file is %Programfiles%\Microsoft\Exchange Server\UnifiedMessaging.

Port name Associated executable file

MSExchangeADTopologyPorts

MSExchangeADTopologyService.exe

MSSPorts

SpeechService.exe

MSExchangeUMPorts

umservice.exe

UMWorkerProcessPorts

UMWorkerProcess.exe

MSExchangeFDSPorts

MSExchangeFDS.exe

MSExchangeMonitoringPorts

Microsoft.Exchange.Monitoring.exe

Return to top

Appendix 2: Additional Security-Related Exchange Documentation

This section contains links to additional security-related Exchange documentation. For the most up-to-date list of security-related content, see Security and Protection.

Anti-Spam and Antivirus Functionality

Client Authentication and Access Security

Microsoft Office Outlook Web Access

Outlook Anywhere

POP3 and IMAP4

Permissions

Protecting Mail Flow

Return to top