Archive for July, 2009

HTML Application – Retrieve SP_WHO2 and the Input Buffer from a SQL Server

You can find the full post here:


, , ,

No Comments

Decrease Malware Infections Using Software Restriction Policies (SRP) to Strip Administrative Privileges from Internet-Facing Applications

This information applies to Windows XP only.  It is NOT valid for Windows Vista or Windows 7


I know that many organizations do not put restrictions on their users’ computers.  The users are often given full administrative privileges on their workstations, which means that they can not only mess around with all the settings on their computers, but they can also install and uninstall applications.  This includes accidental virus and malware installations.  While many Systems and Network Admins consider this unacceptable, it’s still a reality in many working environments.  So rather than complain about how it’s not the ideal way to run a windows network, let’s focus on cool ways to mitigate the risks of this approach.  This is one VERY simple but effective method to limit malware infections on your network computers while still allowing users to be local administrators.  This approach can be used across an entire network with a group policy object, or it can simply be applied to a single computer by modifying the computer’s local security policy.


The idea here is that you apply a group policy object to the users or computers in your organization.   It prevents whatever applications you choose from launching with full admin privileges on the users’ computers.  The users are still local administrators, but the particular applications that you pre-select get launched without administrative permissions.  If you apply this restriction to all of the applications that deal with typically untrusted, unsafe, or unknown content, then you dramatically decrease the likelihood that a virus or other malware can be installed because non-admin users are not able to install software on the computer.  Windows doesn’t let them.  I recommend applying it to all web browsers, all email clients, and all media players because these are the primary apps that deal with internet content.  You could alternatively apply it to the entire C:\Program Files folder, but if you do so you should be mindful of the fact that some apps might break as a result.

You can produce functionality that is similar to DropMyRights but without the annoyances that come along with it.  In my opinion this method is by far the easiest to deploy to a lot of users or computers, something which DropMyRights isn’t suited for (since any time an application is updated or a new one installed, the DropMyRights configuration has to be re-applied).  Using Software Restriction Policies, you can apply this functionality in a way that is virtually transparent to users.  However, Microsoft doesn’t publicize this particular usage of SRP for whatever reason (the functionality is actually hidden in XP by default – you need to add a registry DWORD to make it available), which is why I’m taking the time to mention it here.  When I embarked on setting this up today at my job I spent hours researching something that took only minutes to implement.  Hopefully I’m now saving you the hours of research.


The only real caveat is that when an application is launched without admin privileges, if that application then launches another process or program, the program that it launches will also not have admin privileges.  This means that if a user wants to install software that he/she downloads from the web, he/she needs to be aware that launching the setup.exe file directly from browser’s ‘Downloads’ window will generate an error and abort the installation.  In some cases it might not throw an error and instead will appear to install successfully, but when the app is launched it isn’t able to run because the installation was actually not successful.  Users have to be trained to save the application setup files to their desktops (or wherever) and then launch them from the desktops or through Windows Explorer.

Additionally, it is up to you test out any applications that you restrict.  While most of the time this is a transparent deployment, there is always the possibility that this restriction could hinder a custom application from working in the way that it was designed.  However, for most applications in most situations it works great and causes no issues.

Here’s the step by step:

1. Expose the hidden ‘Basic User’ option by opening the registry editor and adding a DWORD called “Levels” with a value of 20000 (hexadecimal) to



2. Open the domain Group Policy editor (or to apply to a single computer, open the local policy editor by going to Start > Run > gpedit.msc) and go to

Computer Configuration\Windows Settings\Security Settings\Software Restriction Policies

If this is the first time you’ve looked at the Software Restriction Policies, the right hand pane will be empty.  To rectify this, click on Action > Create New Policies.  Once you’ve done this you should see ‘Security Levels’ and ‘Additional Rules.’  Now click on ‘Security Levels’ and verify that you see 3 options (Disallowed, Basic User, and Unrestricted).

If you do not see the ‘Basic User’ option on the right-hand pane, close the GPO editor, go back to step 1 and make sure you’ve properly created the registry DWORD, then re-open the GPO editor (Note that the Basic User option is hidden in Windows XP until you add the Levels DWORD value).


3.  At this point you’re going to highlight ‘Additional Rules’ and right click to create a new path rule. Specify the path to the application that you want to limit.  In the path entry you can use the asterisk (*) as a wild card for multiple letters/words.  The question mark symbol can be used as a wild card for a single letter.

Set the security level drop-down menu to Basic User.  This is the key ingredient that makes the magic happen.  Now any executable file in the specified path or its subfolders will launch with limited user privileges on a computer that receives this GPO.



4.  When you’re done creating the policy, link it to your workstations OU and test it!  That’s it.  Pretty simple, eh?

In this example, I’ve limited Firefox so that it can only be launched as a Basic User with no admin rights. I’m able to verify this is the case by first closing all instances of Firefox, then launching it once again after the path rule has been created.  I browse to a website and download a software installation package. I then try to launch the software package from within Firefox’s ‘Downloads’ window, but I can’t perform the installation, so I know it works!


, ,