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 or a user receives.

start sidebar
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 or an application like Outlook Web Access 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).

end sidebar
 

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 the best choice.

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 (and your ability to manage public folders from Exchange System Manager) 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 on an Exchange BE server. 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 start 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; at best, the settings might work temporarily until the next time ds2mb runs.

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. In addition, all of the Exchange virtual directories on a server must have the same authentication settings specified, or OWA won t work properly.

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-3 (this is the Windows Server 2003 version; the version you see when running Exchange Server 2003 on Windows 2000 is very similar, minus a few controls).

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

You ll have to use the IIS Manager snap-in to change authentication settings on the /exchweb/bin directory.

The authentication controls are very straightforward: there s one check box for each type of authentication that IIS supports. Note that not all of these authentication methods are actually useful for Outlook Web Access, which only supports anonymous, basic, certificate, and integrated authentication:

  • The Enable Anonymous Access check box turns anonymous authentication on or off. When it is selected, you can specify which account is used to authenticate (for example, the permissions granted to the account shown in the User Name 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. Typing a single backslash in 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. This happens automatically when you enable FBA so that users can log on with their UPNs, as previously described. Remember, though, that if you have a large number of domains, this setting adds time to the authentication process.

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

    Note  

    Typing the account name in the User Name field is prone to entry errors; 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.

Enabling Form-Based Authentication

You can enable FBA on your servers by simply selecting a check box; this is a welcome contrast to the involved (and unsupported) process required to get the same kind of functionality with Exchange 2000 Server. However, there are a couple of prerequisites. First, you must have an SSL certificate installed, and SSL must be enabled for Outlook Web Access (which is discussed later in this chapter). Second, you have to have basic authentication enabled; if you don t, selecting this check box enables it for you. Once you enable FBA, you won t be able to change the authentication settings for the virtual directories of Outlook Web Access. These requirements apply only to the FE, although if you re using FBA on an FE that s behind ISA Server (or another similar device that offloads SSL processing), you must use SSL bridging. Exchange System Manager won t allow you to enable FBA unless it sees that SSL is available on the server itself.

To actually enable FBA on your server, all you need to do is open the HTTP virtual server Properties dialog box from within Exchange System Manager (look under the server s Protocols container). Click the Settings tab (see Figure 14-4) and select the Enable Forms Based Authentication check box ”that s all you have to do!

click to expand
Figure 14-4: Enabling FBA is simple once you ve satisfied the prerequisites.

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. You could use LDIFDE to do the same thing; in fact, you could even apply permissions directly to the Exchange virtual directories in IIS, but this isn t recommended because it introduces supportability issues.

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, and click Protocol Settings. When the Protocols dialog box appears, double-click HTTP, then clear the check box to disable HTTP access. Click OK twice, 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, and 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 (note that this involves creating a custom LDAP query for the recipient policy), then assign an SMTP address, say, of sales.contoso.com, and create a matching virtual directory for Outlook Web Access.

Tip  

This behavior changes somewhat in Exchange Server 2003 Service Pack (SP) 1. By default, OWA 2003 SP1 is more flexible at accepting multiple SMTP addresses for authentication, which means that you need to add a new REG_DWORD value named DisableSMTPMailboxAddressin to the HKLM\System\CurrentControlSet\Services\MSExchangeWEB\OWA key and set it to 1. Microsoft is now recommending that you use the Deny access to this computer from the network group policy setting to prevent selected users from logging on, instead of this SMTP addressing trick.

Using Outlook Web Access Segmentation

Segmentation is a useful feature with an awkward name. First introduced in Exchange 2000 Server Service Pack 2, the segmentation features of Outlook Web Access 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. (It s also very useful for controlling the use of performance- intensive features like calendaring or spelling checker.)

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. Outlook Web Access 2003 supports tasks , but not the Journal or Notes folders.

  • 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.

  • The Exchange 2000 Server and Exchange Server 2003 versions of Outlook Web Access support two distinct interfaces for different Web clients. The premium interface offers the best functionality but requires Internet Explorer 5.01 for Windows or later; all other clients get the basic interface, which is still functional but lacks some of the niceties (including new mail and calendar notifications, drag-and-drop, spell-checking, and S/MIME support) of the premium version. 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 accessible to those clients, you ll need to disable the rich client features. As a bonus, the reach client is somewhat faster than the rich client.

  • For performance reasons you might need to turn off spell-checking on busy servers; there s a segmentation value that allows you to selectively control this feature.

  • One of the best new features of Outlook Web Access 2003 is its support for S/MIME (see Chapter 12). You can use segmentation to control which users or servers have access to this feature.

  • Outlook Web Access 2003 also adds support for two features familiar to Outlook users: signatures that can be appended to messages and an interface for editing server-side message processing rules. Both of these can be controlled by segmentation.

  • Outlook Web Access itself doesn t have a junk mail filter like Outlook does; however, if you set segmentation up to allow it, users can edit the Safe Senders, Safe Recipients, and Blocked Senders lists from within Outlook Web Access 2003.

When you disable a feature that ordinarily uses its own custom data type (for example, calendaring or contacts), OWA will treat items of that type as ordinary mail items, just like it now does for notes. Users can still see meeting requests or contact items in other folders, but they don t act like meeting requests or calendar items; instead, they act like ordinary mail messages.

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

Affected Feature

Hex Value

Notes

Messaging

0x0000 0001

You can t turn messaging off, so this value must always be included.

Calendar access

0x0000 0002

 

Contacts folder access

0x0000 0004

 

Tasks folder access

0x0000 0008

 

Journal folder access

0x0000 0010

This is basically useless, because Outlook Web Access doesn t support the Journal feature.

Notes folder access

0x0000 0020

This is not entirely useless, because Outlook Web Access can display notes that you ve already created.

Public folders

0x0000 00040

This doesn t prevent users from going straight to the /Public virtual directory on the server, but it hides the public folder links and buttons in Outlook Web Access.

Calendar reminders

0x0000 0080

This only affects rich clients, because they re the only ones that can get reminders.

New mail notifications

0x0000 0100

This only affects rich clients, because they re the only ones that can get notifications.

Internet Explorer 5 and later rich interface

0x0000 0200

Enabling this flag makes all affected users get the reach interface.

Spell-checking

0x0000 0400

When this is on, rich clients can submit messages for spell-checking.

S/MIME

0x0000 0800

When this is on, rich clients that meet the S/MIME requirements can send and receive protected messages.

Search folder access

0x0000 1000

 

Create and edit signatures

0x0000 2000

 

Create and edit rules

0x0000 4000

This applies only to server-side rules.

Change junk mail filtering settings

0x0001 0000

 

All features enabled

0xFFFF FFFF

If the value is not set, per-server or per-user, then OWA will enable all features.

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\MSExchangeWEB\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. You can use ADSIEdit, a custom script, or the ADModify tool 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 311154 is the official reference on how to set up segmentation for Outlook Web Access.




Secure Messaging with Microsoft Exchange Server 2003
Secure Messaging with MicrosoftВ® Exchange Server 2003 (Pro-Other)
ISBN: 0735619905
EAN: 2147483647
Year: 2004
Pages: 189

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net