Communications: Log onto Outlook Web Access with Smart Cards

Article
09/07/2016

Communications

Log onto Outlook Web Access with Smart Cards

Victor Akinnagbe and Ted Dressel and Jason Opdycke

At a Glance:

Two-factor authentication
Kerberos constrained delegation
ISA Server and Exchange configuration

Mobile employees present a unique security challenge for IT organizations. Remote users need secure access to data and services such as e-mail. The unfortunate reality, however, is that the most

vulnerable links in the security chain involve weak passwords, malware (such as key loggers), and viruses on the remote computers that are accessing your organization’s internal resources.

One way to increase security in this mobile environment is to remove one of those vulnerable links: passwords (though the idea of allowing access to an account without a password for authentication may seem disturbing). A primary technique for eliminating the problems associated with passwords is known as two-factor authentication (or sometimes multi-factor authentication). Rather than relying on a single method—a password—to enable access, two-factor authentication enforces the use of additional authentication methods, including a username/password combination, a physical device such as a smart card, or a biometric identifier such as a fingerprint.

If you have remote users, typically you’ll have to open up your firewall a bit to allow remote access to the corporate network. A standard firewall gives you basic risk mitigation by providing network-level isolation between the internal and external networks (see Figure 1). For added security, ports are simply closed off, and if communication needs to happen with a device on the internal network, ports are then forwarded to the right place. These techniques do provide substantial network-level protection, but now multiple layers of network security have become necessary due to the ever growing sophistication of attacks.

Figure 1 Standard firewall with ports blocked or forwarded

Figure 1** Standard firewall with ports blocked or forwarded **(Click the image for a larger view)

Since the most common corporate services mobile employees are likely to use are e-mail and messaging, configuring your Exchange infrastructure securely becomes more important than ever. Giving your users access to e-mail through Outlook® Web Access (OWA) is one way of providing secure services to mobile employees. Providing more secure two-factor authentication for OWA via smart cards is another key step. In this article, we take a closer look at the configuration and setup issues you should be aware of when enabling your own smart-card-enabled OWA deployment.

Better than a Firewall

Employing Microsoft® Internet Security and Acceleration (ISA) Server 2006 on your network can simplify the task of opening your network to remote users in a more secure manner. ISA Server 2006 includes security-enhancing features such as smart-card-enabled virtual private networking (VPN), Lightweight Directory Access Protocol (LDAP) authentication to Active Directory®, and Kerberos constrained delegation. ISA Server is a little bit different from what you might traditionally think of as a firewall. It provides multiple layers of security not only by functioning at the network layer—and it can do this in place of or in conjunction with standard firewall hardware—but also by providing additional security features not typically supported in traditional firewalls, such as application filters. Don’t want someone using the HTTP POST method to a particular hosted Web site? Want to force RFC compliance on SMTP messages before they touch your Exchange server? Want to inspect encrypted Secure Sockets Layer (SSL) HTTP packets before they come into the network? ISA Server can manage all of these tasks and more to ensure that only clean, filtered traffic is forwarded to your DMZ or internal network.

SSL sessions are something of a problem for standard firewalls. As packets pass through the firewall, they remain encrypted (which means that SSL is functioning correctly). Thus, if an application such as OWA is published through a hardware or software firewall using SSL, there is really no kind of appreciable inspection that can done by the standard firewall other than stateful packet inspection. Simply opening and forwarding ports can leave a substantial attack surface area exposed. Since no real inspection is happening at the edge, uninspected and unauthenticated packets could be routed into your internal network.

ISA Server 2006 can act as an SSL endpoint for HTTP clients, ensuring that only authenticated traffic reaches the published Exchange server. ISA Server supports a useful feature called SSL bridging. Typically, a packet is encrypted by a client that is communicating via a standard SSL session with ISA Server. With SSL bridging, ISA Server can terminate the SSL encryption locally, inspect the now unencrypted packet, authenticate the user to Active Directory (if necessary), re-encrypt the packet using SSL, and pass the encrypted packet on to the appropriate Exchange server (see Figure 2). Using this technique, SSL bridging mitigates attacks hidden within an SSL session that would look like nothing more than encrypted blobs of data to a firewall that is not application-aware.

Figure 2 ISA Server takes an application layer view of traffic

Figure 2** ISA Server takes an application layer view of traffic **(Click the image for a larger view)

