Controlling Access to Outlook Web Access

There are a variety of ways to control access to Outlook Web Access, including turning it off completely, restricting which individual users can and cannot use it, selecting the authentication methods you want to be used, and even fine-tuning which individual Outlook Web Access features a particular server offers.

Virtual Servers versus Virtual Directories

Talking about Outlook Web Access security can be confusing because there are two related entities that you have to set security properties on. Virtual servers are IIS instances that handle requests for a particular protocol on a specified Internet Protocol (IP) address and Transmission Control Protocol (TCP) port. You can have multiple virtual servers for each of the Internet protocols that Exchange supports; for example, it’s common to see multiple SMTP virtual servers dedicated to traffic from various sets of users. Virtual directories are IIS objects that link a physical file system directory with a logical URL. Some IIS settings can be applied only to virtual servers, some can be applied only to virtual directories, and some can be applied to virtual servers or virtual directories.

Outlook Web Access service is primarily provided through the /Exchange virtual directory. Accordingly, that’s where you control the access, authentication, and permission settings that IIS uses. However, most of the other interesting settings (including those for things like caching, SSL use, and custom error pages) are normally set at the virtual server level (although some might be set at the page level, too).

Controlling Access to Servers

You might think that stopping the w3svc service would be the best way to turn off Outlook Web Access on a server. Sure enough, stopping or pausing that service does turn off Outlook Web Access, but it also turns off some other useful functionality, including public folder administration. Remember, the HTTP publishing service is tightly integrated with a variety of other Exchange components, so stopping it probably isn’t your best bet.

However, you can use Exchange System Manager to pause an individual virtual server at any time. Pausing one of the IIS-based servers (SMTP, POP3, IMAP4, and HTTP) causes that server to stop accepting new connection requests. Clients who are already connected are allowed to finish their existing sessions, but no new sessions can be created. By pausing the Exchange Virtual Server object (look in the HTTP node under the physical server’s Protocols container), you can stop new Outlook Web Access sessions; as long as the service stays paused, access to Outlook Web Access will be effectively turned off. (You can accomplish the same thing by pausing the IIS w3svc itself.)

Perhaps you want to restrict access to servers only from particular network addresses; for example, it’s common to allow internal users to use Outlook Web Access from some locations on the internal network without allowing external users (or even some groups of internal users) to have it. The best way to accomplish this is to use a firewall to block traffic on the ports Outlook Web Access uses: TCP port 80 for regular Outlook Web Access traffic and TCP port 443 for SSL traffic. You can also filter requests based on the source IP address within IIS by using Internet Services Manager to view the virtual directory Properties dialog box, clicking the Directory Security tab, and clicking Edit within the IP Address And Domain Name Restrictions section.

Setting Permissible Authentication Methods

By default, Outlook Web Access can use both basic and integrated authentication. Depending on the mix of clients you have to support, you might want to disable either of these methods, or at least restrict their use. If you’re familiar with IIS, you might think that you can just fire up Internet Services Manager and make the change, but you can’t. As with many other Outlook Web Access–related settings, even though IIS is responsible for using the settings, you have to change the settings from within Exchange System Manager and allow the ds2mb process (which is responsible for one-way synchronization of Exchange settings from Active Directory to the IIS metabase) to copy the changes to the metabase. Changing the settings directly in Internet Services Manager typically has no effect.

Tip

You can only set authentication methods on a per-server basis; there’s no global way to apply your preferences to multiple servers. That means you’ll have to manually ensure that all of your FEs have similar settings.

To choose which authentication methods a particular server will support, start Exchange System Manager and expand the Servers container of the administrative group that contains the target server. Expand the target server’s node, open its Protocols container, expand HTTP, then Exchange Virtual Server. Right-click the Exchange virtual directory, and select the Properties command. Click the Access tab, then click Authentication, and you’ll see the dialog box shown in Figure 14-2.

Figure 14-2: The Authentication Methods dialog box lets you specify which authentication methods you want your Outlook Web Access server to accept.

The authentication controls are very straightforward: there’s one check box for each type of authentication that IIS (and thus Outlook Web Access) supports:

• The Anonymous Access check box turns anonymous authentication on or off. When it’s checked, you can specify which account is used to authenticate (for example, the permissions granted to the account shown in the Anonymous Account field will be used). By default, the IUSR_machineName account is used.

• The Basic Authentication check box controls whether your server will accept basic, unencrypted authentication requests. By specifying a domain in the Default Domain field, you can also control which domains the server attempts to authenticate against. Putting a single backslash into this field tells IIS to try authenticating a user’s credentials against all trusted domains; this is a nice shortcut for your users, because they won’t have to enter their domain name to be authenticated.

• The Integrated Windows Authentication check box turns integrated authentication on and off.

