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.
Originally by Mark Russinovich on 4/30/2005 10:01:00 PM
Migrated from original Sysinternals.com/Blog
# re: Circumventing Group Policy Settings
FYI...
A full list of the available policy setting and their corresponding registry keys can be downloaded from MS site as an Excel Spreadsheet.
Asher.
5/1/2005 8:29:00 AM by Anonymous
# re: Circumventing Group Policy Settings
The Download gives a 404 after MS redirects me to the download itsef! :-(
5/1/2005 9:37:00 AM by Anonymous
# re: Circumventing Group Policy Settings
5/1/2005 3:56:00 PM by Anonymous
# re: Circumventing Group Policy Settings
Mark,
Wonderful article!
I just love to learn new ways of using your wonderful set of tools.
keep blogging.
5/1/2005 10:39:00 PM by Eli Rapoport
# re: Circumventing Group Policy Settings
We dont pay mark enough
5/2/2005 1:31:00 AM by Anonymous
# re: Circumventing Group Policy Settings
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
5/2/2005 5:42:00 PM by Anonymous
# re: Circumventing Group Policy Settings
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...
5/2/2005 9:04:00 PM by Anonymous
# re: Circumventing Group Policy Settings
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.
5/3/2005 8:08:00 AM by Anonymous
# re: Circumventing Group Policy Settings
An administrator which allows use of regedit by users is really stupid !
5/4/2005 12:19:00 AM by Anonymous
# re: Circumventing Group Policy Settings
"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.
5/4/2005 8:56:00 AM by Anonymous
# re: Circumventing Group Policy Settings
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?
5/5/2005 9:25:00 AM by Anonymous
# re: Circumventing Group Policy Settings
Hello,
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...
5/9/2005 10:11:00 AM by Itay
# re: Circumventing Group Policy Settings
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.
5/13/2005 2:48:00 PM by Ross
# re: Circumventing Group Policy Settings
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.
5/17/2005 12:32:00 PM by NimbUs
# re: Circumventing Group Policy Settings
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.
6/23/2005 2:37:00 PM by Joshua Hudson
# re: Circumventing Group Policy Settings
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.
6/24/2005 8:34:00 AM by Wes Miller
# re: Circumventing Group Policy Settings
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 :-(
Martin
7/1/2005 2:38:00 AM by Anonymous
# re: Circumventing Group Policy Settings
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?
7/17/2005 6:31:00 PM by Winged
# re: Circumventing Group Policy Settings
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.
8/22/2005 8:53:00 PM by Anonymous
# re: Circumventing Group Policy Settings
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.
8/22/2005 10:50:00 PM by Anonymous
# re: Circumventing Group Policy Settings
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 systemtools.com. 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).
8/24/2005 3:51:00 PM by rotaiv
# re: Circumventing Group Policy Settings
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...
8/24/2005 5:17:00 PM by Anonymous
# re: Circumventing Group Policy Settings
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??
8/25/2005 8:35:00 PM by Drink..But..Very..Carefully
# re: Circumventing Group Policy Settings
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.
Regards,
John
9/2/2005 11:05:00 AM by John Rolstead
# re: Circumventing Group Policy Settings
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
9/18/2005 10:54:00 PM by Anonymous
# re: Circumventing Group Policy Settings
Once you circumvent the group policy, is it permanent?
10/5/2005 11:32:00 AM by Keith
# re: Circumventing Group Policy Settings
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...
10/15/2005 4:33:00 AM by Anonymous
# re: Circumventing Group Policy Settings
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.
11/3/2005 11:35:00 AM by Adam Leinss
# re: Circumventing Group Policy Settings
Question:
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).
11/21/2005 8:01:00 AM by Michael Dawson
# re: Circumventing Group Policy Settings
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 :-(
1/19/2006 7:17:00 AM by Anonymous
# re: Circumventing Group Policy Settings
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,
Kevin
1/30/2006 12:52:00 PM by Anonymous
# re: Circumventing Group Policy Settings
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.
2/8/2006 5:26:00 PM by Wade
# re: Circumventing Group Policy Settings
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.
2/21/2006 12:42:00 PM by Anonymous
# re: Circumventing Group Policy Settings
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.
Cheers.
3/8/2006 5:51:00 AM by Anonymous
# re: Circumventing Group Policy Settings
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?
Thanks,
3/27/2006 10:23:00 AM by Anonymous
# re: Circumventing Group Policy Settings
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.
St4rW4rs!
W0rkingSucks!
?W0rkT0d4y?
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.
4/27/2006 3:39:00 PM by Anonymous
# re: Circumventing Group Policy Settings
>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?
5/5/2006 11:28:00 AM by empyle
# re: Circumventing Group Policy Settings
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?
6/19/2006 2:18:00 AM by 2raj
# re: Circumventing Group Policy Settings
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?
6/27/2006 8:01:00 AM by Anonymous
# re: Circumventing Group Policy Settings
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 ?
6/30/2006 9:12:00 AM by Anonymous
# re: Circumventing Group Policy Settings
GPUpdate /force will pull down all the GPO settings from the DC again and reapply any settings you have overridden.
"GPUpdate" with no /force only checks to see if the machine's GPO version number matches the DC's GPO version number.
Additionally, any Security settings are automatically reapplied every 16 hours by default even if the DC's version of the GPO hasn't changed.
8/10/2006 12:07:00 AM by Anonymous
# re: Circumventing Group Policy Settings
an FYI, you can lock down the registry so that no one can edit it with a GPO. This even applies to local admins. Really, this article does not help much with that.
8/24/2006 9:03:00 AM by Anonymous
# re: Circumventing Group Policy Settings
A quick way to enable regedit access when it's locked down by GP is, take the following code, paste it into notepad, and save it as enableregedit.inf
__________________________
[Version]
Signature="$CHICAGO$"
[DefaultInstall]
DelReg=EnableRegTools
[EnableRegTools]
HKCU, "software\microsoft\windows\currentversion\policies\system","DisableRegistryTools"
__________________________
then Right click the file and choose "Install". Notice the INF file format. It fools the system into installing a registry key when normally it would refuse. ("Registry editing is not allowed, blah blah...") You have to be a local admin (or power user) to install though.
9/20/2006 12:05:00 PM by Andrew
# re: Circumventing Group Policy Settings
For you who wanted to know how to stop GP from reapplying.
To change the refresh interval for computers:
Registry key: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\ System
Name: GroupPolicyRefreshTime
Type: REG_DWORD
Valid range for data (in minutes): 0 to 64800
• To change the offset interval for computers:
Registry key: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\ System
Name: GroupPolicyRefreshTimeOffset
Type: REG_DWORD
Valid range for data (in minutes): 0 to 1440
To change the refresh interval for users:
Registry key: HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\ System
Name: GroupPolicyRefreshTime
Type: REG_DWORD
Valid range for data (in minutes): 0 to 64800
• To change the offset interval for users:
Registry key: HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\ System
Name: GroupPolicyRefreshTimeOffset
Type: REG_DWORD
Valid range for data (in minutes): 0 to 1440
0 == Never
10/10/2006 4:18:00 AM by Anonymous
Comments
- Anonymous
July 25, 2010
Several great comments, very helpful.