Securing an Exchange Server 2010 Environment : Securing Outlook 2007

Exchange Server 2010 and Microsoft Outlook 2007 were designed to work together and, therefore, are tightly integrated. Utilizing these two products together can provide a formidable security front.

Outlook Anywhere

Prior to Exchange Server 2003, Outlook users who needed to connect to Exchange Server over the Internet had to establish a virtual private network (VPN) connection prior to using Outlook. The only alternatives were to open a myriad of remote procedure calls (RPC) ports to the Internet or make Registry modifications to statically map RPC ports. However, most companies felt that the benefits provided by these two “workarounds” were outweighed by the risks.

With Exchange Server 2003 and Outlook 2003, Microsoft provided an alternate (and very much improved) method for Outlook users to connect over the Internet. Known as RPC over HTTPS, this feature allowed Outlook 2003 users to access their mailboxes securely from remote locations utilizing the Internet and an HTTPS proxy connection. This feature reduced the need for VPN solutions, while still keeping the messaging environment secure.

In Exchange Server 2010, this functionality is known as Outlook Anywhere, and Microsoft has improved the functionality and greatly reduced the difficulty of deployment and management of the feature.

Outlook Anywhere can be used with both Outlook 2003 through 2010 clients and provides the following benefits:

• Users can access Exchange servers remotely from the Internet.

• Organizations can use the same URL and namespace that is used for Exchange ActiveSync and Outlook Web App.

• Organizations can use the same SSL server certificate that is used for Outlook Web App and Exchange ActiveSync.

• Unauthenticated requests from Outlook are blocked and cannot access Exchange servers.

• Clients must trust server certificates, and certificates must be valid.

• No VPN is needed to access Exchange servers across the Internet.

Note

For a Windows client to use this feature, the system must be running Windows XP SP1 or higher.

Preparing Your Environment for Outlook Anywhere

Enabling Outlook Anywhere in an Exchange Server 2010 environment is a very straightforward process, and can be done using either the Exchange Management Console or the Exchange Management Shell. However, prior to enabling the product, you must install a valid SSL certificate from a trusted certificate authority (CA).

Note

When you install Exchange Server 2010, you have the option of installing a default SSL certificate that is created during the Exchange Server setup process. However, this certificate is not a trusted SSL certificate. It is recommended that you either install your own trusted self-signed SSL certificate, or trust the default SSL certificate that is created during the Exchange Server setup process.

Enabling Outlook Anywhere from the Exchange Management Console

After installing a valid SSL certificate, Outlook Anywhere can be easily enabled from the Exchange Management Console by following these steps:

1.	Start the Exchange Management Console. In the console tree, expand the Server Configuration node, and then select the Client Access node.
2.	Select the CAS server that will host Outlook Anywhere and in the action pane, click Enable Outlook Anywhere. This starts the Enable Outlook Anywhere Wizard.
3.	In the External Host Name field, shown in Figure 1, type the appropriate external host name for your organization. Figure 1. Enabling Outlook Anywhere.
4.	Select the appropriate External Authentication Method, either Basic Authentication or NTLM Authentication.
5.	If you are using an SSL accelerator and want to allow SSL offloading, select the Allow Secure Channel (SSL) Offloading check box. Caution Do not use the Allow Secure Channel (SSL) Offloading option unless you are sure you have an SSL accelerator that can handle SSL offloading. Selecting the option when you do not have this functionality prevents Outlook Anywhere from functioning properly.
6.	Click Enable to apply the settings and enable Outlook Anywhere.
7.	Review the completion summary to ensure there were no errors, and then click Finish to close the wizard.
8.	These steps should be repeated for each CAS server that will host Outlook Anywhere.

Enabling Outlook Anywhere from the Exchange Management Shell

Alternatively, you can enable Outlook Anywhere from the Exchange Management Shell. To do so, run the following command from the shell:

enable-OutlookAnywhere -Server:'ServerName' -ExternalHostname:'ExternalHostName' -DefaultAuthenticationMethod:'Basic' -SSLOffloading:$false

					  

You can substitute “NTLM” for the DefaultAuthenticationMethod, and replace $false with $true if you are using SSL offloading.

Outlook Anywhere Best Practices

Consider the following best practices when deploying Outlook Anywhere:

