GPOs and Group Policy: Just Say No!
by WagStaff
Group Policy is a Microsoft Windows technology that supports centralized management of machines and users in a Windows domain environment, either with or without Active Directory (AD).
It functions by merging registry changes into the local Windows Registry via the distribution of Group Policy Objects (GPOs). GPOs are specialized snippets of registry files containing the desired registry settings.
The initial processing of Group Policy occurs when the computer starts up and when the user logs on, which is also referred to as "foreground" policy application. The system also applies (refreshes) Group Policy in the "background" on a periodic basis.
By default, there is a refresh every 90 minutes plus or minus up to 30 minutes (this is a random delta applied to keep all workstations in the domain from updating GPOs at the same time).
GPOs are used by sysadmins to enable or disable a large variety of Windows features and/or behaviors. If a registry entry under GPO control is changed by a user, the Group Policy process ensures that these changes are "undone" and replaced with the settings present in the GPO. This behavior can be appropriate and highly desirable in a controlled corporate setting.
However, this behavior can be quite annoying and undesirable when, for example, a home computer is used to connect to the corporate network so that the employee may work from home. Of course, this situation can and should be prevented by the proper application of GPOs.
Sadly, though, not all sysadmins are created equal. So we must have a way to deal with these sorts of real world issues.
After Googling unsuccessfully for a set of instructions on how to locally disable the GPO propagation virus (did I say that out loud?) on Windows systems, I decided to learn the details of the mechanisms in use and write my own set of instructions.
My results follow.
Please read these instructions completely before attempting any of these changes, and be sure you are comfortable editing the Windows registry. Your mileage may vary. Void where prohibited. Some settling of contents may have occurred during shipping. Don't run with scissors...
To disable "Group Policy" propagation to a Windows NT4/2000/XP workstation, perform the following steps, in order, while logged into the workstation with Administrator privileges:
(Note: If you don't have administrative privileges on the affected computer, please see the numerous tutorials available on how to "acquire" these privileges as it is beyond the scope of this article.)
Step 1
- Rename: C:\Windows\System32\dllcache\gpupdate.exe to: C:\Windows\System32\dllcache\gpupdate.exe.save
- Click "O.K." on any warning messages.
- Rename: C:\Windows\System32\dllcache\secedit.exe to: C:\Windows\System32\dllcache\secedit.exe.save
- Click "O.K." on any warning messages.
Step 2
- Rename: C:\Windows\System32\gpupdate.exe to: C:\Windows\System32\gpupdate.exe.save
- Click "O.K." on any warning messages.
- Rename: C:\Windows\System32\secedit.exe to: C:\Windows\System32\secedit.exe.save
- Click "O.K." on any warning messages.
The above changes are made to prevent future "command line" initiated updates to local Group Policy.
If the risk of that is low/nonexistent, these two steps can be skipped entirely.
The execution order of the above steps is necessary to deal with the "Windows File Protection" (WFP) mechanism introduced by M$ in Windows 2000.
Step 1 is not necessary on a Windows NT4 workstation, since it does not implement WFP.
As an alternative, you could disable WFP entirely (these details are also beyond the scope of this article) and rename only the two files present in C:\Windows\System32 (Step 2).
To avoid starting a religious war on the merits of the hare mechanism, I have opted instead to describe the above steps which sidestep that sometimes sensitive issue. Moving on...
Step 3
Search the boot/system drive (usually C:) for all files named *.pol and rename them or delete them.
Most of these files will appear under various user home directories under the C:\Documents and Settings folder structure (e.g., C:\Documents and Settings\All Users\ntuser.pol).
These are the actual policy files that are created by the domain SysAdmins and distributed throughout the domain via the GPO process. Since we're trying to disable this activity, these files are no longer necessary.
Step 4a
For Windows NT4: Navigate to the following registry key:
Create a new REG_DWORD entry there named UpdateMode if it doesn't already exist.
Set its value to 0 (in hex font 0x00000000) (Example: UpdateMode"=dword:00000000)
This step disables NT4-based domain GPOs.
If you are sure your domain exclusively uses Windows 2000-or-newer servers to manage the domain (e.g., your domain is AD-based and does not distribute NT4-based GPOs for backwards compatibility), you can skip this step.
If in doubt, performing this edit when not necessary causes no harm.
Step 4b
For Windows 2000: Navigate to the following registry key:
Create a new REG_DWORD entry there named DisableGPO if it doesn't already exist.
Set its value to 1 (in hex 0x00000001) (Example: DisableGPO"=dword:00000001)
This step disables AD-based domain GPOs only for Windows 2000 clients.
If you're not running Windows 2000 (e.g., you're running Windows XP), you can skip this step.
M$ disabled this otherwise useful feature in the Windows XP "Gold" code release. Performing this edit on a Windows XP client provides you with some typing/clicking exercise, but not much else.
Step 5
Navigate to the following registry key:
Create the REG_DWORD entries listed below if they don't already exist.
Set the values as indicated.
This step does not actually disable GPOs.
Rather, it makes them slightly less annoying should you choose not to completely disable them. It prevents the background refresh which was discussed previously and keeps foreground GPO refreshes from slowing down the boot/login process.
This step is optional and can be skipped entirely if a full disabling of local GPO processing is your desired end-state.
Step 6
Change the permissions on the following registry keys to remove "Full Control" from every user/group except your domain logon account to which you will add "Full Control" permissions:
You will have to "Add" your user account to the security list for the two HKLM key locations and give it "Full Control" permissions prior to removing the "Full Control" permissions from the other listed users/groups.
It should already exist in the list for the two HKCU keys, but it won't have "Full Control" permissions until you add them.
Step 7
Reboot the PC (hey, it's Windows, not *NIX!).
Step 8
Proceed to make any changes to your PC configuration secure in the knowledge that Group Policy pushes will no longer be an issue! Hallelujah!
Please note that Step 6 is the true "meat" in this procedure for AD-based domains (currently, the most common type of Windows domain configuration).
You can generally achieve the desired result in an AD-based domain by only performing that single step. The other steps are merely for less-common environments or for added insurance.
If you want a quick back-out strategy in an AD-based domain, then you should consider only performing Step 6.
Also, I haven't validated these steps yet in the Windows Vista (formerly "Longhorn") environment.
All indications are that they will work there "as-is," especially if Windows Server 2003 or earlier servers are used to manage the domain.
If necessary, I'll update these instructions once M$ releases the "Gold" code for Windows Vista/Vista Server (2007?).
blogs.dirteam.com/blogs/gpoguy/archive/2006/07/21/1229.aspx Just say no to bad GP articles... Jeremy Moskowitz was kind enough to point me to an article in the Summer issue of 2600 magazine (www.2600.com). For those that don't know this mag., its essentially a paper-only (i.e. not online) magazine that is written by and for hackers on a variety of hackable topics, not specifically limited to computers. The article in question was called, "GPOs and Group Policy: Just Say No!", and was written by someone called "WagStaff". The idea behind the article is that Group Policy is bad and so you will want to disable it at your earliest convenience. Problem was, the article was clearly written by someone who had had little experience with GP, so it was riddled with errors and misconceptions. The biggest problem I had with it was that the article assumed that the reader was an administrator on their machine, to which I thought to myself, "big deal!". If you are an administrator on your machine, then I would suggest that GP is totally useless and circumventable in at least a half-dozen ways. The point of GP is not to lockdown administrators. The point of GP is to lockdown users in a managed computer environment. If anyone has the notion that GP is a useful way of managing users who are administrators on their own machines, I would suggest the following test: On a machine in a domain, as an administrator-equivalent, disable the TCP/IP NetBIOS Helper service and then see how well GP does at distributing policy updates to that machine... I wrote a nice letter to 2600 with all of my concerns for the article. It will be interesting to see whether they respond. Published Friday, July 21, 2006 12:16 PM by dmarelia
www.mmshannon.net/pages/windows_info/gpo_hacks.php Group Policy Hacks (removing GPO) 08-29-06 Sometime Group Policies can be a real pain. The basic idea behind these hacks came from v23 #2 2600 summer 2006, WagStaff. What needs to be done is set permissions on the Registry keys that your GPO is hitting. This is for a Windows 2003 Domain. It may not work just like this for a Win2k domain, but the principles are the same. You will need local admin. Open Regedit and locate the following keys below and set the permissions to your Domain account only. My admins had set all sorts of other permissions on the keys and had scripts to add the permissions back. It took a few tries but once you locate all the locations you can get the job done. From regedit: HKEY_LOCAL_MACHINE\Software\Policies HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\policies HKEY_CURRENT_USER\Software\Policies HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\policies My goal was to get the Windows XP firewall turned on. There were all sorts of registry keys to kill the XP firewall so I had to locate all the keys and delete them and set permissions high enough up in the tree to block further keys being put in. I used the search function in Regedit for "firewall" and any place there were settings I went up the tree and set my permissions to just me (and my local account). At this point I have Windows XP firewall and no more refresh on the GPO!! Wagstaff had other things in his article that I am leaving out. This worked for my purposes.