Preauthenticated traffic reaching the server is an important point to note when speaking of Kerberos constrained delegation. In a standard firewall, ports are simply forwarded to the Exchange server and the front-end server itself is responsible for performing authentication tasks against what could be malicious users. When authentication is required, ISA Server can directly contact Active Directory and make the request for credentials on behalf of the user. If the user is authenticated successfully, ISA Server will forward the message to the Exchange front-end server. The front-end server no longer has to authenticate random unknown user requests and can be used solely for proxying requests to the back-end servers. ISA Server 2006 can also use Kerberos constrained delegation to enable certificate-based access to technologies like Windows SharePoint Services and Exchange ActiveSync.

Exchange Server 2003 included support for Kerberos-based authentication between front-end and back-end servers for OWA logins. (You are using IPsec to protect that client traffic, aren’t you?) Exchange Server also supports Kerberos authentication to clustered mailbox servers.

Enabling Smart Card Authentication

Implementing smart-card-based authentication for OWA has been a challenge. However, a solution has been developed based on the Kerberos constrained delegation feature now available in ISA Server 2006. The solution allows a user to submit credentials via a certificate in order to successfully authenticate to OWA. Kerberos constrained delegation comes as a welcome improvement over the Kerberos delegation support in Windows® 2000, which used unconstrained delegation. The constrained function of Kerberos is more secure and limits the potential risk of sophisticated attacks using impersonation.

In the smart-card-enabled scenario, ISA Server 2006 contacts Active Directory to authenticate the user since the user does not have routable access to a Key Distribution Center (KDC) from the external network. ISA Server defers to Active Directory certificate-user mapping to authenticate the user and then acquires the respective Kerberos tickets based on the User Principal Name (UPN). In this case, ISA Server is providing Kerberos constrained delegation functionality to an Exchange front-end server via application-level filtering and reverse proxy services. If delegation is attempted without a reverse proxy, the increased risk for exploits could affect the integrity of the network or Active Directory domain.

Exchange Server 2003 and Exchange Server 2007 both allow for Basic and Integrated authentication. However, you need to apply a software update to Exchange Server 2003 for smart-card-based authentication to OWA to work. (For more information, see the article "Description of the New Feature in Exchange Server 2003 that Supports Smart Card Authentication to Outlook Web Access".) You must have a domain in the Windows Server® 2003 Native functional mode, all involved Exchange Server 2003 servers must have SP2 or later applied, and you need an ISA Server 2006 server acting as a reverse proxy for the OWA site.

After you install the software update and configure your ISA and Exchange servers, users can authenticate an OWA session using smart cards. Figure 3 shows the flow of events required for smart card authentication. A user begins by opening the OWA site in Internet Explorer® (1). In fact, the user actually connects to ISA Server and is prompted for a certificate instead of a username and password to start the OWA session. The appropriate certificate is stored on the smart card, for which the user needs a PIN.

Figure 3 Authenticating OWA with a smart card

Figure 3** Authenticating OWA with a smart card **(Click the image for a larger view)

Certificate validation (2) is handled via a Certificate Revocation List (CRL) or an Online Certificate Status Protocol (OCSP) request, depending on the configuration of ISA Server and other installed software. ISA Server makes a request to a domain controller (DC) to verify the user’s credentials. If the request fails, ISA Server provides an error page to the user and no request gets to the Exchange front-end server.

After the credentials are verified, the Kerberos ticket is generated and the request is passed to the Exchange front-end server using integrated authentication (3). When the Exchange front-end server receives the request, it validates the Kerberos ticket and locates the user’s back-end mailbox server (4).

The front-end server requests a Kerberos ticket for the appropriate back-end server via Kerberos constrained delegation and proxies the mailbox request to the back-end server using integrated authentication (5). The request is serviced by the back-end server (6) and the mailbox data is returned to the Exchange front-end server (7). The HTML data for the OWA page is passed to ISA Server (8), which then passes it back to the client machine (9).

Configuring the Exchange Environment

The Knowledge Base article that was mentioned earlier describes the software update for Exchange Server 2003 and includes information that will help guide you through the process of enabling Kerberos constrained delegation using ISA Server 2006 and Exchange Server 2003.

The main action the software update enables is automating the process of Kerberos constrained delegation from the Exchange front-end server to the respective back-end servers. The update will not automate the process of Kerberos constrained delegation from ISA Server to the front-end server since ISA Server is not part of the Exchange organization. That delegation will have to be enabled manually from each ISA Server instance to each Exchange front-end server.

The software update adds a new tab in Exchange System Manager (ESM) that enables you to designate an Exchange front-end server as a KCD-FE (see Figure 4), which in turn allows that server to be populated in the delegation tab of the respective Exchange back-end servers.

Figure 4 Enabling Kerberos constrained delegation

Figure 4** Enabling Kerberos constrained delegation **

