If you would like to read the other parts in this article series please go to:
- Outlook Web Access Security Features (Part 2)
- Outlook Web Access Security Features (Part 3)
- Outlook Web Access Security Features (Part 4)
- Outlook Web Access Security Features (Part 5)
Introduction
In this multi-part article I want to cover the security features that are available in Outlook Web Access (OWA) in Exchange 2007. With OWA 2007, there are many security enhancements over previous versions of Exchange and therefore these security considerations should be addressed during the design phase of your Exchange 2007 deployment. Let us get going straight away and see what is on offer.
Client Access Server Location
Let us start this article by covering a fundamental part of Exchange 2007 OWA security, namely the security of the server responsible for providing OWA, the Client Access Server. With Exchange 2000 and Exchange 2003, the front-end server role is loosely similar to the Client Access Server role in Exchange 2007. It was sometimes the case that organizations deployed the front-end server role into a perimeter network based on the notion that this particular role was suited to that location, with the front-end server then performing a connection to the back-end mailbox server. However, such a configuration often proved controversial as there were also those who argued that locating the front-end server into a perimeter network required that many additional ports were opened on the firewall separating the perimeter network with the internal network housing the back-end mailbox server. With Exchange 2007, it should be noted that Microsoft does not support locating the Client Access Server in a perimeter network so this factor should be taken into account when planning the location of Client Access Servers.
With that covered, let us now move onto the other key areas of OWA security starting with Secure Sockets Layer (SSL) encryption and the certificates used for this purpose.
Secure Sockets Layer
One of the big changes in security for OWA in Exchange 2007 has been the fact that SSL encryption is enabled by default and to achieve encryption via SSL, Exchange 2007 makes use of digital certificates. You might ordinarily associate the term digital certificate with 3rd party certificate authorities such as Verisign, or perhaps with an internal certificate authority that is integrated with the Active Directory environment. Whilst this is correct, the default SSL certificate that is generated by Exchange 2007 during installation is actually a self-signed certificate. This means that, whilst 3rd party certificate authorities will sign certificates that it issues, the self-signed certificates issued by Exchange 2007 are, as the name implies, signed by Exchange 2007 itself.
Figure 1 shows a self-signed certificate that has been issued by an Exchange 2007 server with a NetBIOS name of CCR-SRV1. Figure 2 shows the same certificate but this time the focus is on the Subject Alternative Name field of the certificate.
Figure 1: General Tab of a Self-Signed Exchange 2007 Certificate
Figure 2: Subject Alternative Name Field of a Self-Signed Exchange 2007 Certificate
You can see from Figure 2 that the certificate has a Subject Alternative Name field set with not only the NetBIOS name of the server, but also the Fully Qualified Domain Name (FQDN). Also, you can see from Figure 1 that the self-signed certificate is not trusted by default in the same way that 3rd party certificates would be. In other words, you would need to copy this certificate to the Trusted Root Certificate Store on each computer from where you planned to connect to the Client Access Server, such as when using Outlook Web Access from the browser on a PC. If you do not do this, you will receive the certificate warning prompt that you can see in Figure 3.
Figure 3: Browser Certificate Trust Warning Prompt
If you do not mind the fact that you will receive the aforementioned certificate prompt, it is actually possible to use the self-signed certificate when using OWA to access your mailbox. However, you should note that other client access methods, such as Outlook Anywhere, do not work with the self-signed certificate so you may be better off deploying a certificate from a 3rd party certificate authority from the beginning, or possibly from an internal certificate authority. We will discuss the certificate authority options in greater detail later in this article. The other main issue with the self-signed certificate is the fact that they are more difficult to manage in general. For example, self-signed certificates are only valid for 1 year with Exchange 2007 Service Pack 1, after which time you must renew them via the New-ExchangeCertificate cmdlet. It can sometimes be problematic for an administrator to remember when these certificates are going to expire although monitoring technologies such as System Center Operations Manager (SCOM) can help address this issue. Certificates supplied by either 3rd party or Active Directory certificate authorities can have longer expiration timescales, such as 3 years for example.
The fact that an SSL certificate is installed by default on the Client Access Server role allows the use of SSL encryption between the client and the Client Access Server when using the protocols that the Client Access Server supports, such as HTTP, POP3 and so on. This is achieved by the various virtual directories created in Internet Information Services (IIS) on the Client Access Server requiring SSL encryption. You can see this if you examine the properties of the various virtual directories. For example, Figure 4 shows the properties of the /owa virtual directory running in IIS6 on a Windows 2003 server.
Figure 4: SSL Requirements For /owa Virtual Directory
Certificate Authorities
Although this is an article series covering OWA security in Exchange 2007, I feel that it is important to break out for a short while and discuss certificate authorities. As mentioned earlier in this article, it is possible to use the self-signed certificates that are supplied by default in Exchange 2007 or use certificates from another source. These other sources include an internal Microsoft certificate authority, an internal certificate authority based on non-Microsoft technology, or a 3rd party certificate authority such as Verisign, GoDaddy and so on. Of course, the use of 3rd party certificates depends largely on the server role that is being protected. For example, assume that an organization has a URL of https://webmail.neilhobson.com that provides external access to OWA from remote locations and that the Client Access Server responsible for external OWA access is protected by ISA Server 2006. It will likely be most appropriate to deploy a certificate on the ISA Server for the external OWA URL from a 3rd party certificate authority in order to ensure that, no matter which client PCs and browsers are being used for OWA access, there are no certificate trust issues involved. However, the certificate for the Client Access Server need not be purchased from the same 3rd party certificate authority as it is the ISA Server that will be communicating with the Client Access Server directly and not external client PCs. Therefore, it is sometimes the case that organizations deploy certificates issued from an internal certificate authority onto the actual Client Access Server.
Clearly there is a cost involved with purchasing 3rd party certificates whereas those issued by an internal certificate authority are free once the cost of designing and installing the internal certificate authority have been recovered. Additionally, it is much easier to create and assign certificates from an internal certificate authority and have them re-issued if there are any problems. For example, a Client Access Server certificate requires many additional names listed in the Subject Alternate Name field and it is quite possible that you may forgot to include one of these names in the initial certificate request.
There are many organizations out there, particularly smaller organizations, which have not installed an internal Microsoft certificate authority that integrates into the Active Directory environment. Therefore, when installing Exchange 2007 for the first time, these organizations must decide whether they are going to continue using the Exchange 2007 self-signed certificates, or whether they are going to obtain their digital certificates from a 3rd party certificate authority. The other option is, of course, to deploy an internal certificate authority and the most obvious option is to deploy one using Microsoft Certificate Services.
Deploying an Exchange 2007 infrastructure is not the only reason to consider the deployment of an internal certificate authority based on Microsoft technology. Other Microsoft products, such as Office Communications Server, System Center Operations Manager and System Center Configuration Manager also make use of certificates. Therefore, if you don’t currently have an internal certificate authority it might be worth taking the time to consider the advantages of having one deployed and operational.
Summary
This completes part one of this article series on OWA security in Exchange 2007. We have spent most of this article covering SSL certificates which is justified as these are vital to OWA 2007 security. In the next part of this article series, we will be taking a look at OWA authentication methods, such as forms-based authentication as well as the ‘standard’ authentication methods such as Integrated Windows authentication.
If you would like to read the other parts in this article series please go to:
