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Â
(http://kbalertz.com/Feedback.aspx?kbNumber=815164/EN-US/
)
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.
.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.
Collapse this tableExpand this table
| 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. |
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.
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.
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.
For additional information, click the following article
numbers to view the articles in the Microsoft Knowledge Base:
315736Â
(http://kbalertz.com/Feedback.aspx?kbNumber=315736/EN-US/
)
HOW TO: Secure an ASP.NET Application by Using Windows Security
315588Â
(http://kbalertz.com/Feedback.aspx?kbNumber=315588/EN-US/
)
HOW TO: Secure an ASP.NET Application Using Client-Side Certificates
818013Â
(http://kbalertz.com/Feedback.aspx?kbNumber=818013/EN-US/
)
HOW TO: Support Applications That Are Built on the .NET Framework