{
	"id": "e8410d22-01ba-4de1-86af-ba4779fffb02",
	"created_at": "2026-04-06T00:10:37.393664Z",
	"updated_at": "2026-04-10T03:20:38.616635Z",
	"deleted_at": null,
	"sha1_hash": "5bf864fc22db10d849bb2e68c9b40c30e35525d8",
	"title": "Control access to software using Software Restrictions in Group Policy",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 222158,
	"plain_text": "Control access to software using Software Restrictions in Group\r\nPolicy\r\nBy Archiveddocs\r\nArchived: 2026-04-05 22:47:41 UTC\r\nSecurity\r\nApplication Lockdown with Software Restriction Policies\r\nChris Corio and Durga Prasad Sayana\r\nAt a Glance:\r\nHow software restriction policies work\r\nInventorying applications in your environment\r\nCreating and enforcing policies\r\nWhen IT professionals look to reduce the total cost of ownership, or TCO, of their desktop machines, there are\r\ntwo key strategies that often come to mind. The first one is to get your desktop\r\nusers' accounts out of the Administrators group. And the second one is to limit the applications that the users can\r\nrun. Approaching these problems can be quite a challenge in an enterprise environment, but Windows Vista®\r\noffers some technologies that can help you to achieve these goals.\r\nWindows Vista, and its User Account Control (UAC) feature, has made a giant step toward helping IT\r\nprofessionals run their enterprise users as members of the Users group (Standard Users). UAC changed the default\r\nsecurity context for all applications to be that of a User rather than an Administrator. This migration to the Users\r\ngroup is still a formidable task, but as the industry adjusts to this new paradigm, the task will get easier over time.\r\nAfter analyzing the challenges of moving users to the Users group, or sometimes during this process, many\r\nadministrators catalog what applications their users need to run and consider the steps necessary to allow only\r\nthese applications. The software restriction policy feature is designed to help IT pros do just that.\r\nYou simply specify what applications are allowed to run and then deploy the policy using Group Policy. Enforcing\r\nsuch a policy throughout an entire enterprise can reduce TCO, as this lockdown will limit issues that are related to\r\nunsupported applications. (And you can also use software restriction policies in some interesting and very extreme\r\nways, as we discuss in the sidebar \"The Bare-Bones Software Restriction Policy.\")\r\nHow Software Restriction Policy Works\r\nSoftware restriction policy aims to control exactly what code a user can execute on a Windows Vista machine.\r\nYou, the administrator, create a policy that defines what can (or cannot) be run in your environment. This policy is\r\nhttps://docs.microsoft.com/en-us/previous-versions/technet-magazine/cc510322(v=msdn.10)?redirectedfrom=MSDN\r\nPage 1 of 10\n\nthen evaluated whenever and wherever code may be executed. This includes during process creation, in a call to\r\nShellExecute, and when a script runs. (We'll look at this in more detail in a moment.)\r\nIf it is determined that an application is allowed to execute, the application will start. If, however, it is determined\r\nthat an application is not allowed to run, the app is blocked and the user is notified. For example, if you tried to\r\nrun Solitaire from the Start menu and it wasn't allowed, you'd receive a dialog similar to the one shown in Figure\r\n1.\r\nFigure 1 A dialog appears when an application is blocked (Click the image for a larger view)\r\nThe UI for defining a software restriction policy is exposed in the Group Policy Object Editor (GPOE), and this is\r\nwhere the lockdown policy is authored. There are a variety of methods for defining what code can and can't run.\r\nOnce the policy is complete and tested, you can deploy it.\r\nDefining the Software Restriction Policy\r\nThe first major decision you will make, a decision that will dramatically affect how software restriction policy will\r\nwork in your environment, is to choose a default rule type. Software restriction policies can be deployed in one of\r\ntwo modes: Allow List or Deny List. Basically, you're choosing whether you want to create a policy that describes\r\nevery application that is allowed to run in your environment or a policy that defines every application that cannot\r\nrun.\r\nIn Allow List mode, the default rule within your policy is Restricted and will block all applications that you don't\r\nexplicitly allow to run. In Deny List mode, the default rule is Unrestricted and restricts only the applications that\r\nyou have explicitly listed.\r\nDeny List mode, as you might guess, is an unrealistic approach if you are seeking a broad TCO reduction and the\r\nsecurity benefits resulting from an application lockdown. Creating and maintaining an extensive list that blocks all\r\nmalware and other problematic apps would be next to impossible; therefore, we recommend that software\r\nrestriction policy be implemented in Allow List mode, which means a default rule of Restricted.\r\nInventorying Apps in Your Environment\r\nIf you're going to design a policy that will specify what applications can run, you need to determine exactly which\r\napplications are required by your users. The software restriction policy feature offers an advanced logging feature\r\nwith a very simple policy to understand exactly what applications are running in your environment.\r\nOn a sample set of machines within your environment, deploy software restriction policy with the default rule set\r\nto Unrestricted and be sure to remove all other additional rules. The plan is to enable software restriction policy\r\nbut not allow it to restrict applications; instead, you are using it to just monitor what is being run.\r\nhttps://docs.microsoft.com/en-us/previous-versions/technet-magazine/cc510322(v=msdn.10)?redirectedfrom=MSDN\r\nPage 2 of 10\n\nNext, create the following registry value in order to enable the advanced logging feature and set the path to where\r\nthe log file should be written:\r\n\"HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows\\Safer\\\r\nCodeIdentifiers\"\r\nString Value: LogFileName, \u003cpath to a log file\u003e\r\nNow, when an application is run and the software restriction policy evaluated (it is evaluated even though it is\r\nallowing everything to run), an entry is written to the log file.\r\nEach log entry includes the caller of the software restriction policy and the process ID (PID) of the calling process,\r\nthe target being evaluated, the type of software restriction policy rule that was hit, and an identifier for the rule.\r\nHere's a sample entry written when a user double-clicks on notepad.exe:\r\nexplorer.exe (PID = 3268) identified\r\nC:\\Windows\\system32\\notepad.exe as Unrestricted using\r\npath rule, Guid =\r\n{191cd7fa-f240-4a17-8986-94d480a6c8ca}\r\nThis log file represents every piece of executable code that software restriction policy will check when it is\r\nenabled and set to block applications. That means that you must decide for each entry in the log file whether or not\r\nit should be accounted for in your Allowed List. Note that you'll see several binaries being checked that are part of\r\nWindows® and required for the system to work.\r\nThe logging technique that we describe here offers a clear way for you to understand exactly what applications the\r\nsoftware restriction policy will encounter in your environment. But it is not the only way to accomplish this task.\r\nThe Inventory Collector that is included as part of the Microsoft® Application Compatibility Toolkit 5.0 gives you\r\nthe capability to inventory the applications that are being used in your environment. This tool offers a variety of\r\ndifferent ways for you to discover what applications are installed in your environment, and it also consolidates the\r\nresults into a central database.\r\nAuthoring Additional Rules\r\nNow that you have a list of applications that must be allowed to run in your environment, you are ready to create\r\nthe actual rules that will permit these applications to run. The software restriction policy feature uses two ways to\r\nidentify policy—one is based on the cryptographic properties of an application (such as its hash), and the other\r\ndefines a Trusted Path or folder in which trusted applications should reside.\r\nFigure 2 shows where you would add rules to allow the applications to run in the Software Restriction Policies\r\nnode of the GPOE (gpedit.msc). The most straightforward way to define applications in your environment is to\r\ncreate a hash rule for every single binary you encountered during the logging phase.\r\nhttps://docs.microsoft.com/en-us/previous-versions/technet-magazine/cc510322(v=msdn.10)?redirectedfrom=MSDN\r\nPage 3 of 10\n\nFigure 2 Using gpedit.msc to author software restriction policies (Click the image for a larger view)\r\nSince the hash is a unique value that is returned for a particular set of bits, each binary in your policy is going to\r\nhave a different hash. This approach is particularly secure and will only allow the specific binaries in your policy\r\nto run.\r\nOf course, there are some drawbacks to this approach. For instance, your environment could easily have several\r\nthousand binaries. It could be difficult to author all of these rules in the software restriction policy UI, and as the\r\nnumber of rules gets particularly large, performance can be affected. In addition, each application update in your\r\nenvironment will require one or more new hash rules to be deployed in the environment. Updating such a large\r\npolicy as applications are updated can be a huge burden.\r\nFortunately, this burden can be avoided because there are two other ways to identify rules that make it easier to\r\nuse software restriction policies in your environment. Venturing further down the cryptographic security route,\r\nyou can create a rule that will allow any binary that is signed by a particular certificate to run.\r\nDoing this helps to simplify the maintenance of the policy list since, when an application is updated, the new\r\nbinaries will generally be signed by the same certificate as the previous ones. However, if you don't want a\r\nprevious version of the binary to run in your environment, you'll need to add a Restricted hash rule in order to\r\nprevent the file from being allowed.\r\nBy default, the evaluation of certificate rules is disabled for software restriction policies. There are two reasons\r\nbehind why this had to be done.\r\nFirst, the certificate rules in the software restriction policies are defined by what is in the system's Trusted\r\nPublishers store. Because the Trusted Publishers store is used for purposes other than just software restriction\r\npolicy rules, this requires additional time and consideration when it is used for the software restriction policies\r\nfeature.\r\nhttps://docs.microsoft.com/en-us/previous-versions/technet-magazine/cc510322(v=msdn.10)?redirectedfrom=MSDN\r\nPage 4 of 10\n\nThe second reason is that in order to determine whether a file's signature is valid, you must take a hash of the file\r\nand compare it to the signature information. Hashing a file is a very expensive operation—the entire file must be\r\nread off of the disk and processed to calculate this hash.\r\nIn order to enable certificate rules, navigate to the Software Restriction Policies node and select Enforcement\r\nObject in the results pane. Then double-click to open its properties dialog and select the enforce certificate rules\r\nradio option.\r\nThe other common way to identify code is to use the path of the code on the local machine. This is an effective\r\nand efficient technique, but it has one drawback—you must be careful to ensure that the security settings are set\r\nproperly on the folder.\r\nIf you add a particular path rule, and this path allows users to write files there (to the desktop, for example), they\r\nwould be able execute anything they want just by putting the executable in that folder. However, if your users are\r\nnot in the Administrators group, they generally don't have the ability to modify anything in the Program Files or\r\nWindows directories. This means that if all your applications are in the Program Files directory and your users\r\naren't Administrators, then you should look to path rules for having a very simple and efficient policy.\r\nPath rules offer some other features that make it more appropriate for some environments. It allows for wildcards\r\nand lets you use environment variables to make it easier to define rules that are portable in your environment—\r\nafter all, %systemdrive% might not be c:\\ for every user.\r\nAs for performance and maintenance, this is probably the most hassle-free way to identify code. Path rules are\r\ncertainly something to consider, but you need to be aware of the additional security considerations.\r\nNetwork Zone Rules\r\nSoftware restriction policy does include a rule type called Network Zone rules, although this type of rule is being\r\ndeprecated. The original intention of these rules was based on the idea that the source of particular executable\r\ncode could be identified and trusted, and thus the code would be allowed to run. Unfortunately, this is particularly\r\ndifficult to do and, as a result, never worked particularly well. Currently, this type of rule is not enforced in the\r\nmajority of places on the software restriction policy entry points.\r\nIn cases where most applications are installed to the %Program Files% directory but there are other executable\r\nfiles that are installed elsewhere and signed by a specific certificate, it may make sense to use rules of different\r\ntypes. A few hash rules, a couple of path rules, and you'll find you've got the right policy for yourself.\r\nJust keep in mind that there is an order in which the rules are processed (as shown in Figure 3). Certificate rules\r\nare the most specific, hash rules are next, then path rules, and then path rules with wildcards in them. So, if a piece\r\ncode is identified by a hash rule and a path rule, the security level of the hash rule will take priority.\r\nhttps://docs.microsoft.com/en-us/previous-versions/technet-magazine/cc510322(v=msdn.10)?redirectedfrom=MSDN\r\nPage 5 of 10\n\nFigure 3 Rule\r\n processing order (Click the image for a larger view)\r\nPolicy Enforcement\r\nThe software restriction policies feature provides a breadth of coverage on the system being secured. The idea is\r\nthat any location from which code can be executed should be integrated with the software restriction policy and, in\r\nhttps://docs.microsoft.com/en-us/previous-versions/technet-magazine/cc510322(v=msdn.10)?redirectedfrom=MSDN\r\nPage 6 of 10\n\nturn, check the policy to see if the executable code is allowed to run.\r\nWhile there are numerous places that check the software restriction policy, the most straightforward entry point is\r\nCreateProcess. During CreateProcess, the policy is checked to determine whether or not the binary that represents\r\nthe application is permitted to execute. The policy check is done by the SaferIdentifyLevel API, which is publicly\r\ndocumented. The general process is illustrated in Figure 4. (We'll discuss SaferIdentifyLevel in more detail in a\r\nmoment.)\r\nFigure 4 Using SaferIdentifyLevel to determine whether a binary can be executed (Click the image for a\r\nlarger view)\r\nAfter CreateProcess, the next most commonly used API where software restriction policy is enforced is\r\nShellExecute. This is the API that is called when the user clicks on an application in the Start menu or double-clicks something on the desktop.\r\nShellExecute can be called on a wide variety of file formats. In cases such as a .txt file, calling ShellExecute on\r\nthe file doesn't actually result in the file being executed—technically, of course, the file is opened. For this reason,\r\nsoftware restriction policy contains a list of executable file types so that it can control what types of files are\r\nchecked when ShellExecute is called. You can customize this list of executable file types in the software\r\nrestriction policy UI.\r\nBeyond CreateProcess and ShellExecute, there are two other key integration points: LoadLibrary and script hosts.\r\nLoadLibrary is obviously an important place to check executable code, but unfortunately LoadLibrary presents\r\nhttps://docs.microsoft.com/en-us/previous-versions/technet-magazine/cc510322(v=msdn.10)?redirectedfrom=MSDN\r\nPage 7 of 10\n\nsome special constraints.\r\nMost applications have one executable and several DLLs that are loaded. And there are typically lots of\r\napplications running on the system. This means that LoadLibrary would require a lot of checking of the policy.\r\nDepending on your policy for identifying code, this could be a very expensive entry point to enforce—imagine\r\nchecking the hash of every DLL loaded on the system, which includes hashing the binary and then comparing it to\r\na list of perhaps thousands of hashes.\r\nThis functionality is disabled by default, but it can be enabled manually. To do this, navigate to the Software\r\nRestriction Policies node in gpedit.msc and double-click on Enforcement. After that, select the All software files\r\nradio button.\r\nAs we mentioned, software restriction policy is integrated with most script hosts in the system. This includes cmd,\r\nVBScript, Cscript, and JScript®. These entry points, as well as the others, use the primary software restriction\r\npolicy enforcement API: SaferIdentifyLevel.\r\nThe SaferIdentifyLevel API determines whether a specified executable should be allowed to run by looking up the\r\nidentification information in the relevant software restriction policies. This is a publicly documented API. Third-party script hosts and executable environments can and should use it\r\n in order to integrate with software restriction\r\npolicy so the policy can determine whether a piece of executable code should be allowed to run.\r\nRunning as a Standard User\r\nA not-so-well-known feature of the software restriction policy is its ability to filter the privileges of certain\r\napplications when they're launched. This functionality was introduced in Windows XP, but it wasn't exposed in the\r\nsoftware restriction policy UI until Windows Vista.\r\nIn this way, it was a precursor to Windows Vista UAC because you could use it to run an application as a Standard\r\nUser even when the user was a member of the Administrators group. This is what happens when you create a rule\r\nand set the Security Level to Normal User in the Additional Rules UI.\r\nBoth UAC's token filtering functionality and software restriction policies' Normal User rules take advantage of an\r\nunderlying API that implements the same behavior as the CreateRestrictedToken API. However, the overall\r\narchitectural differences in the technologies are very significant. But UAC differs from software restriction policy\r\nin a couple of key ways.\r\nFirst, in Windows Vista with UAC enabled, every application is started with a security token similar to a member\r\nof the Users group by default, even when the user is an Administrator. This is achievable with software restriction\r\npolicy, but there is no means to start an application with the user's actual Administrator token—for instance, when\r\nthe user needs to install an application. The change in default security context and ease of access to a user's full\r\nadministrator token are key benefits of UAC.\r\nThe second difference is that, in the case of executables, the code itself expresses what privilege level is required\r\nin order for it to function. This is a key distinction because independent software vendors (ISVs) and developers\r\nunderstand the needs of their code. For example, if a control panel application needs to edit something that\r\nrequires administrator privilege, it can specify that requirement in its manifest. Thus the ISV can describe the\r\nhttps://docs.microsoft.com/en-us/previous-versions/technet-magazine/cc510322(v=msdn.10)?redirectedfrom=MSDN\r\nPage 8 of 10\n\nprivileges needed by an application rather than imposing a certain privilege level upon it without any means\r\navailable to change this level.\r\nFor now, you should avoid using the Normal User rules unless you really understand how they work. UAC is an\r\nexcellent way to help get your desktop users out of the Administrators group, and you should seriously consider\r\nsimply leaving UAC in your enterprise environment.\r\nSoftware Restriction Policies in Use Today\r\nThere are a number of moving parts that you need to account for when you use software restriction policy. But it's\r\nnot as you might think, and, in fact, you may even be using software restriction policies today without realizing it.\r\nIf, for instance, you run Parental Controls on a Windows Vista system, you are using software restriction policies\r\nto control the execution of applications.\r\nSoftware restriction policy was an important technological development when it was first introduced in Windows\r\nXP. But application lockdown is really just now starting to get the attention of IT professionals.\r\nThe software restriction policy feature in Windows Vista has some rough edges that still need to be polished, but it\r\nis clear that administrators want to have this increased control over what is running in their environments.\r\nFortunately for all of us, this technology will continue to evolve and make it easier for IT pros to manage their\r\nsystems and lower the cost of running a Microsoft Windows environment.\r\nThe Bare-Bones Software Restriction Policy\r\nOne application of software restriction policy is to create a policy that locks down Windows into a kiosk mode.\r\nMicrosoft actually produces a tool kit, called SteadyState™, for creating this kiosk. However, if you are only\r\ninterested in locking down the applications that can run, this can be achieved more simply.\r\nTo allow the minimum set of applications required to log on to Windows Vista, create a policy that allows\r\nlogonui.exe and userinit.exe to run from %windir%\\system32. Most users will probably also need the following\r\napplications allowed to run:\r\ndllhost.exe, rundll32.exe, control.exe (also under %windir%\\system32)....\r\nIf you want the default Windows shell, you would also want to add %windir%\\explorer.exe.\r\nAlternatively, you could choose to boot directly into an application, such as Internet Explorer®. In that case, it\r\nwould be necessary for you to list iexplore.exe instead of explorer.exe.\r\nAnother aspect of this bare-bones policy is that your users should not be in the Administrators group. This is\r\nimportant so that they cannot bypass the policy. However, because they can only run a very basic set of\r\napplications and do not have the privileges of an Administrator, the users will not have the privileges to install\r\napplications or maintain the system.\r\nYou will need to have some way to do that for these machines. If you intend to update and maintain these\r\nmachines by logging on locally with an Administrator account, you should select the radio button that applies\r\nhttps://docs.microsoft.com/en-us/previous-versions/technet-magazine/cc510322(v=msdn.10)?redirectedfrom=MSDN\r\nPage 9 of 10\n\nsoftware restriction policy to all users except local administrators. The policy should also include consent.exe and\r\ncmd.exe. This will allow the Administrator to launch any administration option from an Administrator cmd\r\nprompt.\r\nNote that UAC limits the privileges of the user's security token by default to make it look like the token isn't a\r\nmember of the Administrators group. Even if you set the setting above to not apply the policy to Administrators, it\r\nwill still be applied to the users. It is only when you go through the UAC elevation experience that the\r\nAdministrator actually gets the full administrator privileges and the software restriction policy will then not be\r\napplied.\r\nChris CorioChris Corio was a member of the Windows Security team at Microsoft for more than five years. His\r\nprimary focus at Microsoft was application security technologies and management technologies for securing\r\nWindows. You can reach Chris at winsecurity@chriscorio.com.\r\nDurga Prasad SayanaDurga Prasad Sayana is a Software Design Engineer/Test on the Windows Core Security\r\nteam. His primary interests are security technologies and software testing. You can reach Durga at\r\ndurgas@microsoft.com.\r\n© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole\r\nwithout permission is prohibited.\r\nSource: https://docs.microsoft.com/en-us/previous-versions/technet-magazine/cc510322(v=msdn.10)?redirectedfrom=MSDN\r\nhttps://docs.microsoft.com/en-us/previous-versions/technet-magazine/cc510322(v=msdn.10)?redirectedfrom=MSDN\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://docs.microsoft.com/en-us/previous-versions/technet-magazine/cc510322(v=msdn.10)?redirectedfrom=MSDN"
	],
	"report_names": [
		"cc510322(v=msdn.10)?redirectedfrom=MSDN"
	],
	"threat_actors": [],
	"ts_created_at": 1775434237,
	"ts_updated_at": 1775791238,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/5bf864fc22db10d849bb2e68c9b40c30e35525d8.pdf",
		"text": "https://archive.orkl.eu/5bf864fc22db10d849bb2e68c9b40c30e35525d8.txt",
		"img": "https://archive.orkl.eu/5bf864fc22db10d849bb2e68c9b40c30e35525d8.jpg"
	}
}