Knowledge Base

HOW TO: Troubleshoot Problems That Are Caused by the .NET Framework Security Configuration

Article ID: 815163

Article Last Modified on 4/30/2003

APPLIES TO

Microsoft .NET Framework 1.0
Microsoft .NET Framework 1.1

IN THIS TASK

SUMMARY
REFERENCES

SUMMARY

This step-by-step article describes how to temporarily reset the .NET Framework Security policy configuration, and then restore the policy configuration after you finish troubleshooting.

One of the most common sources of problems when you use applications in secure environments is permissions that are too restrictive. Frequently, an application does not function correctly because security policy prevents the application from gaining access to necessary resources. The more restrictive and secure the environment is, the more likely these problems are to occur.

You can start to troubleshoot security problems that occur when you use managed assemblies or .NET-connected applications by eliminating the trust level as the source of the problem. For additional information about troubleshooting trust levels, click the following article number to view the article in the Microsoft Knowledge Base:

815164 HOW TO: Troubleshoot Problems That Are Related to Trust Levels

After you identify that the problem is not the result of trust levels that are too restrictive, it may be useful to reset security policy settings to their default configuration. This procedure can rule out as a cause any configuration attributes that are specific to the enterprise system or to the local computer.

back to the top

.NET Framework Security Policy Files

The following table lists critical .NET Framework configuration files and their locations. The specific files that affect an application may vary.

File Location	Description
\`System Root`\Microsoft .NET\Framework\`Version Number`\CONFIG\Machine.config	Defines .NET Framework configuration information for the local system.
\`System Root`\Microsoft .NET\Framework\`Version Number`\CONFIG\Enterprisesec.config	Enterprise security policy configuration file, as applied to the local system.
\`System Root`\Microsoft .NET\Framework\`Version Number`\CONFIG\Security.config	Local computer security policy configuration file.
\`User Profile`\ Application Data\Microsoft\CLR Security Config\`Version Number`\Security.config	User security policy configuration file on Microsoft Windows NT, Windows 2000, Windows XP, and Windows Server 2003. Roaming profiles are located on a network server.
\`System Root`\`User Name`\CLR security config\`Version Number`\Security.config	User security policy configuration file for Microsoft Windows 98 and Windows Millennium Edition.

back to the top

Create a Backup of a .NET Framework Security Policy

The .NET Framework security policy is stored in XML files that have .config extensions. To create a backup of the current security policy file, copy it to the same folder. Give the copy a new name (for example, use a .config.backup file name extension). To do this by using Windows Explorer, select the file, press CTRL+C, press ESC (to clear the selection), and then press CTRL+V to create a copy of the file in the same folder.

back to the top

Restore Original .NET Framework Security Policies

Method A

Install the .NET Framework redistributable package on a clean computer that is not affected by group policies.
Locate the security policy configuration file on the clean computer, and then copy this file over the active security policy file. (The active security file is the file that you copied in the "Create a Backup of a .NET Framework Security Policy" section.) The .NET Framework detects the change and immediately applies the new security policy.

Method B

Alternatively, you can use automatically created backup files in the same folder. These files have a file name extension of either .default or .old. These files may not be the original files that are included with the .NET Framework redistributable package. After you restore the original security configuration, it is a good idea to test the application to determine whether the problem has been resolved.

After the problem is resolved, compare the original security configuration files to the customized files that you created backup copies of.
Identify the specific configuration elements that are the source of the problem.
One at a time, copy the customized configuration elements to the current security configuration files, and then test the application.

The configuration element that causes the application to stop responding is the source of the problem. You must adjust this element after you revert to the customized security policies.

If the problem is not resolved, you may conclude that the cause was not the customized security configuration. However, the problem may be related to the security configuration if the application requires configuration changes to the default settings. For more information, see the application documentation.

back to the top

Revert to Customized Security Policies

When you troubleshoot this problem (after you identify whether security configuration is a factor and you identify the specific configuration elements that may be involved), it is a good idea to restore the customized security policy. To do this, copy the backup file that you created over the restored security policy.

If you have determined that one or more configuration elements are causing the problems that occur when you run the application, adjust these configuration elements. If possible, perform application-specific configuration adjustments on the application's configuration file (located in the application’s folder). The .NET Framework detects the change and immediately applies the new security configuration.

back to the top

REFERENCES

For additional information, click the following article numbers to view the articles in the Microsoft Knowledge Base:

315736 HOW TO: Secure an ASP.NET Application by Using Windows Security

315588 HOW TO: Secure an ASP.NET Application Using Client-Side Certificates

818013 HOW TO: Support Applications That Are Built on the .NET Framework