Microsoft Outlook Web Access

Outlook Web Access (OWA) was first introduced to Exchange Server in version 5 and provides a way to access Exchange-based folders using a web browser such as Internet Explorer. OWA can be used to access e-mail, public folders, contact information, and calendar information. Since its introduction, OWA has become very popular, and its architecture has once again been completely overhauled with the introduction of Exchange Server 2003 Server. It has been redesigned to provide improved performance and a streamlined user interface.

When using OWA, the only thing required on the client computers is Internet Explorer. This is also what makes OWA a good tool for cross-platform support, since versions of most web browsers exist for Windows, Macintosh, and Unix. In fact, OWA is the primary Exchange Server access method for users of Unix.

Note ‚

Outlook Web Access is designed to work with any browser that supports HTML version 3.2 and JavaScript. This includes the latest versions of Internet Explorer and Netscape Navigator, as well as many other browsers. However, OWA is also designed to take advantage of a number of features provided in Internet Explorer 5 and higher that are not supported by other browsers at this time, such as Dynamic HTML (DHTML) and Extensible Markup Language (XML). Such features help provide many advanced collaborative functions.

OWA Features and Restraints

OWA is installed by default when you install Exchange Server 2003. Taking advantage of the ASP.NET service of Windows Server 2003, an OWA user can access many of the functions available through Outlook, including functionality for e-mail, calendar and group scheduling, public folders, and collaborative applications (when the forms have been developed with Microsoft Visual InterDev). Although OWA in Exchange Server 2003 is an almost perfect replacement for Outlook 2003, the following are some of the items that are not available when using OWA:

Personal address books (because they are stored on your workstation)
Personal folders (PST files)
WordMail and Microsoft Office integration
Electronic forms creation
Synchronizing local offline folders with server folders

Outlook Web Access simulates the look and feel of Outlook 2003, as shown in Figure 7.20. The ubiquity of the browser client makes OWA an attractive choice in environments that have a widespread mix of client platforms (such as Windows, Macintosh, and Unix) and that require shared client computers. Outlook Web Access is extremely useful for users who frequently move around among different workstations during the day and users who must access the Exchange server remotely via the Internet.

Figure 7.20: Accessing Exchange via OWA

The OWA Process

The OWA process in Exchange Server 2003 is quite different from that of previous versions. OWA 5. x used Active Server Pages (ASP) to communicate with Exchange Server 5.5, which in turn used Collaboration Data Objects (CDO) 1.2 and MAPI. The effective number of users per server was limited by the overhead needed to support ASP and to run MAPI sessions within ASP. OWA was actually a part of IIS.

The new version of OWA does not use MAPI to communicate with the mailbox store and no longer uses ASP for client access. Instead, OWA is built into Exchange Server 2003 ‚ s new web store and uses IIS only to receive requests and pass them to the web store. Thus, IIS acts as an intermediary between the browser and OWA. IIS receives a client request, looks at the URL, and passes the appropriate information for the URL back to the web browser. If the server houses the Exchange Server 2003 database, OWA uses a high-speed channel to access the mailbox store. If the server is a front-end server, OWA redirects the request to a back-end server using HTTP.

OWA is actually not a client itself but rather a set of Active Server Pages that run in the context of Microsoft ‚ s IIS. Client web browsers access IIS using HTTP over TCP port 80, by default, and in turn IIS accesses the OWA component on behalf of the clients using an extended version of HTTP known as HTTP-DAV. HTTP-DAV adds several features to HTTP such as file locking, namespace management, and document property access.

Many components play an important role in the OWA process, including the following:

Active Directory
Information Store
The Exchange DSAccess component, which enables Exchange Server 2003 components to communicate with Active Directory (DSAccess uses the LDAP protocol to perform this communication)
OLE DB Provider for Exchange (ExOLEDB), which acts as the interface between DAVEx and EXIPC (both discussed a bit later)
Directory Service to the IIS metabase (DS2MB), which provides a one-way synchronization of configuration information from Active Directory to the IIS metabase
EXIPC, a queuing engine that is used to pass information between the IIS and Information Store components
IIS metabase , which is a Registry database for IIS configuration
W3svc , the World Wide Web publishing service of IIS
DAVEx , a component that passes client requests between W3svc and the Information Store
ExProx, which acts as a protocol proxy on a front-end server if a front-end/back-end server configuration is being used
Forms Registry , which stores the OWA forms rendered by IIS and passed to the client

As you can see, the OWA process is fairly complicated and involves a number of components. The complexity of the process is basically designed to ensure that each major tool in use does what it is good at and that the client needs no special configuration. Since the client needs to be able to access Exchange using a standard web browser, its only responsibility must be to request a simple URL, such as http://owa.microsoft.com/exchange, from a web server (in this case IIS) and display the results in its window. Everything else must happen on the server end. For example, to open a user ‚ s contacts, type the path to the user ‚ s mailbox followed by /contacts, as in http://owa.microsoft.com/exchange/ user /contacts, where user is the user ‚ s mailbox name .

Here is the actual process that occurs when a client ‚ s browser requests information from an Exchange server:

