Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

How can I, as a Workstation Administrator, disable Group Policy on that workstation?

The Domain Administrator is feeding utter garbage via Group Policy and I want it stopped.

Last antic: turning on automatic updates globally. Result: build server started making bad builds.

Education of this Domain Administrator is a hopeless cause.

Really, I don't trust the domain except for logins anymore.

EDIT: Actual answer for how to do this (I can't add the answer as question is closed):

  1. Create local admin account on workstation
  2. Log in to local admin account
  3. Un-join domain
  4. run gpedit.msc and unset all domain policies
  5. change local shell to runas /netonly /user:domain\username explorer.exe
Presto, non-domain, non-gpo machine that uses universal sign-on (well, almost -- you do get asked for your password twice).

share|improve this question
    
Which version of Windows? –  Marko Carter Jul 21 '10 at 16:14
1  
Windows XP and up. –  joshudson Jul 21 '10 at 16:24
2  
Your complaining about the DA but you don't know what a OU is? I'm sure that doesn't work very well for the DA. From the sounds of it they didn't do adequate testing or communication, now that you CAN fault the DA for! The cost of NOT turning on AU can very high but it still needs to be tested and communicated. And yes dumb DA's can be worse then dumb lusers! –  tony roth Jul 21 '10 at 16:36
    
Not a good idea. You block one, you block 'em all. This includes password policy settings, audit settings, etc. Effectively you bypass an important security control that could get you and/or your organization in hot water. Better to escalate this to your boss with specific details. –  K. Brian Kelley Jul 21 '10 at 20:05
1  
Too bad this is closed as somebody just posted the answer somewhere else: change shell to runas /netonly /user:domain\username explorer.exe –  joshudson Aug 6 '10 at 16:56
show 3 more comments

closed as off topic by Zoredache, Doug Luxem, Chris S, John Gardeniers, Mark Henderson Jul 22 '10 at 0:31

Questions on Server Fault are expected to relate to professional server, networking, or related infrastructure administration within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

6 Answers

The old "us versus them" battle (or more appropriately the old "developers versus sysadmins" battle). Maybe a conversation is in order here between the development staff\management and the system administration staff\management. There can be no winners if the two sides don't find a way to work together toward the company's common goals. Technology ultimately can't fix what is, at it's essence, a political, ego-driven problem.

share|improve this answer
1  
Seems a lot easier to set the bozo bit on the domain controller. –  joshudson Jul 21 '10 at 16:40
    
+1, Plus AD GPO can always override local settings; so you can't lock him out without un-joining the domain. –  Chris S Jul 21 '10 at 18:56
    
+1 - just don't even try and block the Group Policies. Group Policies are there for a reason, and you don't mess with that - if you do, you risk (or should, at least) very serious repercussions from management. One of our users who "found the restrictions annoying" and tried to bypass them was given a disciplinary for breaching the IT Policy, and what is effectively hacking into a company system. –  Ben Pilbrow Jul 21 '10 at 21:10
add comment

My opinion: This is not a technical problem with regard to locking out domain management from your machines.

This is about communication (and business process and policies and maybe service or operational agreements) between your group and whatever group sets the AD policies.

You need to document what your requirements are for the server and then work out if that means things like no global updates and that means bosses need to agree to it to. Likewise, they probably have other requirements that they need to communicate. There's got to be a compromise that is workable for both sides...both groups just need to be committed to finding it.

If, once there is a workable agreement in place, they keep breaking things in violation of that agreement, then it's time to call them on it and escalate. You start showing the impact of the build server broken for example, complaining to bosses, etc.

share|improve this answer
add comment

Get your own OU and then either write your own policies to override or block inheriting.

There basically is no solution that I would recommend for a production server. (yes you can fool around with disabling policy applying dlls (and windows file protection etc) and such, but that just seems unwise)

share|improve this answer
1  
Not sure what OU means –  joshudson Jul 21 '10 at 16:28
    
Your answer presumes that the OP has the rights to create OU's in the domain, has the rights to move computer objects, and has the rights to create and link GPO's. –  joeqwerty Jul 21 '10 at 16:29
1  
@joeqwerty This is why my solution is very involved client-side. Bosses taught me how to do this because I did not have permissions in our domain to modify AD objects or GPO's when I was a student. Oh well. –  ajstein Jul 21 '10 at 17:00
    
And your answer presumes that he has the authority to do so. Rights != authority. –  K. Brian Kelley Jul 21 '10 at 20:07
    
Update: Domain admin doesn't know what OU is either. –  joshudson Dec 9 '10 at 22:04
add comment

Well, I will tell you about the easiest way to subvert Group Policy (my experience ranges with Windows XP, Vista, and 7 and it should work in principle with all of them).

First of all, you are going to need local Administrator privileges on the box in question. If you do not, you are going to have do this first (and if you get yelled at, not my problem).

  1. Burn the ISO of NTPassword Reset Disk. I am not explaining the instructions for that, because the instructions presented are very straightforward by the utility.
  2. Shut down the computer.
  3. Disconnect the ethernet connection for the time being.
  4. Boot your disk and reset the local Administrator account, or any local account with admin privileges.
  5. Reboot the computer.

Now, here is where the fun begins. Keep that ethernet connection disconnected.

  1. Log into the local account you just reset the password for after the reboot.
  2. Move the Group Policy folder. Copy and paste the following into a command prompt. cmd /k move C:\Windows\System32\GroupPolicy GroupPolicy.arc
  3. Now reboot the machine.

Now, so far, you have cleared the local store of GP on this box. Now, if you reconnect, all that will happen is that it is certainly going to be re-applied on reboot. That is the pickle, my friend. Now, to move forward in this conondrum, you have only two choices really: move the computer object to an OU where it is not impacted by said GPO's or unjoin from the domain. Depending who you are at your organization, expect wrath from someone if you are not the right guy. So, if you decide to unjoin, which means also losing AD authentication (but I am sure you know that, do the following).

3a. Unjoin from the domain by copying pasting this from the command prompt. cmd /k wmic computersystem where name!=null call unjoindomainorworkgroup. You can do it the GUI way, but I hate that. If it successful, the return value will be 0. 4a. Reconnect the ethernet cable and reboot the machine.

or

3b. Move it to the proper OU without interfering policy. 4b. Ethernet time, reconnect and reboot.

Now, I will not explain 3b. If you are an admin know what you are doing, I should not need to explain it. If you do not, you should probably not do this in the first place.

share|improve this answer
2  
@joshudson On second thought, I am not recommending this if you do not know what an OU is. If you were a sysadmin for a rogue box, this is what I do. In your case, I would be careful. Needless to say, your admins will be pissed if you try this and they find out what you did after hosing the computer months later. –  ajstein Jul 21 '10 at 16:37
2  
-1. Your intentions might be good, but assisting someone in subverting their company's policies (group policy, security policy, etc) is not the kind of answer I would expect would be met with any kindness here. –  joeqwerty Jul 21 '10 at 16:41
1  
@alharaka: I hear you. I would only suggest a little caution with answers that may be construed as "Here's how you hack your company's security mechanisms". That being said, I was a little hasty with my downvote and should have paid more attention to the spirit of your answer. My apologies. –  joeqwerty Jul 21 '10 at 17:02
1  
I am a sysadmin. I admin both the build machines and the production servers. I am not a domain admin, and the last time I was a domain admin was NT4. –  joshudson Jul 21 '10 at 17:23
2  
@Chris S I totally understand what you mean, and my procedure can be used for good or evil. Any idiot who would do this to install something stupid is asking for his own pain, and will not realize why his account won't log him in anymore. As I pointed out in bold, this will lose you AD/Kerb authentication to log in (I fixed the typo so it was clear to even the greenest techies). In the real world, you cannot have your cake and eat it too. Convenient network authentication means you play by admin rules. End of story. –  ajstein Jul 21 '10 at 19:46
show 7 more comments

One method I've seen is to disable the "NetBIOS TCP/IP Helper Service". The reason this works is that the GPOs are located at a DNS domain like "addomain.example.com", and without that service turned on your local Windows stations can't turn that into an IP address for GPO processing. This has other side-effects, but at least you can still keep domained and blithely ignore network policy.

Note, it doesn't stop the GPOs from applying, but it does prevent them from being updated. To remove the local cache, alharaka has that procedure.

What kinds of side-effects are we talking about? If you still have a WINS server out there, you may not even notice. If you DON'T have a WINS server, then accessing off subnet Windows workstations (like, say, Domain Controllers for login) won't work. You may have to resort to populating your lmhosts file for the DCs just so you can log in.

share|improve this answer
add comment

Communicate well to reach the best alternative.

If you start an IT war, you can trust Administrators to perform administrative actions.. like Mac address filtering so you have no internet until you play nice.

It may be politics, but if he were communicating with you this problem wouldn't exist. So, inflating the problem by not communicating back is of no better doing.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.