23

I am trying to provision a few special case laptops. I would like to create a local guest account. That's fine but when I try to create it I prompted that my guest password does not meet the complexity requirements.

I tried editing the local security policy to change the complexity but this is greyed out. Is it possible to override domain policy with local?

Yes, I know I can chose a longer password but that is not the point. I want to know how to override domain policy in case I need to in the future.

24

There are always way to hack around central policies if you have local admin access - at a minimum you can make your changes locally to the registry and hack the security settings so they can't be updated by the group policy agent - but it isn't the best way to go. I'll admit to doing it 10 years ago.. but really.. don't. There are unanticipated results in a lot of cases.

See this technet article. The order for policy application is effectively:

  1. Local
  2. Site
  3. Domain
  4. OU

Later policies will overwrite earlier ones.

Your best bet is to make a computer group and use that group to either exclude your custom computers from the password complexity policy or assemble a new policy that'll override these defaults, filtered to only apply to this group.

  • 4
    Thank you. Very informative. That is very dumb though. A local admin should have complete power over that particular local machine just like Linux root. – hkkhkhhk May 8 '14 at 16:27
  • 2
    @hkkhkhhk - even root in Linux has limits. :) If you are using a centralized management product like Puppet or Chef they'll keep pushing out their policies and revert changes made by the local root account, just like group policy. The design is intentional - it forces folks to to use scalable methods. – Tim Brigham May 8 '14 at 16:32
  • But as Linux root I can always tell Puppet to GTFO if I need ;). What I mean is that local configuration always beats remote (think NIS+ or LDAP authentication). All the puppet deamon is doing is basically pushing out configs that are applied locally. – hkkhkhhk May 8 '14 at 16:51
  • 11
    @hkkhkhhk - It's not a "dumb" design. A domain admin always trumps local admin. That's the whole point. – user62491 May 8 '14 at 18:50
  • 1
    To add to hkkhkhhk's comment: If you are a local admin and you do not like to be trumped by the domain admin you have the power to leave the domain. However, you do not have the power to override the rules of the domain set forth by the group policy. (Well, you have, but only by hacking as described in the answer.) – Martin Liversage Oct 7 '14 at 12:45
18

I've worked around this by creating a script that overwrites the policies I don't want in the registry (you can use the "REG" command in a batch script). This script can be set to run using Task Scheduler, immediately after the Group Policy client finishes applying the policy, by using "On an event" as the trigger.

The best event trigger that I have found is Log: Microsoft-Windows-GroupPolicy/Operational, Source: GroupPolicy, and Event ID: 8004, but you can check the event viewer logs for some additional possibilities.

  • 1
    Dude you are my hero. Folks don't forget that if you are modifying registry keys (like for windows firewall) that you need to restart the service in question for it to pick up your changes. – brakertech Dec 17 '17 at 4:00
1

A potential solution, using Windows 10 Enterprise. I haven't tested it in a domain environment. I tested it locally, and it prevented c:\gpupdate /force from working entirely. If I understand the mechanism correctly, I presume this will break a foundation component, and therefore guarantee's the user 100% success rate. I used a tool that lets me run binaries with TrustedInstaller/System authority. Sordum PowerRun in my case. The binary I ran with these elevated permissions was "services.msc". I then Stopped(if started) and disabled Group Policy Client (service name: gpsvc). It's at this point that c:\gpupdate /force no longer functioned. I'm not joined to a domain, but the disabled startup type persisted through reboots. So the idea is, you revert/change/override/whatever group policies inherited from the domain controllers, then disable the gpsvc service before another automated gpupdate fires off. Most of this is my theory, but I like this solution if it works, because I subjectively feel it has a high level of plausible deniability. "uhh.. must be the ram going bad, flippin bits and whatnot"

Edit: Did find a quirk, the firewall turns itself off if gpsvc is disabled :|

-3

Remove it from the domain... do whatever you need to do to the machine then re add it. depending how your GPO is set up this works in most situations. Either way i would run it by the IA mafia and get something in writing stating whatever your doing is authorized. Especially considering in most situations a security violation as a sysadmin can result in immediate termination.

  • 2
    This has a very little chance of working. Next time the group policy sync comes through, everything's changed again. – mstaessen Mar 14 '16 at 15:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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