UpGuard 101: Verifying Windows Groups

September 15, 2017

Estimated Time to Read:6 minute read

This article is part of our ongoing UpGuard 101 series that focuses on ways to use UpGuard to keep your environment ready and yourself sane in real world scenarios.

Keeping track of which people are members of privileged groups is an important part of mitigating cyber risk The more access a group has, the fewer members should be in it, and the more important it is that unauthorized accounts are not added. In a single sysadmin environment, this is usually no problem, since one person acts as the gatekeeper for privileged groups, but when multiple sysadmins or other IT staff have access to manipulate group membership, some additional mechanisms are needed to ensure compliance with company policy. We’ll look at how UpGuard monitors Windows groups and how it can help organizations minimize the risks they can pose.

The Scenario
The CTO of your company has mandated that only two accounts are allowed in the Administrators group of any company server, a local account called scriptrock and a domain account for Rob Sysadmin. You must find out if any servers have unauthorized users in that group, and be notified if the groups are changed at some later point in time. To accomplish this, we’re going to build a policy in UpGuard based on a server with the configuration we want and then apply it to the rest of our servers.

We’re responsible for about 80 Windows member servers. All of these servers except domain controllers have a local Administrators group and all of them must comply to the new policy the CTO has issued. The first thing we’ll want to do is get a server that we know has the Administrators group configured correctly. Once we have the server we want, we’ll scan it in UpGuard and check out the details under Groups > Administrators.

The Administrators group scan

As we can see, there are only two members in the group: scriptrock and Rob Sysadmin, the two users authorized by the CTO. We’re going to build a policy from this setting by right clicking on Administrators and choosing Add to policy. Then we add this to a new policy in  our Windows Servers node group, a dynamic node group based on operating system.

Creating the policy

Request a Free Demo

Unauthorized Accounts in the Group

Our source server passes with flying colors, of course, but if we navigate to the policy itself and run a report, we can see that we have a failure. This means one of our servers has an unauthorized Administrators group configuration. If we drill down into the failure, it takes us to that server’s info, where we can see that in addition to the two authorized accounts, someone has added Jeff Manager to the group as well.

One server has failed the policy

This can happen when an employee takes a shortcut around security, whether through a friendly sysadmin or a de facto “exception to the rule” sanctioned by IT managers. Or perhaps he was granted “full access” during an emergency and that access was never revoked.  However it happened, it defeats the purpose of having an access policy in the first place, or rather, it is precisely because of these ad hoc allowances that having an access policy and the visibility to enforce it is so important. In our scenario, it would be necessary to remove Jeff Manager from the Administrators group, but we would also try to help him do whatever part of his job it is he had admin access for, but without lowering resiliency.

Failure details: Jeff Manager was added to the group.

Back in UpGuard, we can now be notified whenever a server fails this policy. If someone is added or removed down the line, we’ll know about it. We can also modify this policy if necessary to change allowed members or monitor additional groups. We can also monitor users, for instance to verify that a built-in account is disabled on all of our servers. It’s one thing to write an access policy down on paper and tell people to follow it. It’s another to make that policy executable and fully automated.

Wrap-Up
Monitoring Windows groups is a small but important task that can fall through the cracks during normal operations. Usually a failure of an access policy wouldn’t be discovered until an incident had occurred and someone was performing forensics. In our scenario, the CTO might ask why Jeff Manager had admin access on the server, if data from that server were compromised. Even if Jeff didn’t have anything to do with the breach, the extraneous access would be seen as an example of the server’s vulnerability. Following the principle of least privilege and finding solutions for people’s problems that don’t involve giving them admin or root access can be more difficult up front, but it’s one of the most important methods of minimizing cyber risk. UpGuard can help you with this and more. Find out how here:

Request a Free Demo

More Articles

UpGuard 101: Managing IIS Server Configs

One of the best out-of-the-box features of UpGuard is the ability to build a policy from one configuration and apply that policy to other nodes that should match it.
Read Article >

Top 9 Ways To Improve Mac OS X Security

We're a couple months into 2016 and Apple has already issued major security updates for OS X and iOS.
Read Article >

Understanding Risk in the 21st Century

And as we enter 2016, the risk of data breaches in particular threatens to hamper business innovation.
Read Article >

Share this post: