Sysinternals Freeware - Mark Russinovich & Bryce Cogswell

Mark's Sysinternals Blog

Circumventing Group Policy Settings

Group policy settings are an integral part of any Windows-based IT environment. If you’re a network administrator you use them to enforce corporate security and desktop management policy, and if you’re a user you’ve almost certainly been frustrated by the limitations imposed by those policies. Regardless of which you are, you should be aware that if the users in your network belong to the local administrator’s group they can get around policies any time they want.

There are two steps to circumventing a group policy setting: identifying the setting’s location and preventing the setting from being applied. There are many group policy references available, but since machine group policy settings store in the HKEY_LOCAL_MACHINE branch of the Registry and per-user group policy settings store in HKEY_CURRENT_USER, if you don’t know the location of the setting that’s preventing you from doing something you want you can use Regmon to find it.

The number of desktop lockdown settings available to group policy administrators is enormous. They can prevent you from doing anything from changing your desktop appearance and start menu to running certain applications. Two commonly applied settings include a pre-configured screen saver program so that users don’t waste resources on frivolous screen savers, and a screen saver timeout so that systems aren’t left indefinitely accessible when a user steps away. When these settings are in effect Windows omits the screen saver tab of display properties control panel applet or doesn’t let you modify the screen saver or its timeout. I’m going to show you how to use the power of being a local administrator and Regmon to track down these settings and override them on your own system.

The first step is to launch Regmon and capture a trace of policy setting being read by whatever process enforces it. Explorer implements most policies, reading some at the time you login and others when you perform specific actions. If the policy setting is read during the logon process you must run Regmon in the local system account so that it captures a trace of your logon. You can do that by using psexec:

psexec –s –i –d c:\sysint\regmon.exe

The instance of Regmon that launches will survive subsequent logoffs and logons and capture all activity during those activities.

Explorer doesn’t show the display properties dialog, but to easily determine which process hosts a configuration dialog such as the display properties dialog, simply run Process Explorer and highlight the dialog with Process Explorer’s window-finder toolbar button. Process Explorer selects the owning process in response, which for the display properties dialog is a Rundll32.exe process (look at its command line in its Process Explorer properties dialog to see how it launches).

Next, search or visually scan the resulting Regmon trace for strings that you think might be in the name of the Registry key or value related to the policy setting you are targeting. For example, if you scan a trace of the display properties execution you’ll find a query of HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System\NoDispScrSavPage. In the trace displayed below the value is set to 1, which means that a per-user policy is in effect and that the screen saver page won’t show on the display properties.

Once you’ve identified a policy’s Registry value you can prevent the policy from being applied by removing all access to the Registry key in which it’s stored. Double-click on the value in Regmon’s trace to open Regedit to the value, move to the parent key and open the security editor. In most cases the security of the key is inherited so you won’t be able to just remove the existing access entries. Instead, you’ll have to open the permissions editor’s advanced security dialog and remove inherited security. If you try to edit the permissions of the key and you are denied access use the advanced security dialog to make yourself owner of the key (since the local administrator’s group has the Take Ownership privilege assigned to it) and then you’ll be able to modify its security.

The next time you open the display properties dialog it won’t be able to read the policy settings and will behave as if the policy is undefined. Unfortunately, the HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System key doesn’t store the screen saver selection or timeout policies, so if those are defined you’ll see a dialog like this:

If you capture another Regmon trace and look through it for relevant values you’ll find these queries:

Once you remove all access to HKCU\Software\Policies\Microsoft\Windows\Control Panel\Desktop you’ll be able to reopen the display properties dialog and select the screen saver of your choice. I recommend that you leave the timeout to whatever your network administrator has defined (or lower it) so that you don’t get into real trouble by violating the security policy (as opposed to the usage policy you violate by changing the screen saver).

This demonstration highlights the fact that networks that run with users as local administrators have no way to police the usage of their computers. The reason that most networks leave their users with so much power is that many line-of-business applications violate basic security programming guidelines and won’t run otherwise. However, by using Regmon and Filemon to find the Registry keys, files and directories that an application is unable to access as a limited user, and then defining security group policy settings so that limited users have access to those resources, network administrators can run users in limited accounts and gain real control of corporate computer usage and security policies.

posted by Mark Russinovich @ 10:01 PM

A full list of the available policy setting and their corresponding registry keys can be downloaded from MS site as an Excel Spreadsheet.

The Download gives a 404 after MS redirects me to the download itsef! :-(

Wonderful article!
I just love to learn new ways of using your wonderful set of tools.

keep blogging.
We dont pay mark enough
On newer versions of Windows gpupdate can tickle group policy application without needing to log off/on. There was some similar cmdline tool for downlevel OSes - name slips my mind right now.

- Drew
i tried this technique and it appears my subsequent policies are not applied - my connection to SQL Server no longer works. P

Putting back the permsissions fixes the problem I think...
It would be nice if there were tools that allowed automated changing of the DACL with very logical commands and precise control. Using the DACL and personalizing the ACL (to your implementation) of those keys can help.
I am of the opinion (with XP and above), never log in with administrator access. There are too many things out there that could be 'wandered' across and mess up a computer totally.
I always use 'run as' for my administrator duties at home and at work.
An administrator which allows use of regedit by users is really stupid !
"An administrator which allows use of regedit by users is really stupid !"

Incorrect - An administrator who lets users run as administrators and assumes he has any level of control over them is wrong.
Hi Mark,
I am not sure if this is the right place to ask my question about Process Monitor. I wish to know - how does the suspend option wok in it. What happens when you suspend a process?
What about the password setting, like enforcing password complexity and password expiration timeout? I'd like to circumvent these, but they're not registry settings. Don't like to change the password every month...
Since the password policy settings belong to the domain controller, and the domain controller ultimately has to approve your new password ... no, there's no way for a local admin of a desktop to avoid following the password policy of the domain.
As a member of the local administrators group, I may create a new local account (user or machine); why does Windows seem to enforce the network password length etc. restrictions for such a local only, non domain, account ?

Or is there a way around ? I have not set any local password policies, yet Win 2k insists my new local account must follow the minimum length rules for domain passwords.
Is this a joke? I have killed group policy settings as applied to my account on a W2K domain without being local administrator.

The GPO is copied into a key under HKEY_CURRENT_USER and applied from there. I found the key, and changed its permissions to Administrators: No access, Me: Change Permissions, Everyone: (null). GPO no longer worked for my account.

Yes, the administrator owns the GPO key in HKEY_CURRENT_USER, but I own ntuser.dat.
Joshua - were you logged on as a member of the administrators group when you did that? If so, it's obviously the same loophole - admin = everything. If you were not an Admin, then it's an example of inadequate ACL on your domain administrator’s part. Deny write should have been set against all non-administrator accounts on your system on that key. Unless you are an administrator on the system, you don’t own NTUSER.DAT. You just use it.
Reasons to ALLOW local admin rights: neither Norton's LiveUpdates nor Windows Automatic Updates will run if you're not logged in as admin. Discovered that on my kids' XP Home machines when I tried to lock them down against anything nasty getting installed :-(

This is a bit of a gripe against Microsoft, so here goes:

This demonstration highlights the fact that networks that run with users as local administrators have no way to police the usage of their computers. The reason that most networks leave their users with so much power is that many line-of-business applications violate basic security programming guidelines and won’t run otherwise. However, by using Regmon and Filemon to find the Registry keys, files and directories that an application is unable to access as a limited user, and then defining security group policy settings so that limited users have access to those resources, network administrators can run users in limited accounts and gain real control of corporate computer usage and security policies.

Just how in the 9 layers are administrators supposed to figure out just what each individual process needs/wants in order to run? There's over 200 business-critical applications that are being used in most Fortune 1000 companies -- and trying to tune for each group's unique requirements (payroll needs access to this data, while HR needs access to that data but not this data, the controller needs access to payroll data but not confidential HR data, developers need to be able to compile, run, and debug applications on their machines AS WELL AS maintain the security policy, the CEO wants everything but will never use any of it until that one day that he does and it doesn't work and he beats down your door with a wild look in his eye that says "pink slip" all over it...)

How is an administration team supposed to figure all this out? How much does does it take to determine the functional requirements of an application, then determine that all policies comply with what that application needs? Is there ever going to be a way to specify an application security policy that overrides the user or machine policies, for those things that just /require/ more privileges than you want the users to have?
On the Password restrictions, it is enforced by the domain controller. I imagine the policy has a reg key that enforces the local password policy.

The thing I hate about password policy as implemented by my companies administrator is that they enforce using mixed case, numbers and / or other shift / control requiring "special" characters. The password must contain 3 of the four catagories. Previosly I only had 2 catagories. now they require me to shift-mod part of my passwords.

Requiring such shifted characters in a password only provides two bits of entropy against attack, while simply increasing the minimum password length by 1 character provides 6 bits more entropy with the same keyboard effort.

Personally my passwords are twice the min length so to me enforcing a longer password will not effect me.

I have found many of the policy settings can be superseeded by other policies. Example: the authorised use confirmation dialog can be overriden by disabling the enforcement of the alt-ctrl-del to login policy.

I have used the disallow priveledges technique to disable many unwanted employer mandated "malware" on my work machine. Many such tricks can be done with only Power-User priveledges.
It's nice to say that users shouldn't have local admin access, but in the real world where you have hundreds of critical apps running it's impossible to get everything working without opening the door a little. Not to mention that software updates typically break a carefully configured lockdown.

We use Server 2003's interactive group to give us certain functionality. Users do not have the rights to run any executable except those contained in paths we have created (using software restriction policies). They don't have access to these paths through windows explorer (through restrict and hide drives) and all command prompts, regedit and other console tools are all blocked.

Users cannot modify their profiles to prevent group policy, since there profiles are mandatory and read only to the user. We also set Group policy to immediately log off the user if all group policy settings are not applied at logon.

It's not 100% secure, but it's a usable solution that keeps most users out of trouble. The lengths users have to go to in avoiding these settings increases the penalties applied if they are caught breaking them.
It is possible to set a password (local or domain) that bypasses the complex password requirements. You have to manually create a password hash (Perl's Crypt::SmbHash will work) then inject the password directly into the SAM using copypwd from This works on XP, 2000 and 2003 and bypasses all password policies. You have to be administrator of the machine with the account you want to update (either member workstation, server or even domain controller).
Regarding the person complaining about his complex password policy..."Enforce Password Complexity" is an on / off setting. You either have to meet 3 out of the 4 criteria (upper, lowercase letters, numbers and symbols) or you don't have to meet any criteria beyond password length.

And, while I don't know much when it comes to "bits of entropy," I do know that a brute force attack will take far longer when the character set includes 3 out of the 4 groups than otherwise.

Requiring password complexity forces attackers to use brute force rather than dictionary attacks, or at least that's the idea...

Password length has a much more dramatic effect, except people are prone to use "long passwords" that are simple lowercase strings of common words that can easily be strung together in a dictionary based attack. "supercalifragilistic..." et al...
Hello Mark

Nice article on you and your skill... What do you think is coming in the next few years inre to Microsoft and it's products. And is there going to be a mojor change or just minor tune-up with 64 bit format and how soon 32 bit will come obsolete??
password policy is applied to the domain. Therefore it applies to local computer accounts. Accounts for the domain are in AD, which lives in ntds.dat on the domain controller. The domain controller applies the domain linked GPO to enforce password complexity on the domain accounts. The member server/workstation applies the same domain linked GPO to the local SAM accounts. So you can edit registry on member server/workstation to block the policy if you are local admin. You are probably not administrator on the the domain, and therefore can't change the registry on the domain controller, so AD accounts are safe from tampering.
Look for an application that allows you to open the HELP files
like an antivirus program [which would have Administrator priviledges]
THEN open a file that escalates your lvel to that admin level
Lots of examples on-line
Once you circumvent the group policy, is it permanent?
Should it be possible to "lock" a registry key or part of a subtree so only Domain Administrator can modify it? (and local admins can't)

I work for a company that develops software and not letting our programmers to access their machine registries sounds kinda impossible, but I'd like to use HKLM/System/CurrentControlSet/Control/StorageDevicePolicies/WriteProtect=1 policy to avoid people from writing to their USB pendrives...
No, you cannot lock it down to just Domain Administrators. The group Domain Administrators only has "power" on a local box because it is placed in the local administrator's group.
Restricted group policies are aplied to all workstations in the domain. Is there a way to add local users to the local admin group without the restricted group policy deleting them?
So basically is there a way to add exceptions to the way restricted group policies are applied and allow e.g. developers to have local admin rights (on their own workstation only).
It works fo removing the policies, but how to prevent them being refreshed every 90 minutes from domain controller? In 90 mins they are back :-(
I am local administrator of a laptop which occasionally connects to a domain. This domain applies an SUS policy that adds itself and removes local administrators from the "Manage auditing and security log" policy. Apparently it also prevents me from adding the Administrators group back. I'm unable to install Windows Updates and the "Manage auditing..." policy is not kept in the registry, according to the MS spreadsheet. Is there some way I can regain access to "Manage auditing..." and prevent the domain from locking me out of it?

Any info appreciated,
Great article! My only comment is if you have an employee that is technical enough to be able to use regmon/filemon/regedits/bypassing inherited permissions, they are surely technical enough to get around being in a lower security group and adding themselves's to the local administrators group, which incidentally is much easier to do.

The bottom line, if you have physical access to the box you can get around group policy, regardless of whether they are in the local admins group or a lower security group.
Great article (and the followup too) but even with the permissions set on my HKCU\Control Panel\Desktop key, the company policy here is still changing the "Wallpaper" string to their own bitmap...? The permissions before and after show only me (domain user + local admin) as having any permissions (and as owner). How is this?
Thanks again for the article.
We have a corporate desktop wallpaper at the moment & I would like rid of it for my own. I have exclusive permissions for the registry & when the machine logs into the domain, it says something about not being able to apply the network policy, but its going to apply the local policy instead. When I right click & properties, most of the desktop options are still greyed out, how do I get round this?

BTW I have admin persmissions on my machine.

Hi, according to the MS excel sheets I've downloaded form above link, you can't hide {Log on to} field. But that doesn't make sense as it says {This setting only works when the computer is not on a domain.}
Anyway, is there anyway of hiding the LOG ON TO field so the users don't log on to a different domain?
Great Article. I just wanted to comment about people saying they want to get around the "complex password" policy. Ussually the IT staff of a company set this up for a reason and it is not to torture their users. It is part of an overall security policy to protect company assets against attacks. Honestly how hard is it to add a number, letter and a special character. Here are some great passwords that are still easy to remember.


See how easy it is? Also the default domain policy for passwords will not apply to the local accounts. The company i am a sys admin at just implamented Complex Passwords today and we tested local accounts.
> Also the default domain policy for passwords will not apply to the local accounts.
> The company i am a sys admin at just implamented Complex Passwords today and we tested local accounts.

Your setup must be different from ours. It's a common complaint that the domain password policy is also applied to local accounts.

It has already been stated that the enforcement of password complexity (on local accounts) is not stored in the registry. But the world has been strangely silent on where it actually is stored. Come on, now. Give it up! Where exactly is the enforcement of password complexity stored?
Thank you for an excellent article!

The Microsoft aricle lists some of teh policies as not kep[t in teh registry, eg. "User Rights security settings are not registry keys".

Now the $64,000 question is how to chaneg these ones?

Does the ntuser.pol file have anything to do with these?
The screen saver lockdown can be a problem for end-users during lengthy presentations, live meetings, etc. Is there something that a regular user can do to keep the screen active, aside from hitting the mouse every 10-14 minutes :-), and violating corporate policy?
I was able to delete the keys responsible for the screensaver lock, but now when I log off and back on (since this is a user based group policy), the group policy does not put these registry keys back. I have even tried rebooting, gpupdate, gpresult shows the GP was applied

Any ideas ?
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?

RSS Feed



Full Blog Index

Recent Posts

The Case of the Mysterious Locked File
.NET World Follow Up
The Coming .NET World – I’m scared
Services Polling when Process Explorer is Running
Explorer’s Registry Polling
Cable DVRs and Competition
Polling and MSN Desktop Search
MSN Desktop Search Bugs
Updated RootkitRevealer
More on MSN Desktop Search


03/01/2005 - 03/31/2005
04/01/2005 - 04/30/2005
05/01/2005 - 05/31/2005
06/01/2005 - 06/30/2005
07/01/2005 - 07/31/2005
08/01/2005 - 08/31/2005
09/01/2005 - 09/30/2005
10/01/2005 - 10/31/2005
11/01/2005 - 11/30/2005
12/01/2005 - 12/31/2005
01/01/2006 - 01/31/2006
02/01/2006 - 02/28/2006
03/01/2006 - 03/31/2006
04/01/2006 - 04/30/2006
05/01/2006 - 05/31/2006
07/01/2006 - 07/31/2006

Other Blogs

Raymond Chen
Dana Epp
Aaron Margosis
Wes Miller
Larry Osterman
Bruce Schneier
Larry Seltzer