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 3)
- Outlook Web Access Security Features (Part 5)
Introduction
If you have been reading the other three parts of this article series, you will know that so far we have covered an array of different security features related to OWA; such as the network location of the Client Access Server, authentication methods and OWA segmentation. Here in part four we are going to discuss another important area regarding OWA security, namely controlling how your users access attachments when using OWA.
OWA File and Data Access
By its very nature an email system makes it extremely easy for users to send and receive files of all different types and over the years the control of dangerous file types such as .exe, .com and so on has been controlled by many different methods. Historically, it was all too easy for an unsuspecting user to double-click an executable attachment containing malicious code and hence changes had to be made.
For Exchange 2007 OWA, it is possible for an administrator to centrally control not only the different file types that can be accessed, but also how these file types can be accessed. Furthermore, this can be controlled separately depending on whether the user is accessing OWA on a public or a private computer, as indicated by the user’s security option selection at login; this was shown in Figure 6 in part two of this article series. To see how file access is controlled for OWA 2007 you can examine the configuration in the Exchange Management Console or use the Exchange Management Shell. In the Exchange Management Console, bring up the properties of the /owa virtual directory on a Client Access Server and click either the Public Computer File Access or Private Computer File Access tab. From here, you will see options for controlling direct file access, WebReady document viewing and accessing files from either file shares or Windows SharePoint Services. The screen controlling public computer file access is shown in Figure 13. I’m going to focus on the public computer file access settings for now but note that the same options exist for private computers on that specific tab.
Figure 13: Public Computer File Access Configuration
First, let us look at the direct file access option. If you click the Customize… button, you are presented with the screen shown in Figure 14. Here you can see that you can control how your users can deal with both known and unknown file types. For the known file types, there are three lists avalable: Allow, Block and Force Save.
Figure 14: Direct File Access Settings
The Allow list is a list of file extensions that the user is able to open in OWA. Conversely, the Block list is a list of file extensions that the user is unable to open in OWA. Finally, the Force Save list is a list of file extensions that the user is forced to save to the local computer hard disk before that file can be run. There is a specific order of preference of the three levels, namely Allow, Block and then Force Save. This means that the Allow list overrides the Block and Force Save lists and the Block list overrides the Force Save list. For example, if a file extension is added to the Allow list and that extension also appears in the Block list, a user attempting to access that file extension will be granted access. At the bottom of Figure 14 you’ll also see the option for handling unknown file types which do not appear in any of the aforementioned lists. This option has a default setting of forcing the users to save the attachment first which is arguably the most appropriate default option, although high security environments could consider changing this setting to ‘block’ to block unknown file types.
When a user attempts to access a file that is configured in the Block list, the user sees the message shown in Figure 15, whereas if the file is configured in the Force Save list the user sees the message shown in Figure 16.
Figure 15: Blocked Attachment Message
Figure 16: Force-Save Attachment Message
The Allow, Block and Force Save lists are pre-populated with many different file extension types as well as MIME types. You will therefore need time to review each of these file and MIME types for suitability within your organization. Microsoft has done a good job of ensuring that the most dangerous file types are handled accordingly and many organizations may well choose to leave the default configuration as it is. Of course, each organization that runs Microsoft Exchange likely has different security requirements and so it is recommended to review the default configuration for suitability within your organization. There are so many file and MIME types configured that you may find it easier to use the Exchange Management Shell to get the default list. You can use the Get-OWAVirtualDirectory cmdlet and examine the values of the AllowedFileTypes, AllowedMimeTypes, ForceSaveFileTypes, ForceSaveMimeTypes, BlockedFileTypes and BlockedMimeTypes parameters.
For example, to obtain a list of allowed file types for the \owa virtual directory held in the default web site, you could run the following cmdlet:
Get-OwaVirtualDirectory ‘owa (default web site)’ | fl *allowedfile*
This cmdlet filters the output to show the parameters whose names contain the string allowedfile. The result is shown in Figure 17.
Figure 17: AllowedFileTypes Output
WebReady Document Viewing
WebReady Document Viewing is another excellent feature available in OWA 2007. This feature simply allows supported document types to be converted to HTML and displayed in a browser window rather than launching the relevant application. For example, this feature can be used to render Microsoft Word documents in a browser window rather than launching Microsoft Word itself. This means that the users do not necessarily need to have the application installed on their local computer in order to view the document. However, you should be aware that WebReady Document Viewing should be considered as a basic way to view documents and that documents can sometimes look slightly different when viewed this way. WebReady Document Viewing does not have all the features that would be expected of the full application. As a result, there are some limitations that should be considered such as the fact that some Excel chart types are not supported.
You will notice back in Figure 13 that it is not only possible to enable or disable this feature entirely, but it’s also possible to force the document to be converted to HTML when a converter is available. Also, don’t forget that Figure 13 shows the options for computers classified as public computers and that separate WebReady Document Viewing options are available for computers classified as private computers. In case you have forgotten, we discussed public and private computers in part two of this article series.
Let us look at what setting the option Force WebReady Document Viewing… actually means for the users. In Figure 18, you can see that the attachment is able to be opened directly as the attachment name itself is a link. Also, the attachment can be opened as a web page by clicking the [Open as Web Page] link. Conversely, Figure 19 shows the same attachment after the Force WebReady Document Viewing option has been enabled. In Figure 19, you can see that the attachment name itself is no longer a link, therefore forcing the user to click the [Open as Web Page] link.
Figure 18: Optional WebReady Document Viewing
Figure 19: Forced WebReady Document Viewing
Summary
This completes part four of this five-part article series on OWA security features. Controlling attachment access is a vital part of any Exchange deployment as it is obviously very desirable to limit the dangerous file types that can host viruses and other unwanted software. I would recommend that you take the time to evaluate the default attachment types that are allowed, blocked or configured in the force-save list. We will continue our look at WebReady Document Viewing, and also move on to cover web beacons, in the final part of this article series.
If you would like to read the other parts in this article series please go to:
