Controlling Access to Message Attachments Through OWA, Part 2
In the first part of this article series, I gave you a general description of the options that are available to you for controlling the way that users are allowed to access message attachments through OWA. In this article, I want to continue the discussion by giving you some more specific information on how to implement the restrictions that I have already talked about in the previous article.
Public VS. Private
As I mentioned in the previous article, OWA maintains two separate profiles; one for public computers, and one for private computers. For the purposes of this article, I will be working with the Private Computer File Access profile. Keep in mind though that the exact same techniques can be used to configure the Public Computer File Access Profile.
Direct File Access
To begin configuring OWA file access, open the Exchange Management Console, and navigate through the console tree to Server Configuration | Client Access. Next, select your client access server and click the Properties link. When you do, the console will display the OWA (Default Web Site) Properties sheet. Go to the properties sheet’s Private Computer File Access tab, shown in Figure A.
Figure A The Public Computer File Access tab is used for configuring file access through OWA while logged in through a private computer.
The first section listed on this tab is the Direct File Access section. Direct file access refers to being able to open attached files through OWA. To configure direct file access, click the Customize button. When you do, you will see the Direct File Access Settings dialog box, shown in Figure B.
Figure B The Direct File Access dialog box allows you to configure direct file access.
As you can see in the figure, this dialog box is divided into several sections. The Always Allow section found at the top of the dialog box allows you to specify which types of files users should always be allowed to open through OWA. Even in a high security environment, users are typically allowed to open JPG files and sound files.
The Always Block section allows you to specify the types of files which should never be allowed to be opened through OWA. For example, .PIF (Program Information Files) are a leftover from Windows 3.x, but for some reason are still functional. In this day and age, .PIF files are almost always malicious, and should therefore always be blocked.
The Force Save section allows you to specify which types of files must be saved to disk prior to being open. The main reason why this feature exists is to protect your organization against unintentional disclosure of sensitive information.
I’ve already showed you how OWA maintains one profile for users who are using a public computer, and another profile for users who are logged on through a private computer. Ultimately though, it’s up to the user to tell OWA which type of computer they are using. OWA has no way of knowing whether the computer is public or private.
Unfortunately, some users will likely lie to OWA and tell it that they are using a private computer, even if they are attached from a public kiosk, because the private computer profile is typically less restrictive.
So what does this have to do with forcing users to save files to disk? Well, the presumption is that most public computers are going to be locked down to the point that the user cannot save an e-mail attachment to disk. Therefore, forcing a user to save an attachment to disk is kind of like having an extra validation that the user really is using a private computer. Of course this technique isn’t full proof, but it does give you a little bit of extra security.
The last section on the Direct File Access Settings dialog box allows you to control how OWA deals with unspecified file types. The default behavior is to force users to save these files to disk prior to opening them, but you also have the option of allowing or blocking such files.
In this article, I have explained that administrators need to regulate the types of attachments that they allow users to open through OWA. I then went on to demonstrate some of the regulatory mechanisms that are available to you. In the next article, I will conclude the series by talking about Web Ready Document Viewing.
Got a question? Post it on our Exchange Server Forums!
More in Exchange Server
M365 Changelog: Get-AdvancedThreatProtectionDocumentReport and Get-AdvancedThreatProtectionDocumentDetail to be retired
May 24, 2022 | Petri Staff
M365 Changelog: (Updated) Microsoft Defender for Office 365: Updates to URL Protection Report
May 24, 2022 | Petri Staff
M365 Changelog: Safe Links Global Settings Migrated to Custom Policies
May 20, 2022 | Petri Staff
Microsoft to Ship Some Exchange Server Security Updates in .EXE Packages
May 11, 2022 | Rabia Noureen
M365 Changelog: Exchange Transport Rule Report moving to the new Exchange Admin Center (EAC) from the Security and Compliance Center
Apr 22, 2022 | Petri Staff
Hive Ransomware Group Attacks Vulnerable Microsoft Exchange Servers
Apr 22, 2022 | Rabia Noureen
Most popular on petri