Outlook Web Access

Microsoft Outlook Web Access is an ASP application that Microsoft ships with Exchange Server version 5.5. This ASP application allows you to access your mailbox, calendar, and contacts as well as directory information using any standard web client. The Outlook Web Access application is built on CDO and is one of the best tools for learning CDO.

In this section, you'll learn how to install Outlook Web Access on your web server, which also installs the CDO library. You'll also learn about security when using Outlook Web Access. This security architecture is important since it also applies to any custom CDO applications you develop using ASP.

Installing Outlook Web Access

Before installing Outlook Web Access, you must have installed either IIS version 3.0 or IIS version 4.0 with Active Server Pages. IIS 4.0 and Exchange Server 5.5 both require Windows NT 4.0 Service Pack 3, but it is recommended that you install Service Pack 4. You can download the Window NT 4.0 Service Pack 4 from http://www.microsoft.com/windows/downloads/. If you don't install Service Pack 4, you will need to install the Windows NT related fixes required for Outlook Web Access. You can download these hot fixes from ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/hotfixes-postsp3/roll-up/.

You can install Outlook Web Access on the same server as your Exchange Server or on a separate server. Be aware that if you do install Outlook Web Access on a separate server, you cannot use Windows NT Challenge/Response as your authentication method. You'll learn more about security implications later in the chapter.

The architecture for your web servers and Exchange Servers can vary depending on the topology of your network environment and requirements of your applications. For example, if few users will be accessing Outlook Web Access but you have a number of Exchange Servers and you do not want to set up multiple Outlook Web Access servers for each Exchange Server, you can set up just one Outlook Web Access server to talk to multiple Exchange Servers. The opposite is true as well. You can have multiple Outlook Web Access servers talking to just one Exchange Server. Think of it as a web farm of Outlook Web Access servers. This will work as long as you make sure that when a user starts a session with an Outlook Web Access server in a web farm, that user stays with the same Outlook Web Access server until her session expires or she logs out. Remember that ASP sessions do not span separate ASP applications. If you use DNS round-robin techniques to farm a user out to multiple Outlook Web Access servers, that user's session will be lost when she changes to a different server.

To install Outlook Web Access, follow these steps:

1. Insert the Exchange Server version 5.5 CD in your CD-ROM Drive.
2. If the Exchange Server welcome screen does not start automatically, launch it by double-clicking on Launch.exe.
3. Click on Server Setup And Components.
4. Click on Microsoft Exchange Server 5.5.
5. When setup starts, click Complete/Custom installation. (If you already have Exchange Server installed, click Add/Remove.)
6. In the Options list, check Outlook Web Access and click Continue. If you don't have the Windows NT Service Pack 4 (or the Windows NT related fixes) and IIS installed, a message box will be displayed and you won't be able to continue the installation of Outlook Web Access.
7. The setup program will prompt you for the name of an Exchange Server that Outlook Web Access should connect to. Type a name of a server that contains an entire replica of the Exchange Server directory. This sets up Outlook Web Access so that it automatically redirects itself to the Exchange Server where the mailbox of the user resides. It also allows you to set up one Outlook Web Access web server that talks to multiple Exchange Servers.

After completing the Outlook Web Access installation, you need to update it by installing Service Pack 1 for Exchange Server 5.5. You can download or order this service pack from http://www.microsoft.com/exchange/. This service pack includes a number of enhancements for the Outlook Web Access client, such as the ability to access Outlook contacts from the Web.

After running the update, you need to set the proper permissions in the User Manager For Domains. Ensure that the Exchange users who will use Outlook Web Access have the following rights: "Log On Locally" and "Access This Computer From Network".

Access your new Outlook Web Access server by typing the following URL in your browser: http://OWAServer/exchange, replacing OWAServer with your Outlook Web Access server name. From the displayed page, you can log in as an Exchange user or log in with anonymous access. (Anonymous access is discussed in more detail in Chapter 11. Figure 8-6 shows how Outlook Web Access looks when you log on as an Exchange user.)

Figure 8-6 Outlook Web Access.

Outlook Web Access and ASP Security

Since the Outlook Web Access application utilizes Active Server Pages, you need to understand the ASP security architecture and how best to configure it for your environment. If you configure the environment incorrectly, you will run into problems when attempting to use authenticated access to the Outlook Web Access application or to any of your CDO web applications requiring authenticated access. This section describes how ASP security works and how you should set up Windows NT to support the type of security you want for your web applications.

ASP Security

When IIS is first installed, it creates a Windows NT user account called IUSR_computername, where computername corresponds to the current computer name. This account is assigned to the Guests account group, is given a random password, and is granted the right to Log On Locally. Whenever a user browses a web page, this account attempts to access the page on behalf of the user. If the IUSR_computername account does not have the proper permissions to access the page, the request is rejected with this error message: 401 Access Denied. The web server then informs the web browser which authentication methods the web server will support—either Basic authentication or Windows NT Challenge/Response authentication—depending on your settings for your IIS server.

Basic authentication Basic authentication is supported across all web browsers. When the web server informs the client that it supports Basic authentication, the web browser displays a message box asking the user for a user name and password. Once the user types this information in, the web server tries to invoke the request using the identity of the supplied user rather than the IIS anonymous account. It is a good idea to pass in your domain name as well as the user name in the authentication dialog box in the web browser using the syntax domain\username.