Note

Just typing the account name in the Anonymous Account field is pretty worthless; the correct way to specify which account should be used for anonymous requests is to open Exchange System Manager, expand a server’s Protocols container, expand its NNTP object, and right-click the Default NNTP Virtual Server. Open the Default NNTP Virtual Server Properties dialog box and click the Access tab. Click Authentication. In the Authentication Methods dialog box, click Anonymous, and you’ll see a dialog box that allows you to change the account by directly specifying an account or by browsing Active Directory.

Using Form-Based Authentication

In some circumstances, it’s desirable to use a logon form instead of relying on the default Internet Explorer credential mechanism. Consider, for example, the case where you have a mix of Internet Explorer and Netscape clients on UNIX, Windows, and Mac OS computers. Basic authentication is the only method that these clients all have in common, but that might not be the best choice for your network setup. An alternative is to fall back on the old-school Outlook Web Access 5.5 style of authentication by providing a logon form that redirects users to the correct Outlook Web Access virtual directory after a successful authentication.

Form-based authentication has another really nice property: by storing the logon credentials in an HTTP cookie, you can force the user’s session to end by throwing away the cookie or making it expire, and you can require that the cookie be sent using SSL. Until Outlook Web Access has a real logout feature, many customers are choosing to deploy form-based logon systems to give them a way to force a complete logoff when users are finished with their Outlook Web Access sessions.

A complete form-based system has two basic parts: the logon form itself and an Internet Server Application Programming Interface (ISAPI) Web filter. The logon form provides a place for the user to type in credentials; a small script on the page adds the credentials as a cookie. The ISAPI filter, meanwhile, is installed on the Outlook Web Access server and registered so that it’s called when certain events take place. The filter reads the credentials from the cookie, converts them to a basic authentication header, and passes them along to Outlook Web Access.

Note

Because this isn’t a programming book, I’ve chosen to omit the complete code for the ISAPI filter. However, an example filter (provided with no warranty or support) is available from http://www.e2ksecurity.com. You can customize this code to meet your needs. However, remember this code is just an example; it doesn’t conform to all of the recommendations in Howard’s Writing Secure Code (Microsoft Press, 2001), and it is not intended for use in production.

Building the Web Pages

There are actually two Web pages required for this approach: one is the logon form, which we’ll get to in a minute. The other is the page that’s displayed when the user requests access to a resource but hasn’t successfully authenticated. The ISAPI filter redirects unauthenticated users to this page; you can use it to point to the help desk, warn visitors away from your site, or do whatever else you like. Create this page, call it NoPermission.asp, and put it in the root Vdir folder of your Outlook Web Access server.

The logon page isn’t much more complicated. First, we need a function to take the user’s credentials and turn them into a cookie. This function, which should be enclosed in a SCRIPT tag on the logon page, takes the username and password from the logon form on the same page and creates a cookie named Login that contains all the parameters we need: username, password, and requested Web page. Note the use of the “;secure” flag, which tells Internet Explorer to only send the cookie over an SSL session, which is a good idea, considering that it has the unencrypted password in it!

// Set pgDomain to your DNS domain name (e.g. "@contoso.com". // It will be appended to the username before turning the // credentials into a cookie. var pgDomain pgDomain = "@webdev.mydomain.com" // Generate a cookie with the user’s credentials. If the user is able // to authenticate, but doesn’t have access to the requested page, // the filter will redirect to http://<site_root_url>/ <LoginURL>/NoPermission.asp?TargetURL= <target> function BakeLoginCookie() { // start the cookie: name it Login and add the username & password document.cookie = "Login=UserName="  + escape(document.LoginForm.txtUserName.value + pgDomain) + "&Password=" + escape(document.LoginForm.txtPassword.value) // if the login page is in a subfolder, insert its path here document.cookie = document.cookie + "&LoginURL="  + ";path=/;" + + "secure;" // Leave this here to force SSL for passing this cookie // redirect to the target URL window.location.replace( "<%=Request.QueryString("TargetURL")%>" ) }

The Web form itself is very simple; there are only two interesting things about it. First, the names for the username and password text fields must match the names specified in the function that generates the cookies. Second, notice that the Login button has a type of “button,” not “submit.” That’s because we want our cookie- making function to be called when the user clicks the button; a button of type “submit” would post the form data to the Web server, which isn’t what we want done in this case.

<FORM NAME=LoginForm METHOD=POST> User Name: <INPUT type="text"  id=txtUserName name=txtUserName size="20"><BR> Password: <INPUT type="password"  id=txtPassword name=txtPassword size="20"><BR> <INPUT type="button" value="Login"  id=btnLogin name=btnLogin onclick="BakeLoginCookie();"> </FORM>

