If you would like to read the other parts in this article series please go to:
- Outlook Web Access Security Features (Part 1)
- Outlook Web Access Security Features (Part 2)
- Outlook Web Access Security Features (Part 4)
- Outlook Web Access Security Features (Part 5)
Introduction
Part two of this article series focused entirely on the authentication methods available in OWA 2007. I want to start part three of this article series by completing the topic of authentication by covering a few key points on which authentication method should be used. Once we’ve done that, we will then take a look at the OWA segmentation feature.
OWA Authentication – Which Method?
The question of whether to use forms-based authentication or standard authentication depends largely on your infrastructure and requirements. For example, ISA Server 2006 also comes equipped with forms-based authentication which can be enabled if required. If your internal Exchange 2007 organization is protected by ISA Server 2006, you may want to implement Integrated Windows authentication on the Client Access Server rather than forms-based authentication otherwise users will be presented with two forms, one for the ISA Server and one for the Client Access Server. With forms-based authentication configured on the ISA Server and Integrated Windows authentication configured on the Client Access Server, the user is only presented with the form once. When the user has entered their user account details into the form and been authenticated by ISA Server, the connection to the Client Access Server, and thus OWA, is made automatically via Integrated Windows authentication.
Having said this, the subject of different user experiences does sometimes need to be addressed. For example, users connecting externally to OWA will be presented with the ISA Server forms-based authentication screen whereas internally the same user will be logged on automatically via Integrated Windows authentication. Some organizations choose to combat this issue by deploying additional internal Client Access Servers, or even additional internal ISA Servers, and configure these with forms-based authentication to ensure that a consistent user experience is seen no matter whether the user is connecting to OWA internally or externally.
Also, you have to consider the requirements of other important Client Access Server technologies, such as CAS-to-CAS proxying. Take the example scenario where a user connects via OWA to a Client Access Server that is in a different Active Directory site to that of the mailbox server hosting that user’s mailbox. In this case, the Client Access Server that the user connects to is able to locate a Client Access Server that is in the same Active Directory site as the user’s mailbox server and can proxy the user request to that Client Access Server. This proxy request is known as CAS-to-CAS proxying. However, in order for this process to work, the Client Access Server in the same Active Directory site as the user’s mailbox must have Integrated Windows authentication set on the virtual directory that is being accessed.
When considering the choice between the different standard authentication methods, one of the primary considerations is the fact that cached credentials can pose a security risk for the organization if OWA is used from public locations. This is mainly a concern if the user is unable to close the browser after accessing OWA; if the browser cannot be fully closed, there is the risk that other users will be able to access the OWA session as credentials are cached within the browser.
Take the time to research your authentication requirements before choosing one, particularly when complimentary security products such as ISA Server 2006 are being used.
OWA Segmentation
OWA segmentation is another feature that has been present in some legacy versions of Exchange and is therefore not a feature that’s new to Exchange 2007. Essentially OWA segmentation is a feature that allows you to block access to specific features of OWA for either some or all users. For example, suppose that you transition your Exchange 2003 environment to Exchange 2007 and at the same time decide to migrate your public folder information to Microsoft SharePoint. If you have also deployed the Outlook 2007 client, there is now no need to use public folders within your environment and so you may choose to block access to public folders from within OWA. Figures 9 and 10 show you the difference between an OWA client with public folders enabled, and one where public folders have been disabled via OWA segmentation. As you can see from Figure 10, the public folder button is entirely missing.
Figure 9: Public Folders Available in OWA
Figure 10: Public Folders Disabled in OWA Via OWA Segmentation
Or, perhaps you have not deployed Exchange ActiveSync devices or the Unified Messaging server role within your organization. Again, it may be worth considering disabling these features so that the options do not appear in Outlook Web Access. Any configuration item that simplifies the user experience and possibly prevents a helpdesk call can only be a good thing.
It is possible to configure OWA segmentation for quite a range of features. The list includes ActiveSync integration, address lists, calendar, contacts, journal, junk email, reminders and notifications, notes, premium client, search folders, email signature, spelling checker, tasks, theme selection, unified messaging integration, change password, rules, public folders, S/MIME and deleted item recovery.
You can control OWA segmentation for an entire virtual directory on a Client Access Server or on a per-user basis. Let’s look at the controls for an entire virtual directory first, starting with the Exchange Management Console. To access the segmentation controls, bring up the properties of the /owa virtual directory and click the Segmentation tab. Figure 11 shows the contents of this tab.
Figure 11: OWA Segmentation Tab
As you can see from Figure 11, it is very straightforward to understand how to enable or disable a specific feature for OWA segmentation; you simply have to select the relevant feature and click the enable or disable button as required.
Note:
You can only configure segmentation on the /owa virtual directory, so do not go looking for the segmentation tab on the other virtual directories, such as /exchange, that you may have on your Client Access Server.
To use the Exchange Management Shell to configure segmentation, use the Set-OwaVirtualDirectory cmdlet. For example, if you wanted to obtain the properties of the /owa virtual directory on a server called CCR-SRV1, the following cmdlet would be used:
Get-OwaVirtualDirectory ‘CCR-SRV1\owa (Default Web Site)’
This cmdlet will return many parameters. Figure 12 shows some of the output of this cmdlet, where you can see the status of each of the segmentation values. You can see towards the top of Figure 12 that the Tasks feature has been disabled in OWA.
Figure 12: Output of Get-OwaVirtualDirectory Cmdlet
As briefly mentioned earlier in this section, it’s also possible to configure OWA segmentation on a per-user basis and to do this the Set-CASMailbox cmdlet can be used. For example, let’s assume that we wish to disable the Tasks feature for one specific user that has a mailbox alias of neil. We can use the following cmdlet to achieve our goal:
Set-CASMailbox –Identity neil –OWATasksEnabled:$false
You’d then obviously need to use the Get-CASMailbox cmdlet to verify that the setting was in place. Also, note that the per-user settings override those made on the virtual directory.
Summary
That concludes part three of this article series on OWA security features found in Exchange 2007. This part of the article series has covered a few important areas to consider when choosing between the various authentication methods and then moved on to the OWA segmentation feature. OWA segmentation can often be overlooked when configuring Exchange 2007 but it’s worth remembering that configuring it can help to give the users a consistent look and feel when using Outlook compared to OWA.
If you would like to read the other parts in this article series please go to:
