Export (0) Print
Expand All

.NET Framework Enterprise Security Policy Administration and Deployment

 

Microsoft Corporation

January 2002

Summary: This document answers some of the most common questions asked about the administration and deployment of code access security policy in enterprise settings. (6 printed pages)

Questions covered include:

Can I deploy security policy across an enterprise network?

How do I create a security policy deployment package?

How do I distribute the policy deployment package across my enterprise?

Can I write scripts to change security policy instead of distributing Microsoft Windows Installer package files?

How do I change security policy to merge my enterprise policy settings with local machine or user settings?

Can I prevent local user and machine policy from interfering with specific enterprise policy settings I have made?

How do I change security policy so that a specific application or software publisher always receives a certain level of trust on client machines?

How do I change security policy so that assemblies from a specific zone, assembly, or software publisher cannot run on my enterprise network?

How can I test my policy changes?

  1. Can I deploy security policy across an enterprise network?

    Yes. In most cases there are two basic steps you need to follow:

    1. Create a security policy deployment package.
    2. Distribute the deployment package across your enterprise.

    You can also write and distribute batch scripts for security policy deployment. See Question #4 for more information on using scripts to change security policy.

  2. How do I create a security policy deployment package?

    Microsoft® .NET Framework ships with a graphical user interface (GUI) configuration tool that you should use to make security policy changes. This tool also contains a wizard that helps you create a self-contained Microsoft Windows® Installer package file (.msi) out of a security policy level.

    Follow these steps to start the tool:

    1. Open Control Panel.
    2. Open the Administrative Tools folder.
    3. Double-click Microsoft .NET Framework Configuration.

    Security policy is administered through settings at three policy levels. The tool can wrap any of the three administrable policy levels into an .msi file that you can then deploy. In most cases you will want to deploy the enterprise policy level. For more information on the policy model, search for security policy in the index of the SDK documentation and select the management subtopic.

    In order to create a deployment package from a policy level in the .NET Framework Configuration tool:

    1. Right-click the Runtime Security Policy node.
    2. Select the Create Deployment Package wizard.
    3. Select the policy level you want to distribute.
    4. Select a file name and location where the wizard should store the deployment package.

    Once you have created the deployment package you are ready to deploy it across your enterprise.

  3. How do I distribute the policy deployment package across my enterprise?

    The .NET Framework Configuration tool generates a Microsoft installer package file (.msi) that contains the installation directions and the content of a policy level. See question two for information on creating an .msi file. The .msi file is self-contained, and can be invoked in many different ways. This leaves you with many deployment options; however, the easiest way to get an .msi file installed across your enterprise is by using Group Policy.

    Follow these steps to distribute the deployment package:

    1. Start the Group Policy Editor.

      a) From the Start menu, choose Run.

      b) In the Open box, type "MMC.EXE" and click Enter.

      c) On the File menu, select the Add/Remove Snap-in option.

      d) Click Add.

      e) Select the Group Policy option, and click Add.

      f) Click Close, and in the Add/Remove Snap-in window, click OK.

    2. Select the Group Policy object containing the machines you wish the policy file to propagate to.
    3. Drag-and-drop the .msi file onto the network node that represents the deployment scope for the policy change.

    Group Policy requires the enterprise to be running Microsoft Windows 2000 or later. You may alternatively use Systems Management Server (SMS), if it is installed on your enterprise. Refer to the SMS documentation for information on how to use SMS to deploy an .msi file across your enterprise.

    Note   The installation package will cause the local policy level to be completely replaced with the one contained in the deployment package. See Question #6 for information on how to least affect user and machine policy settings.

    All security policy is versioned. There is a user, machine, and enterprise policy level file for each version of the .NET Framework installed on your enterprise. Since the .msi file created by the administration tool only overwrites the policy file for a particular version, you need to deploy enterprise policy .msi files for all versions of the .NET Framework installed on your enterprise. This will only become necessary once multiple versions of the .NET Framework are available.

  4. Can I write scripts to change security policy instead of distributing Microsoft Windows Installer package files?

    Yes. Using the Code Access Security Policy tool (Caspol.exe) you can write batch file scripts to affect security policy changes. As the first command in the script, enter caspol –pp off to turn the policy change prompt off, unless you are certain that has already been done on the current machine. You should script against code group names rather than their numeric labels, since the labels can easily get reordered after a policy change. See the .NET Framework SDK for more information on the Caspol tool.

  5. How do I change security policy to merge my enterprise policy settings with local machine or user settings?

    The .NET Framework ships with three administrable policy levels. The machine and user policy levels are intended for policy changes that machine administrators and machine users may wish to undertake. They are scoped to be either machine- or user-context bound. The enterprise policy level, however, is intended to carry enterprise-wide security policy configuration state. Machine and user policy settings will still apply, unless explicitly prevented from doing so, but neither will succeed in granting more trust than what the enterprise policy grants. If you are interested in giving users and machine administrators the possibility of further restricting policy settings, you should always use the enterprise policy level to modify security policy for the enterprise.

    Note   There is also an application domain policy level that can be programmatically defined by a host. If present, it will never be skipped during policy evaluation and it is the fourth element of the security policy state of a machine. This document refers to the user, machine and enterprise policy levels as administrable policy levels, since they are the only policy levels for which there exists a persisted policy file that administrators can alter via the administration tool.
  6. Can I prevent local user and machine policy from interfering with specific enterprise policy settings I have made?

    Users or machine administrators can further reduce the level of permissions granted to a specific assembly from the enterprise policy level. You can stop this by using code groups with a LevelFinal attribute at the enterprise policy level. This attribute will prevent the evaluation of any administrable policy levels below the one in which it is applied. If a code group in enterprise policy is marked with the LevelFinal attribute, and during policy evaluation of enterprise policy this code group applies, then machine and user policy are not evaluated and the only permissions an assembly matching this code group gets are those handed out by the enterprise policy level.

    Follow these steps to turn on the LevelFinal attribute on a code group in enterprise policy:

    1. Open Control Panel.
    2. Open the Administrative Tools folder.
    3. Double-click Microsoft .NET Framework Configuration.
    4. In the Microsoft .NET Framework Configuration tool, open the Runtime Security Policy node.
    5. Open the Enterprise policy level.
    6. Open the Code Groups folder and right-click the code group that you want to mark with the LevelFinal attribute.
    7. Select the Properties option.
    8. On the General tab, check the Policy levels below will not be evaluated box.
    9. Click Apply.
  7. How do I change security policy so that a specific application or software publisher always receives a certain level of trust on client machines?

    Follow these steps:

    1. Open Control Panel.
    2. Open the Administrative Tools folder.
    3. Double-click Microsoft .NET Framework Configuration.
    4. In the Microsoft .NET Framework Configuration tool, open the Runtime Security Policy node.
    5. Open the Enterprise policy node.
    6. Open the Code Groups folder.
    7. Right-click the All_Code code group and select the New option.
    8. Enter the name and description of your new code group, and click Next.
    9. Select the Strong Name or Publisher membership condition type, and click Import to select the assembly that you want to have a high level of trust across the enterprise. If the assembly is not signed, you can use the Hash membership condition instead. If you want all assemblies by the respective publisher to receive high levels of trust across the enterprise, uncheck the Version and Name properties for Strong Name membership conditions, or simply use the Publisher membership condition.
    10. Click Next, and then select or create the permission set you want the assembly or assemblies to receive. For unhindered access to all resources, select the FullTrust permission set.
    11. Finish the wizard.
    12. Right-click the newly created code group.
    13. Select the Properties option.
    14. On the General tab, select This policy will only have the permissions from the permission set associated with this code group to make this code group exclusive with respect to all other code groups of that policy level.
    15. On the General tab, select Policy levels below this level will not be evaluated to make this code group a LevelFinal code group, preventing evaluation of the machine and user policy if this code group applies.
    16. Right-click the Runtime Security Policy node.
    17. Select the Create Deployment Package wizard, and use it to create a deployment package of the Enterprise policy level.
    18. Deploy the .msi file using either Group Policy or Systems Management Server (SMS). See Question #3 for more details on deployment.
    Note   Step 15 bypasses the FullTrust permission set grant from the All_Code code group in default policy by making your new code group exclusive. This excludes any permission contribution from other code groups at that policy level. You should never introduce additional exclusive code groups if you know that two or more exclusive code groups will apply simultaneously to an assembly or set of assemblies.
    Note   Step 16 will cause the machine and user policy levels to be skipped if your new code group applies. Do not use this attribute too widely in enterprise policy, because when you do, policy customizations that the machine administrator or user may have done will not be effective.
  8. How do I change security policy so that assemblies from a specific zone, assembly, or software publisher cannot run on my enterprise network?

    Follow these steps:

    1. Open Control Panel.
    2. Open the Administrative Tools folder.
    3. Double-click Microsoft .NET Framework Configuration.
    4. In the Microsoft .NET Framework Configuration tool, open the Runtime Security Policy node.
    5. Open the Enterprise policy node.
    6. Open the Code Groups folder.
    7. Right-click the All_Code code group and click New.
    8. Enter the name and description of your new code group.
    9. Select the appropriate membership condition. Select Zone if you want to prevent all code from a specific zone from running, or select Publisher if you want to block execution of all code with a specific Authenticode™ signature.
    10. For the permission set, select Nothing.
    11. Finish the wizard.
    12. Right-click the newly created code group.
    13. Click Properties.
    14. On the General tab, select This policy will only have the permissions from the permission set associated with this code group to make this code group exclusive with respect to all other code groups of that policy level.
    15. Right-click the Runtime Security Policy node.
    16. Select the Create Deployment Package wizard, and use it to create a deployment package of the Enterprise policy level.
    17. Deploy the .msi file using either Group Policy or Systems Management Server (SMS). See Question #3 for more details on deployment.

    If you used a membership condition other than hash, strong name, or publisher, you might want to run the GUI administration tool or other Microsoft components from that location. If so follow these steps:

    1. Under the Runtime Security Policy node, open the Machine policy node.
    2. Open the Code Groups folder.
    3. Open the All_Code code group subtree.
    4. Right-click the Microsoft_Strong_Name code group, and click Copy.
    5. Under the Runtime Security Policy node, open the Enterprise policy node.
    6. Open the Code Groups folder.
    7. Right-click the All_Code code group and click Paste.
    Note   These procedures presume that security policy has not been altered significantly from the default state.
  9. How can I test my policy changes?

    The .NET Framework Configuration tool contains a wizard that you can use to view the permissions given to an assembly by current security policy. Follow the below steps to access this wizard:

    1. Open Control Panel.
    2. Open the Administrative Tools folder.
    3. Double-click Microsoft .NET Framework Configuration.
    4. In the Microsoft .NET Framework Configuration tool, right-click the Runtime Security Policy node.
    5. Select Evaluate Assembly.
    6. Browse to or type in the location of the assembly you wish to test.
    7. Under Choose the type of evaluation, indicate whether you want to see the permissions the assembly receives from policy or which code groups in security policy apply to it.
    8. Keep the All Levels policy level setting, unless you want to analyze a specific policy level's contribution to the overall set of permissions the assembly receives.
    9. Click Next to view the list of permissions granted or list of code groups.
Show:
© 2014 Microsoft