Working With Windows Local Administrator Accounts, Part III

Administrator Accounts

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:

Acme-IT-1.

Replaces local  Administrators groups with Acme-IT-1.

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?

Acme-IT-2

With GPP, you can add Acme-IT-2 to the local Administrators groups.

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.

Allows log on locally property

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!

Get the latest security news in your inbox.