Customizing the Security Update

Although Outlook defaults to very stringent security controls out of the box, you can customize the security update for your environment. You can ease some of the restrictions by using the Administrative Security Package, which is included with the book's companion content. Rather than describe every aspect of the package, I'll simply highlight some of the features; see the book's sample files and the documentation for the package for complete details.

The Administrative Security Package

The administrative security package includes a number of tools to help you administer the Outlook Security Update:

• OutlookSecurity.oft     This Outlook template, when used with the security public folder (described in the next section), allows you to customize the security settings for your Outlook user base.

• Hashctl.dll     This DLL is used by the security settings template to specify trusted COM add-ins.

• Comdlg32.ocx     This is the ActiveX control for common dialog boxes that allows the security settings template to show the File dialog boxes in which you can select a trusted COM add-in.

• Readme.doc     You should read this document before you attempt to modify any of the security settings in Outlook. It describes the security settings you can manipulate with the administrative security package.

Public Folder for Security Settings

Before you can modify any security setting, you must create a public folder on your Exchange Server. This public folder must be named either Outlook Security Settings or Outlook 10 Security Settings, and it must be created in the root of your public folder tree. You should then modify the security settings on the folder so that only administrators can modify the items within it and all users have only read permission for the folder. This folder is used to store the security template and any security overrides that you set. In addition, Outlook automatically synchronizes this folder with the offline store of any Outlook user who uses an .ost file.

Outlook Security Form

After you set up your public folder, you can use the OutlookSecurity.oft file to set your security settings. You should first publish this form to the public folder you created. One convenient feature of the administrative security package is that you can set custom security settings for all users or you can make individual settings for a group of users. The readme file included with the administrative package has all the information you need to set up custom security. Figures 5-8 and 5-9 show the first two tabs of the Outlook form that you use to customize your security settings.

Figure 5-8: The Outlook Security Settings tab of the Outlook custom security form

Figure 5-9: The Programmatic Settings tab of the Outlook custom security form

The last tab of the custom Outlook security form, the Trusted Code tab (shown in Figure 5-10), lets you specify which COM add-ins will be trusted.

Figure 5-10: The Trusted Code tab of the Outlook custom security form

Outlook 2002 and 2003 support trusted COM add-ins. Outlook 2000 does not differentiate among COM add-ins, which means that every COM add-in in Outlook 2000 is trusted. When an add-in is trusted, it has full access to the Outlook object model. Calls from the COM add-in to the restricted properties or methods in the object model will not display prompts to the user.

This trust mechanism is powerful, but it does have some limitations. First and foremost, only a certain version of a COM add-in is trusted. Outlook takes a hash of the add-in DLL at the time you trust it and stores that hash in the form. Recompiling the add-in changes the value stored in the hash and the hash value that Outlook determines at run time for your COM add-in. So if you recompile your add-in after designating it as a trusted add-in on the custom security form, you will have to remove the add-in and then add it back to the trusted COM add-in list before deploying the add-in again.

Even though you can trust COM add-ins to have unrestricted access to the Outlook object model, this trust mechanism does not extend to CDO. If your trusted COM add-in calls any restricted CDO object model properties or methods, you must enable the security access for that CDO call on the Programmatic Settings tab of the Outlook custom security form. If you don't care whether users are prompted for that portion of the code in your add-in, you don't have to perform this step. However, opening CDO calls such as these to your users also opens the calls to virus writers. You should carefully weigh the risks of lowering your security settings against your ability to block viruses from entering your system as a result of lowered security settings.

Keep in mind that your COM add-in is passed an Outlook Application object as part of its OnConnection event. This Application object and all of its child objects are trusted. This means that calls from this object to restricted methods do not display warnings. However, if you create new Outlook objects programmatically by using GetObject or CreateObject , these new objects will not be trusted and will force warnings to appear to the users of your application.

Note  

One good security change in Outlook 2003 is that if a form that sends mail or normally would trigger the security dialog boxes is published, it will not trigger the security update. This change is currently for Outlook 2003 only and has not been back-ported to previous versions of Outlook.