This article is part of the series "Working With Windows Local Administrator Accounts". Check out the rest:
One point to keep in mind in this series is that we’re trying to limit the powers that are inherent in Administrator accounts. In short: use the Force sparingly. In the last post, we showed it’s possible to remove the local Administrator account and manage it centrally with GPOs. Let’s go over a few things I glossed over last time, and discuss additional ways to secure these accounts.
Restricted Groups: Handle with Care
In my Acme environment, the Restricted Groups GPO is used to push out a domain-level group to the local Administrators group in each of the OUs: one policy for Masa and Pimiento, another for Taco. It’s a neat trick, and for larger domains, it saves IT from having to do this through scripts or spending time performing this manually.
To refresh memories, here’s how my GPO for Restricted Groups looked:
By using the “Member of this group” section, I’m forcing the Group Policy Manager to replace, not add, Acme-IT-1 to each local Administrators group in my OU. The problem is you may overwrite existing group members, and you don’t know what services or apps depend on certain local accounts being there.
You’ll likely want to evaluate this idea out on a small sample. This may involve more work— local scripts to re-add those accounts, or possibly creating new domain level accounts that can be added into the above.
Or if you prefer, you can use Group Policy Preferences (GPP). It has an update option for adding a new group (or user) under a local Administrator account (below). We know not to use GPP to reset local Administrator account passwords, right?
Even More Secure
There is, sigh, a problem in using Restricted Groups and centrally managed domain-level Administrator accounts. Since all users by default, are under Domain Users, it means that local Administrators can be exploited through Pass-the-Hash (PtH) techniques — get NTLM hash, and pass to psexec — to log on to any other machine in the network.
This was the conundrum we were trying to grapple with in the first place! Recall: local Administrators are usually given simple — easily guessable or hackable — passwords which can then be leveraged to log on to other machines. We wanted to avoid having an Administrator-level local account that can be potentially used globally.
As I mentioned in the second post, this security hole can be addressed by creating a GPO – under User Rights Assignment — to restrict network access all together. This may not be practical in all cases for Administrators accounts.
Another possibility is to limit the machines that these domain-level Administrator accounts can log into. And again we make a lifeline call to User Rights Assignment, but this time enlisting the “Allows log on locally” property, adding the Acme-IT-1 Administrators group (below). We would do the same for the other OU in the Acme domain, but adding the Acme-IT-2 group.
This GPO prevents accounts from logging on to machines outside the specified domain. So even if a clever hacker gets into the Acme company, he could PtH with Administrator account but only within the OU.
It’s a reasonable solution. And I do realize that many companies likely already use this GPO property for ordinary user accounts, just for reasons I noted above.
Additional Thoughts
In writing this brief series, you quickly come to the conclusion that zillions of IT folks already know in their bones: you’re always trying to balance security against convenience. You won’t have a perfect solution, and you’ve probably erred on the side of convenience (to avoid getting shouted at by the user community).
Of course, you live with what you have. But then you should compensate for potential security holes by stepping up your monitoring game! You know where this is going.
One final caveat goes back to my amazing pen testing series where I showed how delegated Administrator groups can be leveraged to allow hacker to hop more freely around a domain—this has to do with accounts being in more than one Active Directory group. Take another look at it!
What should I do now?
Below are three ways you can continue your journey to reduce data risk at your company:
Schedule a demo with us to see Varonis in action. We'll personalize the session to your org's data security needs and answer any questions.
See a sample of our Data Risk Assessment and learn the risks that could be lingering in your environment. Varonis' DRA is completely free and offers a clear path to automated remediation.
Follow us on LinkedIn, YouTube, and X (Twitter) for bite-sized insights on all things data security, including DSPM, threat detection, AI security, and more.