Can I override domain group policy with local group policy as a local admin?
Solution 1:
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:
- Local
- Site
- Domain
- 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.
Solution 2:
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.
Solution 3:
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 :|