Once you’ve created a logon page that contains the form and script elements just described, save it on your Web server, giving it a useful name like Logon.asp. This is the page that your users will have to visit to access Outlook Web Access, so make sure the name will be meaningful to the people who have to use it.

Building the ISAPI Filter

The ISAPI interfaces define a variety of events that a filter can register interest in. For our purposes, we’re interested in three events: the PREPROC_HEADERS event is generated when a page is about to be rendered for the user, the ACCESS_DENIED event is generated when a user fails the access control checks for a requested page, and the AUTH_COMPLETE event occurs when the user has successfully been authenticated by the server.

To register interest in these events, our filter has to implement the GetFilterVersion() interface, which tells IIS which specific events we’re interested in. We want to receive our notifications whether or not the user is using SSL, so we’ll set the appropriate flags and create handlers called OnPreprocHeaders(), OnAuthenticationComplete(), and OnAccessDenied. The sample implementation also does some other things that we’ll need later, including making sure that CryptoAPI is available.

The OnPreprocHeaders() function is too long to include here; its job is to take the contents of the Login cookie and base-64 encode the username and password. This saves us a step later, because basic HTTP authentication expects base-64-encoded credentials. OnPreprocHeader() also has to take care of detecting when the client is sending back an existing authentication header and of properly handling both encrypted and unencrypted requests.

Finally, OnAuthenticationComplete() checks to see whether the user is authenticated or not. If authentication hasn’t yet been completed, the function creates the correct set of headers and returns the encrypted credentials so that the client will have them. If it has already been completed, the function can just exit.

Installing the ISAPI Filter

Once you’ve built your own ISAPI filter, and tested it thoroughly in your lab, you’ll need to install it so that IIS uses it. You do this by using the Internet Services Manager snap-in. Open the Default Web Site object’s Properties dialog box from the snap-in, then click the ISAPI Filters tab. By default, on an Outlook Web Access 2000 server, you’ll only see one filter: the Microsoft Exchange Web Component filter. Click Add to select the DLL containing the ISAPI filter, which appears in the filter list. Make sure that the ISAPI filter appears above the Outlook Web Access filter so that it has a chance to authenticate users before the requests are passed to Outlook Web Access.

Controlling Access for Specific Users

You can control whether individual users can access Outlook Web Access by making the appropriate account changes from the Active Directory Users And Computers snap-in. Although doing this for users can be tedious, it offers a great way to restrict access for small numbers of users in a very precise way. There’s no integrated way to disable protocol-specific access to groups of users, although by writing a script that toggles the value of the protocolSettings Active Directory attribute, you can accomplish the desired behavior.

Anyway, to control whether a particular user can use Outlook Web Access or not, you’ll need to use Active Directory Users And Computers in advanced mode. Launch the snap-in and verify that Advanced Features is selected within the View menu. Then right-click the user you want to modify and select the Properties command. When the Properties dialog box appears, click the Exchange Advanced tab, then click Protocol Settings. When the Protocols dialog box appears, double-click HTTP, then clear the check box to disable HTTP access. Click OK twice, then close the Properties dialog box, and you’re done. You’ve just turned off Outlook Web Access for that one user on all of your Outlook Web Access servers.

Using the SMTP Addressing Trick

For a user to be able to log on to Outlook Web Access, he or she has to have an SMTP address that matches the domain name specified on the Outlook Web Access virtual directory. (The virtual directory points to the domain name’s subdirectory under the M pseudo-drive; you’ll see the full path shown in the Local Path field of the Virtual Directory tab of the virtual directory’s Properties dialog box.) This restriction leads to a slick way to control Outlook Web Access user access by groups: create a secondary recipient policy that assigns an additional SMTP address to the groups of users you want to give access to, then create a new Outlook Web Access virtual directory. For example, let’s say you only want users in the Sales organizational unit (OU) at Contoso to be able to use Outlook Web Access. Create a recipient policy that applies to that OU and assign an SMTP address, say, of sales.contoso.com, then create a matching virtual directory for Outlook Web Access.

Using Outlook Web Access Segmentation

Segmentation is a useful feature with an awkward name. First introduced in Exchange 2000 Service Pack 2, Outlook Web Access’s segmentation features allow you to control exactly which parts of Outlook Web Access a server makes available; you can also control which features individual users can access. For example, you can restrict users’ ability to use public folders, turn off new mail notifications, disable access to the Calendar, Contacts, Notes, and Journal folders, and so forth. Although this might not sound like it has anything to do with security, it does: it’s an access control method.

Segmentation gives you control over a number of features. Notice that messaging isn’t included in the list: it’s always on. You cannot disable individual users’ ability to read or send messages using segmentation. However, you can control the other things they can do by setting bits in a bit mask. There are separate bits for several Outlook Web Access features:

