Security features of OWA (Part 1)

Network management - Outlook Web Access (OWA) was originally named Exchange Web Connect, which was the first integrated Webmail service in Microsoft Exchange Server 5.0 version and later continued by Microsoft. Use in the next version.

Outlook Web Access's web interface has an interface adapted to the interface of Microsoft Outlook. OWA is a tool to access Microsoft Outlook applications, access documents in Microsoft SharePoint sites and shared networks, etc. It also supports users to connect remotely via an application. Web browser.

Exchange 2007's Outlook Web Access in Exchange 2007 has improved many security features compared to previous versions. To help you have a more intuitive look, in this series we will explore some of the security features of OWA and how they work.

Locate Client Access Server

First, we will explore an important security feature of OWA in Exchange 2007 that is the server security that provides OWA named Client Access Server. In Exchange 2000 and Exchange 2003, the communication server is not the same as the Client Access Server in Exchange 2007. Sometimes there are cases where many systems deploy communication servers on an external network without knowing that the server is suitable for That location or not, though this communication server will then make a connection to the auxiliary mail server. However, such a configuration is often inappropriate because placing the communication server on an external network will require opening multiple additional ports on the firewall system to divide the external network from the internal network (containing the secondary mail server). support). Keep in mind that in Exchange 2007 it is not supported to set the Client Access Server to an external network so you need to calculate it before planning to allocate the Client Access Server.

Next, we will explore other important security features of OWA, starting with Secure Sockets Layer (SSL) encryption and certificates used for this purpose.

Secure Sockets Layer

One of the major security enhancements of OWA in Exchange 2007 is the ability to SSL encryption enabled by default. To perform encryption over SSL, Exchange 2007 uses digital certificates. Normally when referring to this term, we will think about third-party rights certificates such as Verisign, or a certificate that is compatible with the Active Directory environment. Although this evaluation is correct, the default SSL certificate created by Exchange 2007 during the installation process is actually a self-signed certificate. This means that third-party authorization certificates will issue certificates that it creates, self-issued certificates created by Exchange 2007 will be approved by Exchange 2007 itself.

---

Figure 1 shows a self-signed certificate that provides an Exchange 2007 server created with a NetBIOS name of CCR-SRV1. Figure 2 shows the Subject Alternative Name field of the same certificate type.

 

In Figure 2 you can see that the certificate has a Subject Alternative Name field set with the server's NetBIOS name and the Fully Qualified Domain Name (FQDN). In addition, Figure 1 also shows that this self-certification by default is not as reliable as third-party certificates. In other words, you need to copy this certificate to the Trusted Root Certificate Store on each computer from the location you intend to connect to the Client Access Server, such as when using OWA from a computer's browser application. If you do not copy this certificate, you will receive a warning as shown in Figure 3.



If you are not interested in the above warning, you can still use the self-signed certificate when using OWA to access the mailbox. However, keep in mind that other workstation access tools such as Outlook Anywhere will not work with a self-signed certificate so it is good to implement a certificate from a third-party certificate authority from the certificate authority. head, or maybe from an internal authority certificate. Another problem with the self-certification certification is that management is not simple. For example, self-signed certificates are only valid for one year with Exchange 2007 Service Pack 1, then you will have to refresh them with the New-ExchangeCertificate command. Sometimes administrators can forget the expiration of these certificates even if they have tools like System Center Operations Manager (SCOM) to help. Third-party certificates or Active Directory credentials may have longer validity periods.

In fact, an SSL certificate is installed by default on the Client Access Server which will allow the use of SSL encryption between the client and the Client Access Server when applying the protocols supported by Client Access Server such as HTTP, POP3, . You can perform this operation by using multiple virtual directories created in Internet Information Services (IIS) on the Client Access Server that requires SSL encryption. You can see this information in the properties of many virtual directories. For example, Figure 4 shows the / owa virtual directory running in IIS6 on a Windows 2003 server.

---

Certificate of decentralization

Although the purpose of this series is to explore security features in OWA in Exchange 2007, we also need to understand the certificate of authority. As mentioned earlier, we can use self-signed certificates in Exchange 2007 or use certificates from other sources. These other sources include an internal Microsoft certification, an internal certification from non-Microsoft tools, or a third-party certification such as Verisign, GoDaddy, etc. Of course, the use of certification Group 3 relies heavily on the server being protected. For example, suppose, a system with the URL address https://webmail.neilhobson.com provides external access to OWA from remote locations and that Client Access Server to support access. Remote OWA is protected by ISA 2006. It's best to deploy a certificate authority on the ISA server for the OWA URL outside the network from a third-party authority certificate to make sure that no one is using the workstation or browser application to access OWA. must be related to certification reliability. However, the certificate for the Client Access Server does not need to be purchased from the same third-party certificate authority because it is ISA Server that communicates directly with the Client Access Server and not the out-of-network client. Therefore, sometimes systems can deploy certificates created from an internal certificate authority for the real Client Access Server.

You can use specialized third-party certificates, but you should use internal authority certificates to easily create and certify, and can re-create when problems occur. For example, a Client Access Server certificate needs many additional names in the Subject Alternate Name field and you will probably forget to add these names to the original certificate request.

There are a lot of systems, especially small systems that do not have an internal Microsoft certificate compatible with the Active Directory environment. Therefore, the first time Exchange 2007 is installed, these systems need to consider using a self-signed certificate or using a digital certificate from a third-party certificate. Either deploy an internal certificate authority and, at best, deploy an internal certificate of authority using Microsoft Certificate Services.

Deploying an Exchange 2007 system is not the only reason to consider implementing an internal certificate authority based on Microsoft tools. Other Microsoft products, like Office Communications Server. System Center Operations Manager and System Center Configuration Manager also use these certificates.

Conclude

In this first part of the series, we have explored SSL certificates that are essential for OWA security in Exchange 2007. In the next part of this series we will explore authentication methods, such as authentication. forrm platform as well as standard authentication method such as Integrated Windows authentication.