Customizing the Outlook Web Access Logon Page

In Microsoft® Exchange Server 2003, a new authentication mechanism was introduced for Microsoft Office Outlook® Web Access for Exchange Server 2003. Forms-based authentication provides a central Web logon screen for users to authenticate through. When you use forms-based authentication, your logon credentials are stored in a temporary cookie. Storing these credentials in a cookie provides a more secure mechanism for ensuring session logout and automatic timeout.

This topic provide information intended to help Exchange administrators customize their logon page so that it fits their organization’s needs.

This topic describes changes that developers can make to, among other objects, Outlook Web Access source .asp, .css, .htc, .js, and .xsl files that exist in the \Exchweb folder. Be aware that any changes you make to these objects will be undone or will not work properly when you install service packs. Also, Microsoft Developer Support cannot support customization to these Outlook Web Access objects.

Before you start customizing the logon page, you should enable forms-based authentication (FBA) on your test server.

To enable forms-based authentication

1. Open Exchange System Manager.

2. Navigate to the HTTP protocol.

3. Right click the Exchange Virtual Server, and then click Properties.

   Note

   Forms-based authentication can be set on any Exchange Virtual Server that you have on your server; these examples assume the default settings.

   

4. On the Settings tab, select Enable Forms Based Authentication.

   

5. Restart Microsoft Internet Information Service (IIS).

To configure forms-based authentication to work without SSL for your development environment

1. Open Registry Editor.

2. Go to the following registry key:

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb

3. If it does not exist already, add an OWA subkey to this key.

4. Under the OWA subkey, add a DWord value named AllowRetailHTTPAuth.

5. Set the value of this DWord to 1.

The following figure displays the standard premium client logon page.

Premium clients are defined as Microsoft Internet Explorer 5.01 and later versions.

The following figure displays the basic client logon page.

Basic clients are defined as Internet Explorer version 5 and earlier and other non-Microsoft browsers.

The most common things that organizations want to change are the strings and graphics on the logon page.

The logon page was designed so that changing the strings would not be difficult. All strings in the page are defined at the top of the logon.asp file as constants.

To assist you in determining which strings to change, use the following table.

The following figure illustrates most of the major strings listed in the table.

The logon page is one of several pages involved in the authentication process for Outlook Web Access users. When a user is asked to authenticate, he or she is normally redirected to the http://servername/exchange directory. This directory contains the default owalogon.asp file.

The owalogon.asp file evaluates the HTTP_ACCEPT_LANGUAGE header of the browser and determines which localized version of the Outlook Web Access logon form to display. After owalogon.asp determines which version to use, the user is redirected to the logon.asp page. It is this page that this topic will cover.

The owalogon.asp redirect page can also be used to isolate the changes you make to your logon.asp pages from changes that may occur when Exchange Server 2003 service packs are applied. Isolating these changes is important because, when Exchange service packs and other updates are applied, they will typically overwrite any changes that you may have made to the logon.asp file. By saving your logon.asp customizations to a different file name (for example, logon2.asp) and changing the owalogon.asp page to point to your new pages, you can reduce the changes you need to make during service pack updates. Of course, you should compare any new logon.asp pages applied during updates with your custom page to make sure that you incorporate any changes that occurred during the update back into your custom page.

To point to your custom logon page, update the two occurrences of logon.asp from the following section at the end of the owalogon.asp page.

for each szSubString in arLanguages
   szLanguage = Split(szSubString, ";", -1, 1)
   szMSFTLang = LangMap.Item(UCase(szLanguage(0)))
   for each folder in folders
      if (szMSFTLang = UCase(folder.Name)) then
         Server.Transfer("./" & folder.Name & "/logon.asp")
      end if
   next
next
Server.Transfer("./" & "USA" & "/logon.asp")

Outlook Web Access has a localized version of the logon.asp page for each language that is supported by Outlook Web Access. If your organization supports multiple languages in Outlook Web Access, and you make changes to logon.asp, remember to make those changes for each language that your organization supports.

The logon page expects that the user will enter his or her user name in the form of either domain\username, or user principal name (UPN).

In addition to the user name, the password must be provided to successfully log on.

Other visible parameters that are transferred when the user logs on include the client experience and the security options.

The logon page submits its values in a post to owaauth.dll. The following table shows the values that are supported.

Of these parameters, the flags parameter deserves further explanation.

The flags parameter allows the enabling and disabling of certain Outlook Web Access features. In Exchange Server 2003, this parameter controls the following features.

Security Level

The logon page provides two different security settings. These settings specify whether a computer that the user is logging on to is a public computer or private computer. When a private computer is selected, the user session changes and the time-out value for his or her session is increased to the value specified in the TrustedClientTimeout registry subkey.

• To enable this feature, perform a bitwise OR of the flags value with the binary value 0100 (decimal value = 4).
• To disable this feature, perform a bitwise AND of the flags value with the binary value 1011 (decimal value = 11). By default, this feature is disabled.

Compression Level

Outlook Web Access supports Internet standard gzip compression. Unfortunately, not all browsers that support gzip compression do it the same way. Therefore, the logon page provides logic to determine specifically which version and software update level of Microsoft Internet Explorer is being used. If Outlook Web Access determines that a version is being used that does not provide sufficient gzip support, this feature can be disabled by using forms-based authentication and by setting the compression level flag.

• To disable this feature, perform a bitwise OR of the flags value with the binary value 0010 (decimal value = 2).
• To enable this feature, perform a bitwise AND of the flags value with the binary value 1101 (decimal value = 13). By default, this feature is enabled.

Client Experience

By default, Outlook Web Access provides the rich client experience for browsers that support it and the basic experience for other browsers. Some users may want to use the basic experience although their browser supports the rich experience. One scenario where a use might make this selection is to gain a performance improvement when he or she has not used Outlook Web Access on a specific computer but needs fast access to his or her Inbox.

• To force the client experience to basic, perform a bitwise OR of the flags value with the binary value 0001 (decimal value = 1).
• To force a client to use the premium client, perform a bitwise AND of the flags value with the binary value 1110 (decimal value = 14).

The following resources offer additional information to help you customize the Outlook Web Access logon page.

• W3C: Cascading Style Sheets Home Page
• W3C: Adding a Touch of Style
• W3C: Cascading Style Sheets, level 2: CSS2 Specification
• MSDN: Introduction to Dynamic Styles