The Locations of the Other Policy Levels

  • Article

On Monday I wrote about how to recover CasPol to a usable state, if you've modified the security policy to disallow CasPol permission to run.  My instructions included deleting %WINDIR%\Microsoft.Net\Framework\vx.y.zzzz\config\Security.config and Security.cch.  I've gotten a few emails that correctly pointed out that this only clears the Machine policy level.  Since this is the level where most modifications occur, this is usually sufficient to clear up the CasPol problem.

For the sake of completeness I'll show where the other policy levels are stored.  This might be useful if you've modified another level to prevent CasPol from running, or if you'd like a backup of your security settings.

  • Enterprise Level: %WINDIR%\Microsoft.Net\Framework\vx.y.zzzz\config\EnterpriseSec.config (and .cch)
  • Machine Level: %WINDIR%\Microsoft.Net\Framework\vx.y.zzzz\config\Security.config (and .cch)
  • User Level: %APPDATA%\Microsoft\CLR Security Config\vx.y.zzzz.ww\Security.config (and .cch)

The AppDomain level is not persisted to disk, for obvious reasons.  The vx.y.zzzz are version strings.  Currently they are:

  • CLR v1.0 : v1.0.3705
  • CLR v1.1: v1.1.4322
  • CLR v2.0 Beta 1: v2.0.40706 (.16 for the user level)
  • CLR v2.0: v2.0.50727 (.42 for the user level)

You may or may not have these files, depending upon if you have any policy on each specific level.  The policy stored in the .config files is in standard XML format.  Obviously performance would suffer if the CLR had to parse three XML files in order to determine the security settings, so that's where the .cch files come into play.  Any file that has .cch in its extension (sometimes there will be numbers after the .cch as well), are essentially compiled versions of the security configuration for a specific policy level.

Updated 2/8/2006: Added the v2.0 final policy location