The goal is to prevent users from running unwanted programs on a terminal server.

I have read many articles from Microsoft and others saying that the new Applocker feature is 100% better than the old Software Restriction Policy and is recommended as a replacement of latter.

I am not sure to understand the real advantages of Applocker apart from the kernel mode execution. The most of its functionnalities can be reproduced with Software Restriction Policy.

At the same it has one BIG disadvantage that make it pretty useless: it is not extensible, and you cannot add custom file extensions that you want to restrict.

What are advantages of Applocker over SRP and what would you recommend for software control?

  • File Extension restrictions are somewhat useless as there are quite a few ways around it. It might keep out people who don't know what they're doing, but if you think it's going to stop virii or corporate espionage, you're barking up the wrong tree. Did you see any other disadvantages??
    – Chris S
    Nov 9, 2012 at 13:59
  • Have a look here: technet.microsoft.com/library/hh994614
    – joeqwerty
    Nov 9, 2012 at 18:09

5 Answers 5


Software Restriction Policy is deprecated by Microsoft (technet effectively claiming SRP is not supported), since Windows 7 Enterprise/Ultimate introduced AppLocker.

In practice SRP has certain pitfalls, for both false negatives and false positives. AppLocker has the advantage that it's still being actively maintained and supported. If AppLocker is an option then it could be the cheaper one - after accounting for your time and risks taken. It's also possible there's a suitable third-party alternative (but this question didn't include that option :).

Hopefully you'd gain perfect understanding of SRP's pitfalls before you fall into any of them </sarcasm>. Some of them are described in a nice security article from Vadims Podāns.

Known pitfalls

  1. In the default rules, execution from the \Windows folder is permitted. Some sub-folders can be written to by users. Applocker is the same, but at least official documentation mentions this limitation.

"To enumerate all folders with users write access you can use, for example, AccessEnum utility from Sysinternals pack." (or AccessChk).

An NSA document gives 16 examples of folders to blacklist with SRP (although the registry path rules use backslashes incorrectly so must be corrected - see point on registry paths below) and warns about a common over-broad blacklist entry.

