The Microsoft .NET Framework provides two major ways for you to deploy policy:

• Building a Windows Installer (.msi) file by using the .NET Framework Configuration tool. For more information, see Deploying Security Policy.

• Modifying policy directly by scripting against the Code Access Security Policy tool (Caspol.exe). For more information, see Configuring Security Policy Using the Code Access Security Policy Tool (Caspol.exe).

Using a Windows Installer file allows more predictable policy evaluation because the entire policy level (typically Enterprise or Machine) is copied to the end user's computer; however, this can create conflicts if different groups within a company want to publish policy independently of each other, or if individuals need to make changes to their policy.

Using Caspol.exe to modify policy allows different people to update policy independently of each other, but any given policy change is not guaranteed to have the desired effect because of unknown interactions between different code groups. For example, if one department deploys a policy change granting full trust to a particular intranet site, that department expects all code coming from that site to be trusted. But if another department deploys policy with an Exclusive attribute denying access to that site, then no code will run. For more information about the Exclusive attribute, see Administration with Code Group Attributes and How to: Make Code Groups Exclusive or Level Final.

Administrators need to balance the predictability of Windows Installer files with the flexibility of Caspol.exe in deciding how to update policy.

Note that while it is also possible to write managed code to directly manipulate policy through the Microsoft .NET Framework APIs, it is hard to create policy correctly this way and the practice is highly discouraged.

If an assembly does not execute, you can investigate the possible cause by reviewing the permissions assigned to that assembly. The Microsoft .NET Framework provides two ways of checking the current policy for an assembly:

• Using the Evaluate an Assembly wizard that is included in the Microsoft .NET Framework 2.0 Configuration tool. For information about accessing this wizard, see How to: Perform Common Security Policy Tasks Using the .NET Framework Configuration Tool (Mscorcfg.msc).

• Running the following commands in Caspol.exe:

  caspol -all -lg caspol -rsg path_to_assembly

  For more information about Caspol.exe commands, see Code Access Security Policy Tool (Caspol.exe).

These tools show the security policy that is applied to the assembly, and how the evidence of the assembly maps to those rules in the common language runtime (CLR). This reveals whether the policy is set up correctly, and whether the assembly matches the correct code groups. Primary problems that are revealed using this technique include the following problems:

• A network rule (for example, assigning full trust to http://server/) was added to the MyComputer zone when it should be in LocalIntranet, or it was added to LocalIntranet when it should be in TrustedSites.

• There is an error in the file name or URL.

• The directory path is missing the asterisk (*) that indicates that all files and subfolders beneath that folder should be included in the policy.

For more information, see Resolving Security Policy Issues Using Caspol.exe.

Visual Studio enables enterprises to define their own default policy. Normally, when you perform a reset on the security policy, the policy reverts back to the default settings that are present when the Framework is installed. Using the Enterprise-specific default policy, a reset restores the basic policy as defined by the particular enterprise. For example, the enterprise might add a trusted publisher to the Enterprise level, and block all code from the Internet zone.

For more information about returning to default policy, see How to: Return to the Default Security Policy Settings Using Caspol.exe and .NET Framework Configuration Tool (Mscorcfg.msc). For more information about default security policy, see Default Security Policy.

Consider the following guidelines when determining policy for your Office solutions:

• Always use named code groups rather than relying on their numbers (for example, use MyComputer_Zone instead of 1.1). Though it is possible for a user to rename a group (for example, renaming Internet to MyComputer), it is less likely than the chance of the numbers changing.

• Be as restrictive as possible in what code a rule will apply to. Never add rules to the All_Code group at the Machine level; always add them to a Zone or another sub-group under Zones. It is better not to have rules governing code that you do not expect.

• Have the most broadly applicable rules first, for example zone, then site, then publisher, instead of publisher, then site, then zone. That way, the specific zone rules can be applied to specific code, and will not be applied to all the code from the publisher before you find out whether the restrictions are needed.

• If a parent group, for example the LocalIntranet_Zone group, no longer exists, you should recreate it. Note that you must do so with the Nothing permission set. The Nothing permission set prevents default permissions from being applied that the administrator has turned off by deleting the code group. For example, if the administrator deletes LocalIntranet_Zone, then all local intranet code stops running. When you recreate the code group and use the Nothing permission set, no permissions are added that were not there before.

• Turn off policy change warnings in batch files, and remember to turn them on again afterward if they were on to begin with. That way, your batch files will not be stopped, waiting for user input. This setting affects all users, not just the current user. For more information, see How to: Suppress Policy Change Warnings Using Caspol.exe.

• When using Caspol.exe, explicitly specify the policy level to modify (Enterprise, Machine, or User); do not rely on the default. The default might not be correct for the policy you are modifying. For more information, see Security Policy Levels.

• Do not use the Exclusive or Level-Final attributes unless absolutely necessary, because they can cause unexpected behavior if a new code group is added. For more information, see Code Group Attributes.

Concepts

Other Resources