Group policy is a powerful 2-edged source. Case in point: last week I was in a rush, I needed to generate a group policy change event in the security log. I flipped to the Group Policy Editor window already open on a test GPO, picked a setting at random and enabled it. I got my audit event and moved on.
After lunch I came back and attempted to logon with my finger print to my Windows 10 desktop. Nothing doing. Tried my PIN and finally my password. Then I read the message: “Smartcard required”.
Yep. That was the setting I picked at random to enable: Interactive logon: Require smart card. And it turns out, because I switch between unrelated tasks like many others, there was more than one Group Policy Editor window open. And instead of enabling this policy on the Test GPO, I enabled it on Default Domain Policy.
So that locked me out of interactive logon and remote desktop logon to EVERY computer in the domain including domain controllers. I didn't feel like walking downstairs to try logging on the domain controllers' local console to see if they were an exception to the rule. Instead I edited the actual text file in the sysvol folder where a GPO's settings are actually stored and incremented the version number on the groupPolicyContainer object in AD using ADSI Edit. But for a while it was touch and go. Now of course you wouldn't make a mistake like this but are you so sure about your colleagues.
Important take-aways:
- It's really easy to “hose” your domain without stringent group policy change controls
- Bad guys with sufficient permissions can bypass Group Policy Editor to make changes to group policy
- You need to lock down group policy access so that people like me can't run amok
- You need an audit trail to enforce accountability and to detect unauthorized changes as soon as they occur
- You need recovery options
In this real training for free ™ webinar I will show you the security controls available in Windows and Active Directory that control who can make changes to group policy objects as well as group policy related attributes on other objects like Organizational Units and Domain roots.
The latter is an important point because changing the gpLink or gpOptions attribution on an OU can be just as disruptive as editing an actual GPO.
So it's important to carefully manage the permissions on
- The GPO itself
- The System/Policies folder in AD
- The sysvol folder on domain controllers
- The gpLink and gpOptions attributes on the domain root and organizational units
I'll also show you what's available in Windows and AD for auditing group policy changes. The good news is that you can instantly know when anything group policy related is changed in your domain and who did it. The bad news is that the audit log is cryptic and doesn't tell you which policies inside a GPO were changed. But there's ways to figure this out – especially if you are saving backups of group policy objects on a regular basis and especially before making changes.
I'll show you how to backup group policy and how to compare one version of a GPO to another.
Finally we'll look at some strategies for limiting the damage of group policy configuration mistakes when they do happen. For instance, I’m going to erect a barrier above the Domain Controller's OU and change the permissions on Default Domain Controllers GPO so that I can't accidentally edit it with my every day admin account. There's a more “enterprise best practice” way to do this in your environments – mine is just a lab.
Quest is sponsoring this real-training-for-free ™ event and Quest product manager Chris Ashley will briefly show you their super-powerful GPOADmin product which automates much of what I show you and wraps vulnerable group policy objects in a workflow environment with version comparison, rapid rollback, approvals, history and more.