W3svc in IIS receives the request and authenticates the user by querying Active Directory.
Once authentication is complete, W3svc relays the request to the DAVEx component.
DAVEx transfers the request through the EXIPC queue to the Information Store.
The Information Store retrieves the appropriate data and returns it to DAVEx.
DAVEx retrieves an appropriate form from the Forms Registry and merges it with the information from the Information Store, creating an HTML or XML document.
DAVEx sends the formatted document back to W3svc.
W3svc sends the information back the client, which displays it in the browser window.

Installing and Configuring OWA

OWA is installed as part of the default setup of Exchange Server 2003, and it is configured by default to allow access to users ‚ mailboxes and the default public folder tree. However, you can configure the server to provide customized access for clients by specifying which users can access the server, which authentication method(s) to allow, and which public folders are exposed to users.

Since Outlook Web Access begins running when Exchange Server is installed, no special setup options are required other than a standard Exchange installation. The OWA client can offer your users much of the functionality offered by using Outlook 2003 from remote locations. Using a dedicated server for OWA can also increase network security by exposing only this dedicated server to the Internet.

When you install Exchange Server 2003, web access is installed and configured by default, and an Exchange virtual root and a Public virtual root are added to the IIS directory tree. These virtual roots point to their corresponding directories in Exchange Server 2003 ‚ the directories that hold the public store and the mailbox store.

To access mail folders from within the corporate intranet, users will need to enter the following address in their web browser: http:// servername /exchange/ user /, where servername is the name of the Exchange server, exchange is the default private web folder, and userid is the alias of the user. For connecting via the Internet, the above URL must be appended by the Fully Qualified Domain Name of the domain on which Exchange is running, for example, http:// servername . domain .com/exchange/ user /.

Web access to Exchange Server 2003 is enabled for all users by default. To change this configuration, use Active Directory Users and Computers. On the Exchange Features tab of the user Properties dialog box, seen in Figure 7.21, you can enable or disable HTTP, IMAP4, and POP3 access to the Exchange organization.

Figure 7.21: Modifying protocol settings for a user

User Authentication in OWA

Users of OWA must be authenticated in some form before anything but Anonymous access is granted. A number of options are available for OWA authentication. Choosing the appropriate mechanism is usually a matter of the capabilities of the client operating system and specific security policies. In a single-server environment, the default authentication method for OWA is Anonymous authentication and Integrated Windows authentication (similar to NTLM). In a multi-server environment, the default authentication is Basic (clear-text) and NTLM. Authentication is set via the HTTP virtual servers configured for OWA. This configuration is actually set in Internet Information Server. Microsoft recommends configuring authentication on the back-end Exchange server only. The default authentication settings are the same on the front-end Exchange server, but securing the back-end server is much more important. In addition, authentication conflicts between the front end and back end could jeopardize user access. Exercise 7.1 outlines the steps for configuring OWA authentication. But first we must define the available types of authentication.

Basic authentication Basic authentication , also referred to as plain-text or clear-text, is commonly used on intranets . Unlike the NTLM protocol, which accepts established users ‚ identification through the access token, Basic authentication relies on users to enter their username, domain, and password. Basic authentication is independent of the browser, which also makes it independent of the platform being used. Basic authentication results in the transmission of unencrypted passwords over the network, which makes it a relatively insecure method of authentication. Users must enter their username, domain, and password each time they log on.

Integrated Windows authentication Integrated Windows authentication works differently depending upon the situation. The optimal authentication takes place when the client is running Windows 2000 (or later) and Internet Explorer 5 (or later), in which case Kerberos provides the best security available. With other pre ‚ Windows 2000 clients, Integrated Windows authentication uses the NTLM protocol instead of Kerberos. Integrated Windows authentication always encrypts the client ‚ s password, which provides excellent security . It also allows browser access without prompting the users for their user ID and password. Integrated Windows authentication does not work with browsers other than Internet Explorer 4 and 5, and it is not available in a front-end and back-end Exchange Server configuration.

Anonymous authentication Anonymous authentication , which IIS also allows, provides limited access to specific public folders and directory information. All browsers support Anonymous authentication, making it an easy way to provide insecure access to public folder data. A single point of configuration makes administration simple. Anonymous authentication does not identify users uniquely. Consequently, you cannot track usage by user.

Secure Sockets Layer authentication Secure Sockets Layer (SSL) provides the best level of security because the entire communications session is encrypted. SSL is not an authentication mechanism itself. Rather, SSL provides a secure channel for other authentication mechanisms. Although any authentication mechanism can be used with SSL, the most common implementation with SSL is Basic (clear-text). Most browsers support SSL communication. SSL creates a substantial amount of overhead in providing this security, so SSL communications tend to reduce the overall performance of an authenticating server and generate increased network traffic.

All in all, Outlook Web Access is a powerful means of providing cross-platform and remote access to your Exchange server. Authenticated users can log on to their personal accounts to access e-mail, public folders, and collaborative tools. Using web-based public folder access, an organization could even build private and public discussion forums on the Internet or on private intranets.

EXERCISE 7.1: Configuring Authentication for Outlook Web Access

Click Start > Programs > Administrative Tools > Internet Information Services (IIS) Manager.
Expand the container for the server running OWA.
Expand the default website container.
Right-click the Exchweb object and select Properties from the shortcut menu.
Click the Directory Security tab.
Click the Edit button in the Authentication And Access Control section at the top of the page.
Select the forms of access that you want to allow.
Click OK twice to return to Internet Information Services (IIS) Manager.