Hi everyone

The subject for this article is the authentication methods of Exchange 2007 Outlook Web Access (OWA). Throughout the article I will talk about the authentication methods, their advantages and disadvantages, how they are configured and therefore give a brief and clear understanding about the authentication methods of OWA to you. Lets begin with the authentication methods that are supported by Exchange 2007 OWA.

Out of the box, OWA (which is served via Client Access Server – CAS) supports two kinds of authentication methods. These are:

1)      Standard authentication (3 independent types)

2)      Forms-based authentication

Note: There are also additional authentication methods that can be used (ISA Server forms-based authentication, Smart card and certificate authentication, RSASecureID authentication) but these are out of scope for this article.

In Exchange 2007 OWA, Standard Authentication methods are; Integrated Windows authentication, Digest authentication, and Basic authentication. One or multiple methods can be selected as standard authentication method. If multiple authentication methods are selected, Internet Information Services (IIS) uses most restrictive method first (IIS is the core service for OWA). IIS then searches the list of available authentication protocols starting with the most restrictive until an authentication method that is supported by the client and the server is found. Figure 1 shows a scenario that all of the standard authentication methods are selected for OWA access (EMC -> Server Configuration -> Client Access -> Outlook Web Acccess field -> owa -> Properties). When Standard Authentication Method is configured for OWA, a username/password pop-up window is presented to the end user.

Figure 1: All Standard Authentication Methods are selected

Forms-based authentication method creates a logon page for Outlook Web Access, instead of pop-up window. This authentication method uses cookies to store encrypted user logon credentials and password information. Tracking the use of this cookie enables CAS server to monitor the activity of OWA sessions on public and private computers. If a session is not active for a long time, the server blocks access until the user re-authenticates (The default time-out period when a user selects the This is a public or shared computer option on the OWA logon page is 15 minutes. The default time-out period when a user selects the This is a private computer option on the OWA logon page is twelve hours). Figure 2 represents the default Forms-Based Authentication screen of Exchange 2007 OWA. Exchange 2007 uses Forms-Based Authentication by default as the authentication method.

Figure 2: Forms-Based Authentication OWA screen

So what is the difference between Standard and Forms-Based Authentication methods? What factors affect the authentication method decision? Table 1 represents a comparison between two methods. As you can see, security requirements or browser support can be the factor for your authentication method decision. As it can be clearly seen in the table, Forms-Based authentication presents the most secure communication. If you are concerned about the security, you have to choose Forms-Based Authentication or think about to use SSL protocol. But if the browser support (and the number of people that you want to serve) is the concern, Basic Authentication is the choice.

Table 1: Standard authentication and Forms-based authentication comparison

Now is the time to explain what all these authentication methods are. Lets start with the standard methods.

Integrated Windows Authentication: Users logged on to the local network are not prompted for their user names and passwords in this method but the method requires users to have a valid Windows 200x Server user account name and password to access information. The server negotiates with the Windows security packages that are installed on the client computer. Integrated Windows Authentication enables the server to authenticate users without prompting them for logon information. The authentication credentials are protected, but all other communication will be sent in clear text unless SSL is used.

Integrated Windows authentication is supported only on computers that are running a Windows operating system and Internet Explorer. Integrated Windows authentication may work with other Web browsers if they have been configured to pass the user’s logon credentials to the server that is requesting authentication.

Digest Authentication: This method transmits passwords over the network as a hash value. Digest authentication can be used only in Windows Server 200x Server domains for users who have an account that is stored in the Active Directory directory service. Figure 3 represents the Digest Authentication process for a client machine.

Figure 3: Digest Authentication process for a client machine

1) The client requests a file from the server running IIS (from CAS server).

2) The server denies the request and sends the following information to the client:

a) Digest authentication is being used

b) The realm name (i.e. domain name)

3) Web browser prompts the user for credentials (user name and password). It then combines these credentials with the name of the realm to create an MD5 hash and resubmits the request for the file from the server running IIS, this time sending the MD5 hash.

4) The IIS server receives the hash and sends the client’s hash to the domain controller for verification.

5) The domain controller informs the IIS server of the authentication results.

6) If the client is authenticated, IIS sends the requested document or data to the client.

Basic Authentication: This method is a widely used one for collecting user name and password information. When it is used, the browser displays a dialog box into which users are required to enter a previously assigned Windows account user name — which includes a Windows domain name, for example, mstip\teo — and password, which are also known as credentials. The browser then attempts to establish a connection to a server using the user’s credentials. The plaintext password is Base64-encoded before it is sent over the network. The process is more-or-less the same as the Digest Authentication except hashing the password. This authentication method is supported by all web browsers but not secure without SSL.

As I explain the standard methods, it is necessary to talk about the Forms-Based authentication also:

Forms-Based authentication: This authentication method creates a logon page for OWA instead of pop-up window.  The first time that the user name and password (credentials) are sent to the CAS server to authenticate an OWA session, an encrypted cookie is created that is used to track user activity. When the user clicks Log Off or closes the web browser to log off their OWA session, the cookie is cleared. The credentials are sent to the CAS server only for the initial user logon. After the initial logon is complete, only the cookie is used for authentication between the client computer and the CAS server.

As it is seen in Figure 4, an Exchange administrator can decide how mail-enabled users can logon to the OWA interface. What I mean here is that they can write the user logon information in one of three formats. These are:

a)      Domain\user name: The user has to give the username in format i.e. mstip\teo

b)      User Principal Name (UPN): The user has to give the username in format i.e. teo@mstip.com

c)       User name only: The user can enter only the user name i.e. teo. But this format can only be used if Logon Domain value is configured.

Figure 4: Forms-based authentication logon formats

The configuration for all the authentication methods are done via the same interface which can be reached from (EMC -> Server Configuration -> Client Access -> Outlook Web Acccess field -> owa -> Properties) as it can be seen in Figure 4. They can also be configured by Exchange Management Shell. Table 2 represents the commands that can be used for this purpose:

Table 2: Configure authentication method for OWA

Set-OwaVirtualDirectory -identity "owa (Default Web Site)" -LogonFormat FullDomain

Set-OwaVirtualDirectory -identity "owa (Default Web Site)" -LogonFormat PrincipalName

Set-OwaVirtualDirectory -identity "owa (Default Web Site)" -LogonFormat UserName -DefaultDomain "<domain name>"

Internet Information Services (IIS) must be restarted by using the command iisreset/noforce for these changes to take effect.

This is the end of this article. I tried to explain the authentication methods which Exchange 2007 offers to you. I hope it is helpful. See you next time.

Related Posts

1. Outlook Web App access in an Exchange 2010 – Exchange 2003 coexistence scenario
2. Exchange Transition Scenario (2003 to 2007) – Day 1
3. Customizing OWA interface (Exchange 2007)