The new UI also enables you to specify in the properties of the Administrative Group which credentials to use for populating the msDS-AllowedToDelegateTo (A2D2) attribute, as shown in Figure 5. This is the attribute that is responsible for Kerberos constrained delegation.

Figure 5 Setting the account that controls delegation

Figure 5** Setting the account that controls delegation **

Respecting the principle of least privilege, you can use a standard user account and grant it the ability to delegate users and computers via a Group Policy Object (GPO). After the account has been granted this elevated permission, it can be used as a service account to automate the Kerberos constrained delegation process for the respective Administrative Group.

Make sure you take the proper steps to ensure that a malicious user will not be able to compromise the Kerberos constrained delegation service account. Even if the account is not a domain administrator, access to it could lead to sophisticated attacks by taking advantage of Kerberos delegation. Since the account will have the ability to establish new Kerberos associations, it should be used with care. Take the necessary precautions in order to ensure the security and integrity of that account: a long, complex password, increased auditing, account disablement techniques, and so on.

The Exchange software update also makes a very important change to the ESM interface regarding integrated authentication. Previously in Exchange Server 2003, when a server was designated as a front-end server, the option for enabling Integrated Windows Authentication for HTTP Virtual Directories (under the HTTP Virtual Server) was grayed out (see Figure 6).

Figure 6a The update enables integrated authentication

Figure 6a** The update enables integrated authentication **

Figure 6b The update enables integrated authentication

Figure 6b** The update enables integrated authentication **

This occurred because integrated authentication was not supported on Exchange front-end servers due to technical issues such as the fact that proxy servers interrupted NTLM sessions, users employing Kerberos authentication needed a connection to Active Directory, and Internet users were usually not part of the domain. The update described in the aforementioned Knowledge Base article removes these limitations. With the update installed, you can simply go to the virtual directory and check the box for Integrated Windows Authentication as the mechanism for verifying user credentials. When this is checked, it sets an attribute called msexchAuthenticationFlags on the virtual directory object in Active Directory (you can see it by using the Adsiedit.msc snap-in for the Microsoft Management Console).

Users checking mail through OWA may know the name of their Exchange back-end servers and can connect to them using integrated authentication while they are on the corporate intranet. The difference in user experience with integrated authentication is that since you are logged onto the network, you are not prompted for a user name and password because Internet Explorer will authenticate you to the Web site automatically. This is great for users who are on the corporate network, but external users—and OWA users are more typically external—will not usually be logged onto a domain when coming from the outside the network into an Exchange front-end server. (This process is explained in detail in the Knowledge Base article "How IIS Authenticates Browser Clients".)

In Exchange Server, the update populates the Delegation tab to use the A2D2 attribute rather than the Service Principal Name (SPN) attribute in Active Directory. If you take a look at the Exchange computer object using Adsiedit.msc, you should notice two distinct attributes: the A2D2 attribute, which is the Kerberos constrained delegation list; and the SPN attribute, which serves as a Kerberos locator and account specification point. While it is true that both attributes work together to make Kerberos constrained delegation happen, you should only modify the A2D2 attribute through the graphical interface.

Windows can use the built-in HOST SPN as an alias to locate other services. This means setspn.exe does not have to be used for Kerberos constrained delegation to work for Exchange front-end to back-end delegation. (Although explicitly specifying HTTP/Servername in the SPN attribute list will work with this solution, it leaves more room for administrator error, and is not required for Kerberos constrained delegation to function.) The Kerberos constrained delegation is looking for the A2D2 attribute in Active Directory. When this attribute is not populated (or populated with the wrong SPN value), Kerberos constrained delegation will not work between the respective servers. On an Exchange cluster, however, the A2D2 attribute from the front-end server only needs to be pointed to the cluster node computer account to work properly.

As noted earlier, a Windows Server 2003 domain containing the Exchange 2003 servers must be in Windows Server 2003 Native functional mode. Kerberos constrained delegation can’t be used unless that level of domain functionality has been achieved. If your domain is still in mixed mode and you install the software update discussed earlier, it will appear to work but the SPN registrations will actually fail. Kerberos constrained delegation is also a domain function, not a forest-level function. This means that for Exchange Server 2003, ISA Server and the Exchange front-end and back-end servers must be members of the same domain (although users from different domains can still authenticate to Kerberos constrained delegation). An ISA Server instance that is not a member of a domain or that is a member of a different domain will not work as part of this solution.

Configuring the OWA Site

IIS Admin should not be used for any kind of authentication changes to OWA. Even though OWA runs under IIS and will respond to changes in the metabase like any other Web site, Exchange introduces a bit of complexity with the Directory Services to Metabase (DS2MB) process. The DS2MB process will replicate changes from Active Directory to the IIS metabase in a one-way process that will overwrite any changes made directly to IIS. The impact of this process is that if an administrator goes in to make a change directly to the IIS metabase (such as setting integrated authentication), the solution will appear to work but will break once the next DS2MB replication cycle kicks off.