• When the Calendar feature is turned on, users can use the personal Calendar folder. If reminders are enabled, they can receive notifications of scheduled events that have reminders attached.

• When the Contacts feature is turned on, users can access their Contacts folder and create new subfolders inside it.

• The Tasks, Journal, and Notes features can be controlled using their respective bits in the bit mask. Unfortunately, Outlook Web Access 2000 doesn’t directly support these features, so being able to control them is relatively useless (although it does offer interesting potential for future expansion).

• The Public Folder feature controls whether Outlook Web Access shows or hides public folder-related interface items from the user. Clearing the appropriate bit turns off the link to public folders (in the folder tree control for Internet Explorer 5 and later, or in the top toolbar for other browsers).

• There are separate control options for calendar reminders and new mail notification, both of which require that the client be using Internet Explorer 5 or later and that you’ve left rich client support turned on.

• Outlook Web Access 2000 has always had two different interfaces. The rich interface offers the best functionality but requires Internet Explorer for Windows 5 or later; all other clients get the reach interface. If you want to force users of Internet Explorer 5 and later to have the reach interface, you can do so by setting this bit—it turns off the rich client features for the selected users or servers. Why would you want to do this? Consistency is one reason, but a bigger potential problem is that all of the rich client features depend on Web Distributed Authoring and Versioning (WebDAV), which might be blocked by some Web proxies. To make Outlook Web Access 2000 accessible to those clients, you’ll need to disable the rich client features.

Calculating the Segmentation Value

There are two ways to use segmentation: you can set a registry key on a single server, in which case the segmentation controls apply to that server only, or you can make a schema change and apply the segmentation value to individual user accounts using a script (or even ADSIEdit, if you’re both brave and gifted with excessive free time). In either case, you’ll need Table 14-1 to calculate the correct value; pick the features you want to enable and sum the corresponding values to get the actual segmentation value.

Table 14-1: Flag Values for Outlook Web Access Segmentation

Feature	Decimal Value	Notes
Messaging	1	You can’t turn messaging off, so this value must always be included.
Calendar access	2
Contacts folder access	4
Tasks folder access	8
Journal folder access	16	Basically useless, because Outlook Web Access doesn’t support the Journal feature.
Notes	32	Not entirely useless, because Outlook Web Access can display notes that you’ve already created.
Public folders	64
Calendar reminders	128	Only affects rich clients, because they’re the only ones that can get reminders.
New mail notifications	256	Only affects rich clients, because they’re the only ones that can get notifications.
Internet Explorer 5 and later rich interface	512
All features enabled	4095

Applying Segmentation to a Server

To force a particular server to segment its Outlook Web Access features, you’ll need to do the following:

1. Use Table 14-1 to calculate the correct segmentation value. This is pretty easy, because it only requires simple addition.

2. Open the registry editor of your choice. Use it to navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchange WEB\OWA.

3. Create a new REG_DWORD value named DefaultMailboxFolderSet. Give it the value you calculated in step 1 and specify the format as decimal.

4. Stop and restart the Exchange information store and the IIS WWW service. Because this effectively makes your server unavailable while the store and IIS restart, be careful when you do it.

5. Once the services have all restarted, verify that segmentation works properly. If not, the first thing to double-check is your segmentation value.

Applying Segmentation to Users

You can also apply Outlook Web Access segmentation to individual users and groups by changing the value of the msExchMailboxFolderSet attribute on user accounts in Active Directory. There’s one minor problem, though: that attribute doesn’t exist in a normal Exchange 2000 schema, so you’ll have to modify the schema before you can apply per-user segmentation. To make the schema change, you’ll need two files from the Server\Support\Owaschema directory of the Service Pack 2 or later distribution. The Owa-schema.ldf file is an LDAP Data Interchange Format (LDIF) file that actually contains the schema changes. Owa-schema.vbs is a small script that applies the LDIF file’s changes. To run the script successfully, you must use an account that has Enterprise Admin and Schema Admin permissions, and you’ll have to run it from a machine that can connect to the schema master. Once you’ve run the script, you must wait for Active Directory replication to complete throughout your forest.

Note

Remember that when you change even a small item in the schema, each domain’s data has to be re-replicated to the global catalogs, and the global catalogs in various domains have to exchange information. Don’t make schema changes first thing on a Monday morning!

Once the schema change has completed, you can use ADSIEdit to edit the user’s msExchMailboxFolderSet attribute; note that this value must be entered in decimal format. If you prefer, you can write a script to get the members of a security group and apply this change to their accounts, but there’s no built-in way to do so.

Tip

Microsoft Knowledge Base Article Q311154 is the official reference on how to set up segmentation for OWA.