• Use at least one client access server per site— In Exchange Server 2010, a site is considered to be a network location with excellent connectivity between all computers. You should have at least one client access server solely dedicated to providing client access to the Exchange Server 2010 server running the Mailbox server role. For increased performance and reliability, you can have multiple client access servers in each site.

• Enable Outlook Anywhere on at least one client access server— For each site, there should be at least one client access server with Outlook Anywhere enabled. This allows Outlook clients to connect to the client access server that resides closest to that user’s mailbox server. By configuring your environment in this manner, users connect to the client access server in the site with their mailbox server utilizing HTTPS. This minimizes the risk of using RPC across the Internet, which can negatively impact overall performance.

Finally, you must configure your organization’s firewall to allow traffic on port 443 because Outlook requests use HTTP over SSL. However, if you are already using either Outlook Web App with SSL, or Exchange ActiveSync with SSL, you do not have to open any additional ports from the Internet.

Tip

Outlook users who will be using Outlook Anywhere as described in this section should be using Cached Exchange mode. Cached Exchange mode optimizes the communications between your Exchange servers and Outlook.

Authenticating Users

By default, both Outlook 2003 and Outlook 2007/2010 use the credentials of the user who is currently logged on to the local computer to access the Outlook profile and mailbox. Both applications are also configured to first utilize Kerberos for the authentication process and, if this fails, utilize NT LAN Manager (NTLM). Administrators have the option of setting Outlook to only use Kerberos if they want to implement stronger security methods. The Kerberos/NTLM or NTLM Only options exist for backward compatibility with older systems. When using Kerberos, the user’s credentials are encrypted when communicating with Active Directory for authentication.

To view or change the current authentication options in Outlook 2007, perform the following procedure:

1.	In Outlook 2007, select Tools, Account Settings.
2.	On the Account Settings page, select the email account, and click the Change icon.
3.	On the Change E-Mail Account page, click More Settings.
4.	Select the Security tab. Under Logon Network Security, select Kerberos Password Authentication from the drop-down box, and then click OK.
5.	On the Change E-Mail Account page, click Next to complete the process, click Finish, and then click Close.

User Identification

An additional level of security can be applied to users accessing email through the Outlook client. In the event of a user closing Outlook, but not locking their computer or logging off the network, it is possible for an unauthorized user to access the system, start Outlook, and access the user’s email.

It is possible to configure Outlook 2007 to require the user to input their username and password before accessing Outlook. To do so, follow the same steps detailed previously in the “Authenticating Users” section, and place a check mark in the Always Prompt for User Name and Password check box.

It should be noted that few organizations implement this security option, as most find that logging on and off the system properly provides adequate protection.

Blocking Attachments

A common and often effective way for viruses and malicious scripts to spread from user to user is through email. When a user receives a message with an attachment, simply opening the attachment can allow the virus to activate and, if proper security measures are not in place, the virus can do damage to the system or spread to other users.

To mitigate this threat, Microsoft has incorporated attachment blocking in Outlook and Outlook Web App (OWA). By default, Outlook is configured to block attachments that contain file types that can run programs. Known as “executable” files, these blocked file types include those with .exe, .bat, .com, .vbs, and .js on the end of the filename.

It is important to note that this does not automatically protect you from being infected with a virus, as other file formats, including Microsoft Office files such as Word or Excel documents, can potentially contain viruses. However, implementing an antivirus solution on the client PC greatly reduces the possibility of such a file causing harm.

Users who are utilizing Outlook to send an attachment are notified when attaching an executable file that it is likely to be blocked by the recipient.

If the user elects to send the message anyway, it might still be blocked on the receiving end.

Outlook does not provide any way for the end user to unblock these attachments. However, savvy users have found that, in many instances, they can rename the file to a nonexecutable extension (such as .txt) and send the file with instructions on how to rename the file back.

Note

File types can be categorized as Level 1 (the user cannot view the file) or Level 2 (the user can open the file only after saving it to disk). By default, Outlook classifies most executable file types as Level 1 and blocks the receipt of the file by users. There are no Level 2 file types by default. However, administrators can use Group Policy to manage how a file type is categorized. For example, if members of your organization regularly receive Visual Basic scripts (.vbs), you can change the categorization from Level 1 to Level 2 for that extension. Extreme caution should be used before changing this setting, as executable attachments are one of the most commonly used methods of distributing viruses.