Basic authentication, if used over Internet connections, can present some security concerns because the user name and password typed into the authentication dialog box is transmitted to the server as clear text. If you do use Basic authentication over Internet connections, use it in conjunction with Secure Sockets Layer (SSL). SSL will encrypt the connection between the web browser and the web server so that any information passed between the two cannot be viewed by unwanted individuals.

For the web server to impersonate the user whose name is typed into the authentication dialog box, the web server must log on as that user. By default, Windows NT does not give regular users the Log On Locally right on the server computer. For this reason, you must give all the users you expect will use your web application with Basic authentication enabled the Log On Locally right on your Windows NT server, which runs your web server. The easiest way to do this is to grant all your domain users the Log On Locally right in the User Manager for Domains.

Windows NT Challenge/Response authentication Windows NT Challenge/Response, or NTLM, authentication is the most secure form of authentication because the user name and password are not sent from the web browser to the web server. Instead an encrypted challenge/response handshake mechanism is used. Unlike Basic authentication, NTLM typically does not prompt the user for a name and password. The Windows NT security credentials of the web user currently logged on are sent to IIS and are used to access the requested resource. IIS then changes to the context of the specified user and attempts to access the resource. If this fails, the user will be prompted for a user name and password.

NOTE

---

For Windows NT Challenge/Response to work correctly, the users you are trying to authenticate must have "Access This Computer From Network" rights in User Manager for Domains. This is normally enabled for users by default.

A one-way encryption method is used, meaning the mechanism validates the user without sending the password to IIS. IIS doesn't know the user information and cannot use it to access other resources on other machines. Essentially, this is a problem of delegation. When IIS attempts to access a resource on another machine, the other machine will prompt IIS for user credentials. Since IIS does not have the password for the user, it cannot return the correct information to the other machine. For this reason, you cannot use the Windows NT Challenge/Response authentication method with Outlook Web Access when your Outlook Web Access server is on a server different from your Exchange Server. IIS cannot remotely send the authentication to the Exchange Server when the Windows NT Challenge/Response method is used. This problem is being fixed for Windows 2000, but it's a gotcha for now.

A second gotcha of the Windows NT Challenge/Response method is that you cannot use it over proxy connections for the same reasons just discussed. So when setting up your web server, consider NTLM's security advantages as well as its limitations.

A third gotcha for NTLM is that at the time of this book's publication, NTLM is supported only by Microsoft Internet Explorer. This means that if you have a mixture of web browser clients accessing your application, you might want to enable both Windows NT Challenge/Response as well as Basic authentication. If you enable only Windows NT Challenge/Response, when your Netscape Navigator users attempt to access a secure resource or page, they'll receive a message denying them permission. With both security methods set up, if Windows NT Challenge/Response fails, Basic authentication will be used.

ACLs Another way to restrict access to your web pages is by setting NTFS file permissions, or access control lists (ACLs), on your actual ASP files and directories. Doing so controls who can and cannot read the files. IIS respects the ACLs on the files, and if you have authentication enabled on your IIS server, IIS will use it to attempt to verify users and their individual permissions on the files. Be careful when setting permissions on files, however, because if the permissions you set are too restrictive, users will not be able to use your application.

Special Considerations for Setting Up Outlook Web Access

ASP security and Outlook Web Access security work in the same way when a user is being authenticated, but when you set up Outlook Web Access on your web server, you need to keep some access issues in mind. The following section describes file permission issues when users try to access Outlook Web Access on a web server, problems that could ultimately cause trouble in your CDO applications.

File Permissions for the Outlook Web Access Files

Outlook Web Access is installed by default in a subfolder under Exchsrvr, named Webdata. If you change the NTFS file permissions for this folder, at the minimum you should enable Read access on it and its subfolders. For temporary work, Outlook Web Access uses another subfolder under Exchsrvr, named WebTemp. Make sure that the permission for this folder is set to Change because Outlook Web Access needs to create and delete items in it.

Exchange Server Search Permissions

If you are using the new Search permissions in Exchange Server version 5.5 to restrict access to information in the Exchange Server directory for your users, you need to make sure that the Everyone and Directory Anonymous accounts have Search permissions at the Exchange Site or Configuration container level. If you do not grant these permissions, a user might get an error message stating that the Exchange Server is down or that HTTP access has been disabled. Your CDO applications could fail as well. For more information on this error, be sure to check out the following Knowledge Base articles in MSDN: Q173455 "OWA Returns Exchange Server Down Error Message"; Q175892 "Permissions Required for Outlook Web Access"; Q180417 "Error Msg: Sorry! The Microsoft Exchange Server Is Down."

Installing Outlook 8.03 on Your Outlook Web Access Server

If you install Outlook 8.03 on your web server after installing Outlook Web Access, Outlook will register an older version of the CDO library. Most commonly, users won't be able to access or render calendar information in Outlook Web Access or CDO applications because the older version of the library did not support this. To fix this problem, type the following at the Run command, which is accessed from the Start menu on your Outlook Web Access server: regsvr32 cdo.dll.