The obvious question is why aren't we carefully whitelisting individual paths under \Windows instead. (Including the \Windows\*.exe legacy, System32\*.exe, etc). I didn't notice any answers to this anywhere :(.

  1. Using environment variables like %systemroot%, SRP can be bypassed by users by clearing the environment variable. These are not used in the suggested defaults. However they may be tempting to use. This footgun is fixed in AppLocker, because it never looks at environment variables.
  2. The suggested defaults neglect to allow for the two different \Program Files used on modern 64-bit installs. When resolving this using the more secure "registry paths", there are reports of false denials in random situations, which could easily be missed in testing. e.g. see comments on SpiceWorks SRP howto. This is to do with 32-bit applications reading relevant paths from the WOW6432Node of the registry: resolution is to add both these paths to SRP to allow all programs to work on 32-bit and 64-bit machines as Unrestricted whether started from an x64 or x86 host process: %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)% %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%
  3. The default extensions neglect to forbid PowerShell scripts (*.PS1) supported by Windows. (See video). And APPX too. Also according to Microsoft's comparison table, SRP can't manage "Packaged apps" in Windows 8; I have no idea what this means.
  4. Registry path rules must not have slashes immediately after the last percent sign (despite being included in Microsoft's own built-in rules for XP/Server 2003) and any backslashes must be replaced with forwardslashes in order for the rule to work (1/2/3).
  5. Of the sources I found for SRP, none put the full list above together for you. And I only discovered Vadims Podāns' article by accident. What else is lurking out there?
  6. Many sources recommend simply removing LNK files from the list. (And Web Shortcuts to avoid breaking Favourites?!). Disturbingly, no sources seem to discuss LNK vulnerabilities... or getting script interpreters to run files with an unexpected extension e.g. wscript /e... or maybe stuffing enough shellcode in an inline script parameter... etc.
  7. If you try to compromise by allowing LNK files on the desktop, and you leave users with write access to the desktop, they can now bypass your policy entirely. Lovely tip from Vadims Podāns again. Note that the explanation applies to using any extension in a path rule. Microsoft present multiple examples of this including *.Extension, with no warning. So you can't trust the official documentation, and it seems unlikely to get fixed now.
  8. [Potential AppLocker disadvantage]. Vadims Podāns reports that SRP entries using mapped drives do not work. The UNC path must be used instead. Maybe they would then apply to access through a mapped drive? it's not 100% clear. Apparently AppLocker was different: it didn't work with either :(. "Due to unknown reason, UNC paths doesn’t work in Applocker! This means that if your application is installed in network, you have to create either hash or publisher rules."

Pragmatic approach

Software whitelisting is potentially a very powerful defense. If we get cynical: this is exactly why Microsoft deprecates the lower-priced versions and invents more complex ones.

Maybe no other option is available (include 3rd-party solutions). Then a pragmatic approach would be to try configuring SRP as simply as possible. Treat it as an extra layer of defense, with known holes. Matching the pitfalls above:

  1. Start from the default rules (from the pre-Win7 era :).
  2. Prefer to not use environment variables, e.g. %systemroot%.
  3. Add rules to make sure both \Program Files\ directories are permitted on modern 64-bit machines. The extra "registry paths" you will need to add for \Program Files\ on 64-bit computers are %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)% and %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%.
  4. When adding to registry path rules, leave out any backslash immediately after the percent sign, and replace any further backslashes \ with forwardslashes / (e.g. %HKEY_LOCAL_MACHINE\Software\CompanyName\CustomApps%App/Bin/start.exe)
  5. Add PS1 to the list of controlled extensions.
  6. Understand that a manageable SRP configuration is not secure against a user determined to defeat it. The aim is to help/encourage users to work within the policy, to protect them against attacks like "drive-by downloads".
  7. Allow LNK files. (Preferably by removing it from the extensions list, not through some path rule).
  8. See point 7 :).
  9. Make sure your logon script folder is permitted. The NSA document suggests adding \\%USERDNSDOMAIN%\Sysvol\. (See point #2, sigh, then see point #6).

I agree that SRP has some additional features that AppLocker could really benefit from.

That being said, I see the big benefits of AppLocker (as documented by this comparison) as:

  • AppLocker rules can be targeted to a specific user or a group of users, whereas SRP is enforced on the whole computer.
  • AppLocker supports audit mode so that rules can be tested in production before being enforced. SRP doesn't have an equivalent log-only mode.

I use Applocker within my company. The strategy we use is: Deny everything as a baseline (in fact: the Applocker defaults), and then do what was suggested: make a rule that allows for only signed applications (office, adobe, wintools, ax etc.). Most, maybe all malware is not-signed software so won't execute. It is hardly any maintenance. I only had to allow for 3 extra legacy apps.

Further I cannot confirm one cannot use UNC-paths. In some extra safety deny-rules I use UNC-path's succesfully. The pitfall is in using environmentvariables: they don't work for Applocker. Use * wildcards. I use it on Windows 2008 R2 and Windows 2012 R2.

I like it a lot: there's hardly any performance-downfall. As the documentation says: Applocker relys on the Application Identity Service (make sure it starts automatically).


The biggest advantage for me is the ability to whitelist signed executables by publisher. Have a look at this http://technet.microsoft.com/en-us/library/ee460943(v=ws.10).aspx

  • 1
    A bit more detail would make this a better answer going forward. A link can change and make the answer less useful. Asdding some detail from the linked material would help
    – Dave M
    Feb 19, 2013 at 18:51

There are no benefits of AppLocker, Microsoft published blatant lies: 1. GPOs with SAFER rules can be attached to users and user groups; 2. Windows Vista introduced multiple local GPOs which achieve the same result without a domain controller; 3. audit mode is available via the extended logging feature with NO enforcement.

  • 1
    Would you be able to provide these GPOs, to help other people implement it?
    – womble
    Apr 23, 2017 at 22:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .