Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
Windows Vista

Supporting Desktop Applications : Troubleshoot Software Restrictions

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
3/19/2011 4:27:27 PM
Software restrictions are another way to ensure desktop security. Applications that are not to be used within an enterprise have found their way in one way or another over the years. Let’s face it, an organization will always have someone who feels compelled to run an application he knows to be forbidden, use a utility that was not supplied to him by the company, or just decide to try this new application that is advertised in an email. The increased number of ways of collaborating in the creation of documents also increases the ways malware can be introduced into a network environment. Hostile code is finding its way into the protected portion of networks. With bad guys finding more insidious ways to inject their poisons into an enterprise, company policies concerning application use sometimes take a hit.

Reviewing Software Restriction Policies

Before you get into using Software Restriction policies, take some to time to review the four available policies. You need to be clear about their capabilities and what they do so that later when you discuss their use either alone or in conjunction with another type of Software Restriction policy, you have a better handle on what results you can expect. Software Restriction policies are put in place to protect against malicious code as well as unknown code. This section starts by listing the four software rules that identify software and then identifies the three security levels in which they are enforced.

The four rules that identify software are

  • Certificate— A certificate from a software publisher that is digitally signed.

  • Hash— A cryptographic fingerprint that uniquely identifies a file.

  • Path— Use of local path or universal naming convention (UNC) path to the place where a file is stored. A path rule can be a file path, Registry path, or path that employs wildcards.

  • Network Zone— Defined network locations such as Internet, Local Intranet, Restricted Sites, Trusted Sites, and Local Computer.

Security levels are employed to dictate a default rule for all software, along with exceptions for software that should not run, may always be run, or run using a normal user security level. These three security levels are

  • Unrestricted— This is the default security level for all Software Restriction policies. This rule should be used if, as administrator, you are aware of all software that should be run. You can set the default policy to Disallowed and create an unrestricted rule for all known software that can be run.

  • Disallowed— This rule should be used if, as administrator, you are aware of all software that should not be run. You can set the default policy to Unrestricted and create a disallowed rule for all known software that should not be run.

  • Basic User— As administrator, you should employ this rule where software is known to run with only normal user security. For example, you can set the default policy to Disallowed and configure a policy for all other software that can be run under normal user security.

Employing Software Restriction Policies

Using the rules individually or in combination with other rules is where the complexity begins. Rules need to be applied based on a processing priority along with the knowledge that any software this is going to be allowed to run will take into consideration any user security set at the folder and file level. Rules that identify software are evaluated such that the more specific rule takes precedence. So the processing of rules in order of precedence is

  1. Certificate rule

  2. Hash rule

  3. Path rule

  4. Internet zone rule (or Network rules)

  5. Default rule

Following are some implementation examples. For instance, if the default rule Unrestricted is in use, but you know that most scripts should never be run except for a few in a select folder, you could employ the following rules to meet these goals.

  1. Default rule of Unrestricted

  2. Path rule that disallows all *.vbs scripts

  3. Path rule that creates an exception for scripts in the C:\scripts\ folder that overrides rule 2 because it is more specific for .vbs files in the C:\scripts\ folder

Or you could possibly use

  1. Certificate rule using a signed publisher’s certificate for specific scripts that are allowed to run

If a company wants to restrict users from running multimedia applications such as Real Player or Windows Media Center, it can create an exception to the default rule Unrestricted. An exception rule can use either a path rule specifying the exact path or a hash rule specifying the exact executable that runs the multimedia applications. The exception rules are seen as more specific and thus override the default Software Restriction of Unrestricted.

Now use the initial scenario as a guideline. What if the company wants to ensure that script files run from a designated \scripts folder are authorized to be run? The company can employ multiple Software Restriction rules to ensure this goal:

  1. One rule could be a path rule used to disallow all script files or maybe just the script files in the \scripts folder.

  2. A second rule would be a more specific certificate rule that signs all allowed scripts, and this rule is set to Unrestricted. This means that any script within this same folder that contains a software publisher’s certificate is allowed to run, and all others are denied by the first rule.

Monitoring Software Restriction Policies

With so many variables possible with Software Restriction policies, you need a tool or two to help troubleshoot problems arising when multiple Software Restriction policies are employed in an environment. Using the Resultant Set of Policy (RSoP) standalone snap-in or the newer Group Policy Management Console (GPMC) that has integrated much of the RSoP snap-in functionality, you can ascertain the effective Group Policy settings on users and computers. Figure 1 shows one of the two ways RSoP (Group Policy Results in the GPMC) is employed within the Group Policy Management Console.

Figure 1. Using RSoP within the GPMC.

The Group Policy Results summary report shown in Figure 1 is based on actual Group Policy applied to the user named Paul using the computer VISTA-PCMOBILE.

The Group Policy Modeling node displays RSoP data based on “what if” scenarios. In other words, what if a user from a specific container (Organizational Unit or domain) is using a computer from another container with the respective policies applied? The report generated is to simulate the effects of given policies applied to specific containers of users and computers.

Using the GPMC and Managing Group Policy for Windows Vista

The newer GPMC that is now integrated into the base operating system of Windows Vista and Windows Server 2008 can also manage all Group Policy settings on Windows 2000, Windows XP, and Windows Server 2003. There are known limitations in using the RSoP snap-in for modeling and logging Group Policy results because there are known limitations with using Group Policy Results and Group Policy Modeling from Windows Vista and Windows Server 2008 computers. Due to these complexities, in addition to the 800+ additional Group Policy settings available to Windows Vista and Windows Server 2008, and the use of a new file format for defining Registry-based policy settings, it is strongly suggested that all Group Policies be managed from a Windows Vista or Windows Server 2008 computer in a mixed domain environment. For additional suggested best practices on deploying Group Policies with Windows Vista desktops, see the article at http://technet2.microsoft.com/WindowsVista/en/library/5ae8da2a-878e-48db-a3c1-4be6ac7cf7631033.mspx?mfr=true.

Using these two powerful reports, you can detect problems or conflicts with Group Policy settings. This includes issues arising from conflicting Software Restriction polices. Another possible utility that allows the viewing of RSoP data is the gpresult command-line utility. This utility allows you to view all Group Policy objects and their effects.

There are some common problems to look out for when implementing Software Restriction policies. The following list should not be considered complete but can be used as a guideline for additional items to be aware of when creating Software Restriction rules:

  • Know the location of all login scripts to ensure their use.

  • Windows Vista system file protection makes duplicate copies of most system applications and stores them in the folder %WINDIR%\system32\dllcache. Create a rule to disallow execution of applications from this directory.

  • Note startup locations for applications on a computer. For example, the Startup folder for each user in her profile is one of many different areas to look out for applications that run at startup. Other locations consist of the Run key in the Registry for the current user as well as the All Users, Scripts, and Startup folder for the All Users profile.

  • Do not disallow antivirus, antispyware, or antimalware applications from running, including those that look for real-time exploits.

  • Watch out for malicious .vbs scripts. Over the years, this has been the most prolific means of introducing malware.

  • Allow only authorized application installations. Disallow any other unauthorized applications from installing on user and server computers.

  • If different users are using a computer, ensure that Software Restriction policies are applied on a per-user basis if there are differences in what each user is allowed to run.


To fix an errant Software Restriction policy applied through Group Policy, log in as the default administrator in Safe Mode. The Software Restriction policy is not enforced in Safe Mode, and the local administrator has the power to remove the errant policy using gpedit.msc or secpol.msc console snap-ins. Force the policy to be removed by running gpupdate.exe while in Safe Mode.

Other -----------------
- Support Deployed Applications
- Configure Network Security (part 2 ) - Windows Firewall
- Configure Network Security (part1 ) - Secure Files and Printer Shares with Access Control Lists (ACLs)
- Configure and Troubleshoot Remote Access (part 2) - Troubleshooting Windows Vista Remote Access Connections
- Configure and Troubleshoot Remote Access (part 1) - Remote Client Access Connections
- Configure and Troubleshoot Wireless Networking (part 3) - Troubleshooting Wireless Connections
- Configure and Troubleshoot Wireless Networking (part 2) - Wireless Security
- Configure and Troubleshoot Wireless Networking (part 1) - Managing Wireless Connectivity in the Enterprise
- Troubleshoot Resource Access and Connectivity Issues (part 2)
- Troubleshoot Resource Access and Connectivity Issues (part 1) - Troubleshooting TCP/IP Configuration
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
Windows Vista
Windows 7
Windows Azure
Windows Server