The following is tip #10 from "20 Tips on securing Outlook in 20 minutes," excerpted from a chapter in Paul Robichaux's...
book, Secure Messaging with Microsoft Exchange Server 2003 © 2004, published by Microsoft Press. Return to the main page for more tips on this topic.
- The Outlook Security Settings tab controls general settings that are applied to Outlook clients.
- The Programmatic Settings tab controls what happens when outside applications try to use certain Outlook methods and properties, including sending mail, and retrieving address information.
- The Trusted Code tab lets you specify which Outlook COM add-ins you want to allow users to run without security prompts; note that these settings don't apply to other Office applications.
The Outlook Security Settings tab
The Outlook Security Settings tab allows you to configure default settings that apply to all users. You can also apply settings to individual users or groups of users. The normal way to accomplish this is to create multiple post items using the form: one for the default settings you want to apply and one for each individual or group that needs special settings. When you use Microsoft Exchange 2000 Server or Exchange Server 2003, Outlook lets you specify Windows 2000 Server distribution groups to indicate who you want settings to apply to. If you're still hosting the folder on Microsoft Exchange 5.5, you must enter the name of each individual mailbox in the group, separated by semicolons, up to the hard-coded limit of 1000 names.
The tab controls at the very top control who this copy of the form applies to. By default, the Default Security Settings For All Users option is selected, meaning that these settings apply to all Outlook users on this Exchange server. If you want to apply these settings to a subset of your users, select the Security Settings For Exception Group option, then fill in the Security Group Name and Members fields. Here's what the rest of the form's controls do:
- The Level 1 File Extensions and Level 2 File Extensions control groups let you specify which file types are included in each group. You can add or remove attachment types by putting the extensions in the appropriate fields and saving the items; unfortunately, there's no way to see the current list of Level 1 or Level 2 extensions.
- The Miscellaneous Attachment Settings controls give you control over Outlook behavior when it encounters a Level 1 item.
- The Show Level 1 Attachments check box tells Outlook whether or not you want the names of Level 1 attachments to be visible in the InfoBar, even though users might not be able to get them.
- The Do Not Prompt About Level 1 Attachments When Sending An Item and Do Not Prompt About Level 1 Attachments When Closing An Item check boxes govern whether Outlook warns you when you include a forbidden attachment in a message you're composing.
- The Allow In-Place Activation Of Embedded OLE Objects check box controls whether Outlook allows in-place activation or not. In-place activation actually turns on an embedded application, making its menus and toolbars visible and active within the multiple-document interface (MDI) frame of an existing application. Because this actually cedes control of the current application to the automation server for the embedded object, it poses a small security risk, so Microsoft turns it off by default. This option lets you turn it on.
- The Show OLE Package Objects check box controls whether Outlook shows OLE binder objects; again, this represents a small security risk.
- The Miscellaneous Custom Form Settings control group includes some oddball options that don't really fit anywhere else. The Enable Scripts In One-Off Outlook Forms check box controls whether individual unpublished Outlook forms (that is, those distributed as .oft files or by using the Send Form Definition With Item check box when the item is sent) can run scripts or not; the remaining options regulate what happens when external code, macros, forms, or COM add-ins attempt to use the Outlook object model to execute forms' custom actions or access the properties of a form control that specifies what Outlook item it's bound to. You have three options:
- The Prompt User option causes Outlook to display a dialog box prompting the user to choose whether to allow access or not.
- The Automatically Approve option tells Outlook to allow all access without displaying a warning.
- The Automatically Deny option tells Outlook to deny all requests without asking.
The Programmatic Settings Tab
The Programmatic Settings tab features an impressive set of options. Fortunately, these break down into a fairly simple taxonomy; you use this form to specify which actions various types of code can take, according both to the requested action and the type of interface used to make the request. Applications, macros, add-ins, and other executables can use three different interfaces to request services from Outlook, as follows:
Outlook object model
The Outlook object model allows you to manipulate data stored in Outlook folders using a set of built-in interfaces that work with any language that supports COM; most of the time, people leverage this object model with code written in Visual Basic (VB) or Microsoft Visual Basic for Applications (VBA) to do this.
MAPI comes in two varieties: Simple and Extended. Simple MAPI enables developers to add basic messaging functionality, such as sending and receiving messages, to their Windows-based applications. Extended MAPI allows applications more control; it's also the only way an external application can use Outlook's data without triggering the Outlook object model guards.
CDO provides messaging and collaboration functionality; CDO lets you do things like schedule appointments, look up contacts, and perform other neat tricks. CDO 1.21 is actually a client-side COM wrapper for the MAPI library; any language that can use COM can use CDO. CDO implements most -- but not all -- MAPI functionality (but more than Simple MAPI). Don't confuse this CDO with the CDO for Exchange Management (CDOEXM) or CDOSYS libraries shipped as part of Exchange and Windows -- same name, but different functionality.
Each potential action (sending items using CDO, looking up address book items with Simple MAPI, and so on) is independently controlled. When any third-party software on the client attempts to do something, the behavior you specify takes effect: the client either approves the request automatically (which is what happens in Outlook 2000 without the security update), automatically denies it, or prompts the user (the default behavior in Outlook with the security update).
The Trusted Code Tab
The Trusted Code tab contains a list box and two buttons: Add and Remove. You use the buttons to add or remove COM add-ins to the list; Outlook clients trust (that is, allow to run) any COM Outlook add-in on the list. However, remember that specifying an add-in on this tab doesn't make it run, nor does it install it on the client. Specifying an add-in here just means that the add-in has permission to call the Outlook object model without triggering the object model guards; add-ins that call CDO are still subject to the guards.
There are a few nuances to using this tab. First of all, you can only specify Outlook add-ins, not, for example, a Microsoft Word add-in that happens to call Outlook object model functions. Second, if you later replace a trusted add-in with a newer version, you'll need to remove the old version from the list and add the new one, even if they have the same file name.
Get more "20 Tips on securing Outlook in 20 minutes!" Return to the main page.
About the author: Paul Robichaux is a partner at 3sharp LLC, author of several books on Exchange, Windows, and security, a Microsoft MVP for Exchange Server and a frequent speaker and presenter at IT industry conferences. He's written software for everyone from the U.S. National Security Agency to scientists flying their experiments aboard the Space Shuttle, fixed helicopters in the desert and spent way too much time playing video games.