UpGuard 101: Verifying Windows Groups

Posted by UpGuard

UpGuard 101: Verifying Windows Groups

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 security monitoring. 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. This week we’ll look at how UpGuard monitors Windows groups and how it can help organizations maintain consistent security.

The Scenario
The CTO of your company has mandated that only two accounts are allowed in the Administrators group of any company server. You must find out if any servers currently have unauthorized users in that group, and be notified if the groups are changed at some later point in time. This part should sound familiar: 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 have a The Administrators group scanlocal 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.

As we can see, there are only two members in the group: scriptrock and Rob Sysadmin,Creating the policy 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. We’re going to be adding this to a new policy in  our Windows Servers node group, a dynamic node group based on operating system.

Unauthorized Accounts in the Group

One server has failed the policyOur source server passes with flying colors, of course, but if we navigate to the policy itself and run a report (generating the report data if necessary) 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 will take 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.

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.  Either way, 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 Failure details: Jeff Manager was added to the group.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.

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 have that policy actively monitored and enforced.

 
 
 
 
 
 
 
2:12
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

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 keeping your data secure. UpGuard can help you with this and more, and the first ten nodes are free. 

Schedule an UpGuard demo right now

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 >

Topics: security, server management, Windows, UpGuard101, how-to

Blog

  Featured Download – The DevOps Toolchain eBook
UpGuard customers