Chapter 26: Using Security-related Policies | Microsoft Office 2003 Editions Resource Kit (Pro-Resource Kit)

Download CD Content

The increase in malicious attacks on corporate computers and data has forced businesses worldwide to develop better methods of protecting their data and systems. To help administrators use the security-related features of Microsoft Office 2003, policies can be enabled to turn security-related features on and off—as well as have those settings enforced at logon—for all Microsoft Windows 2000 and Microsoft Windows XP users on a corporate network.

How Policies Work

Policies are special registry entries designed to help control the configuration of either the operating system or any applications designed to respect policy settings. Applications respecting policies are expected to have an associated ADM template that administrators use to set policy entries. The ADM template must be loadable by the Group Policy snap-in that is included with Microsoft Windows 2000 and Microsoft Windows XP.

The ADM templates for use with Microsoft Office 2003 Editions applications are included with the Office Resource Kit tools. In a typical installation of the tools on the Microsoft Windows XP or Microsoft Windows 2000 platform, the templates can be found in the INF folder of the WINDIR path—for example, C:\Windows\INF. Typically, the policies for the installed operating system are found in the system.adm policy template.

As part of the design of policies, a special node exists on both the HKLM and HKCU branches of the registry. Microsoft operating systems such as Windows 2000 and Windows XP respect policy settings specifically designed for use with these systems. Policies can be used to configure the user interface to appear with specific configuration changes specially suited for a business need—such as disabling access to software, utilities, or special features of the operating system that may be deemed unnecessary or detrimental to productivity. Or, policies can be used to enable a feature that is not normally turned on when the product is installed in a default configuration.

Structure of a policy registry entry

The two most important registry branches in the registry are HKLM and HKCU. HKLM stands for HKEY_Local_Machine and HKCU stands for HKEY_Current_User. Policy settings set in the Local Machine branch are expected to apply to all users and are generally considered the most enforceable and best protected from user changes. Policy settings set in the Current User branch are specific to only the logged-on user.

Both the HKLM and HKCU registry branches are designed to have a Policies node. This is not an absolute for all custom applications, but it is the preferred design approach and is recommended for all developers. Applications are expected to follow the order of precedence indicated in the example provided below, as do all Microsoft applications designed specifically for Windows 2000 and Windows XP.

HKLM\Software\Policies\Microsoft\…
HKLM\Software\Microsoft\…
HKCU\Software\Policies\Microsoft\…
HKCU\Software\Microsoft\…

Registry entries found in the Policies node are mirror entries to those found in the non-policy entries. For example:

HKLM\Software\Policies\Microsoft\Office\11.0\Common\Toolbars

AutoExpandMenus DWORD 1

HKLM\Software\Microsoft\Office\11.0\Common\Toolbars

AutoExpandMenus DWORD 1

HKCU\Software\Policies\Microsoft\Office\11.0\Common\Toolbars

AutoExpandMenus DWORD 1

HKCU\Software\Microsoft\Office\11.0\Common\Toolbars

AutoExpandMenus DWORD 1

Any of the above registry entries would be respected by any Office 2003 application. However, the difference is that the Policies registry entry cannot be set by the user, only by the administrator who has created a POL file by using the Office11.adm policy template. However, if the user knows where this entry is in the registry, the user could manually change the entry.

Unless the permissions for the registry are set so that only the administrator can make changes, it is possible for users to defeat policy settings. Therefore, it is common practice for administrators to apply permissions to the registry in order to block changes to the Policies node by users. For Terminal Services–enabled systems, applying registry permissions is performed automatically by the operating system when Terminal Services is enabled.

It is common for the operating system and applications to respect both the HKLM and HKCU nodes of the registry if a Policies node is found in the registry.

If you develop a custom application that you want to add policy support to, there are general guidelines available within the MSDN Web site at http://msdn.microsoft.com, though there may not be support for the development of ADM templates. Examining existing ADM templates will generally provide enough information and examples for you to develop ADM templates if needed.

First-time installation policy concerns

As part of a first-time installation of Office, administrators are usually concerned about security-related policies such as:

Trust all installed add-ins and templates
Security Level (macro security)
Trust access to Visual Basic Project
Disable VBA for Office applications
Unsafe ActiveX initialization
Automation Security
Prevent users from changing Office encryption settings
Specify Trusted Alert Sources
Prevent users from uploading settings to the Internet
Feedback URL
Prevent access to Web-based file storage
Disable Information Rights Management User Interface
Disable hyperlinks to Web templates in File | New and task panes
Prevent users from customizing attachment security settings
Allow access to e-mail attachments
Outlook virus security settings
Configure Add-in Trust level
Task Manager security key
Prohibit access to Control Panel
Prevent access to the Command Prompt (DOS window)

Each of these policies is available within the various Office 2003 ADM policy templates. Their related non-policy registry entries are usually also settable through the Custom Installation Wizard and the Custom Maintenance Wizard within the Change Office User Settings and the Specify Security Settings pages. By setting non-policy registry entries in three places—in the Specify Security Settings page, through the Change Office User Settings page, and then in the Group Policy snap-in—the desired settings are enforced in all possible places. And if permissions to the registry nodes are set to only accept changes from administrators, the settings are enforced to the greatest extent possible. However, if a user gains access to the most secure and highest order of precedence settings (usually the HKLM node), the user can defeat the setting.

Administrators should guard their user accounts and review the Administrators network group account to be sure no one has forged access to permission-restricted levels of their systems.

Important policies

Following are noted the registry settings for important policies that were requested by administrators. The ActiveX control initialization registry entry is somewhat complex in that it has six possible settings (even though only three are revealed through the Custom Installation Wizard and Custom Maintenance Wizard). Administrators who need to set ActiveX initialization to a more refined setting can review the following ActiveX initialization documentation.

Macro security level

If you use the Specify Office Security Settings page of either the Custom Maintenance Wizard or the Custom Installation Wizard, and you change the Default Security Level for an application, this process is the same as using the Security dialog box available through the application’s user interface. Use of this registry entry sets the macro security level for each application specified in the <APP> portion of the key to the respective value data listed here.

<APP> = Word, Excel, Access, PowerPoint, Publisher, Outlook

HKCU\Software\Microsoft\Office\11.0\<APP>\Security

The parallel policy key is:

HKLM\Software\Policies\Microsoft\Office\11.0\<APP>\Security

Value name: Level

Value type: REG_DWORD

Value data: [ 1 | 2 | 3 ]

1. Low

2. Medium

3. High

Use of the policy is recommended in situations where you never want users to have the ability to change the macro security level.

ActiveX initialization

Through the use of the common security key, you can instruct Office to set ActiveX initialization security for all Office applications. This registry entry can be set by using the Specify Office Security Settings page of either the Custom Installation Wizard or the Custom Maintenance Wizard.

HKCU\Software\Microsoft\Common\Security

The parallel policy key is:

HKLM\Software\Policies\Microsoft\Common\Security

HKCU\Software\Policies\Microsoft\Common\Security

The value name UFIControls can be set for either of these nodes to the following values and respective actions:

Value name: UFIControls

Value type: REG_DWORD

Value Data: [ 1 | 2 | 3 | 4 | 5 | 6 ]

Safe For Initialization (SFI) is a term used by ActiveX developers to mark a control as being safe to open and run and not capable of causing ill effects to any systems, regardless of whether it has persisted data values or not. If a control is not marked SFI, it is possible for the control to adversely affect a system—or it is merely possible the developers did not test the control in all situations and are not sure whether their control may be compromised at some future date.

The value data can be explained as follows:

Regardless of how the control is marked, load it and use the persisted values (if any). This setting does not prompt the user.
If SFI, load the control in safe mode and use persisted values (if any). If not SFI, load in un-safe mode with persisted values (if any), or use the default (first-time initialization) settings. This setting does not prompt the user.
If SFI, load the control in un-safe mode and use persisted values (if any). If not SFI, prompt that it is marked unsafe. If the user chooses No at the prompt, do not load the control. Otherwise, load it with default (first-time initialization) settings.
If SFI, load the control in safe mode and use persisted values (if any). If not SFI, prompt that it is marked unsafe. If the user chooses No at the prompt, do not load the control. Otherwise, load it with default (first-time initialization) settings.
If SFI, load the control in un-safe mode and use persisted values (if any). If not SFI, prompt that it is marked unsafe. If the user chooses No at the prompt, do not load the control. Otherwise, load it with persisted values.
If SFI, load the control in safe mode and use persisted values (if any). If not SFI, prompt that it is marked unsafe. If the user chooses No at the prompt, do not load the control. Otherwise, load it with persisted values.

If you are a programmer interested in knowing more about ActiveX controls marked as SFI, see the documentation on ActiveX control development for information about safe mode for ActiveX controls. Look for the following object and method: IObjectSafetyImpl::SetInterfaceSafetyOptions. The IObjectSafety interface allows a client to retrieve and set an object’s safety levels. For example, a Web browser may call IObjectSafety::SetInterfaceSafetyOptions to set a control to safe for initialization or safe for scripting.

Note

Not all ActiveX controls respect the safe mode registry setting and therefore may load persisted data even though you instructed the control to use safe mode from this registry setting.

When setting the Unsafe ActiveX Initialization option in the Custom Installation Wizard or Custom Maintenance Wizard, the following conditions apply:

Prompt user to use control defaults Sets the UFIControls registry entry to a data value of 4. If the control is marked Safe For Initialization (SFI), the control is loaded in safe mode and uses any persisted values. If the control is not marked SFI, the user is prompted that the control is marked unsafe. If the user chooses No at the prompt, the control is not loaded at all. If the user chooses Yes, the control is loaded with default (first-time initialization) settings.
Prompt user to use persisted data Sets the UFIControls registry entry to a data value of 6. If the control is marked Safe For Initialization (SFI), the control is loaded in safe mode and uses any persisted values. If the control is not marked SFI, the user is prompted that the control is marked unsafe. If the user chooses No at the prompt, the control is not loaded at all. If the user chooses Yes, the control is loaded with persisted values.
Do not prompt Sets the UFIControls registry entry to a data value of 1. This setting loads the control, uses any persisted data, and runs it regardless of whether or not the control is marked as SFI.
<do not configure> Leaves the default configuration for this option set to 3—Prompt user to use control defaults.

It is possible for an administrator to set the ActiveX initialization settings to one of the six possible values by using the Add/Remove Registry Entries page of either the Custom Installation Wizard or the Custom Maintenance Wizard.