The option for enabling Integrated Windows Authentication for HTTP Virtual Directories was made available in ESM because ESM makes its edits directly to Active Directory, which then causes the change to be replicated down to the IIS metabase. Keep in mind that while stopping the System Attendant service will also stop the DS2MB process, allowing you to make changes to the IIS metabase and not have them overwritten, this is not advisable. The next time System Attendant starts, it will poll the changes from Active Directory and the solution will then be disabled automatically.

The Delegation tab shows options for Use Kerberos only and Use any authentication protocol. Simple logic would tell you to select Use Kerberos only since the solution that we’re discussing is using Kerberos constrained delegation—but this is one of those many IT situations where common logic does not apply. So instead, you should select the Use any authentication protocol option (as shown in Figure 7) because the request is not coming in as a Kerberos request; rather, it’s coming in as an HTTP request with a corresponding certificate mapped to an Active Directory account.

Figure 7 Correct authentication settings for smart cards

Figure 7** Correct authentication settings for smart cards **

In this case, ISA Server is requesting the user PKI certificate over SSL. The incoming request is not a Kerberos ticket, so a transition has to happen in order for Kerberos constrained delegation to work properly. Thus, specifying the Use Kerberos only setting will break the chain of communication at ISA Server. Note, however, that the Use Kerberos only option will work on the Exchange front-end to back-end server delegation since the front-end server will only be receiving Kerberos tickets from ISA Server.

The \Exchange and \Public virtual directories are the only locations that should contain private user and public folder information. The SSL configuration in Exchange is not new to Kerberos constrained delegation or two-factor authentication, but a carryover from standard SSL enabling of OWA with basic authentication credentials. You should follow the documented methods to enable SSL on OWA because incorrectly forcing SSL can break OWA—and can cause issues with ESM as well.

Additional Configuration Details

When implementing this solution, it is much easier to deploy ISA Server and Exchange in the standard manner first. Don’t drop in the entire Kerberos constrained delegation solution with all of the settings configured (especially if you didn’t previously have ISA Server in your deployment). This can complicate the troubleshooting process should a component or step in the process fail. It’s much easier to deploy ISA Server and Exchange in the standard manner (with username and password, but without forms-based authentication), ensure that the install is working, and then transition to Kerberos constrained delegation and certificate authentication.

Typically, forms-based authentication cannot be used with smart-card-enabled OWA. Forms-based authentication indicates that a user has a username and password to submit via the standard Outlook form. However, with smart-card-based two-factor authentication, the user will have only a smart card and not a password. Thus forms-based authentication will not have any means of accepting or submitting only the certificate for authentication. Using forms-based authentication anywhere in the chain (for example, on a front-end server behind ISA Server) will break smart-card-enabled OWA configuration. If you enable forms-based authentication, the Exchange virtual directory will be forcibly set to Basic authentication, and thus the IIS metabase will be set to Basic authentication as well.

If you have a mix of users who have both usernames/passwords and smart cards, you can enable fall-back authentication on the ISA Web listener, and when a user hits the ESC button after being prompted for certificate-based credentials, she will be prompted for standard username/password credentials even if Integrated authentication is enabled behind ISA Server on the Exchange server. Additionally, ISA Server can time out the SSL session in much the same way that forms-based authentication functions.

Conclusion

Smart card support for authentication to OWA is a welcome addition to both Exchange Server 2003 and Exchange Server 2007. With the ability to log onto OWA using a certificate, users no longer have to worry about remembering long and complex passwords, and administrators now have an effective tool against key loggers and other forms of malware that can sniff out user credentials from an infected system. See the "Resources" sidebar for more information.

Having ISA Server configured correctly for two-factor authentication with smart cards increases overall security even further by performing application level filtering on the published OWA application. Additionally, ISA Server 2006 has built-in support for publishing both Exchange Server 2003 and Exchange Server 2007 through the simple publishing wizards, so ISA Server remains a sound investment for organizations transitioning to Exchange Server 2007.

Resources

Victor Akinnagbe is a Premier Field Engineer at Microsoft working in the Washington, D.C. area. His primary focus is on security, infrastructure, and messaging.

Ted Dressel is a Consultant at Microsoft working in the Washington, D.C. area. His primary focus is on security and infrastructure.

Jason Opdycke is a Premier Field Engineer at Microsoft working in the Charlotte area. His primary areas of focus are security, and infrastructure.

Share via

Additional resources