GDPR and IT Operations Pt. 2 – Groups

Part 1: What Users in Your Network Has Access to Information

Part 3: IT Documentation and Access Control

Requirements for this tutorial

• The environment in focus for this analysis is a Microsoft environment set up with standard solutions for access control
• In order to follow this tutorial you will need a vScope Directory subscription or to be running a trial license
• The screenshots in this tutorial are from a vScope with all products licensed

Pt. 2 – Groups

Now that we have a clear view of our user accounts, after completing some checks in Pt.1 of this series, we’ll be moving on to having a look at the resource type Groups. Just like with user accounts, groups come in different types. In fact, they come in even more types than user accounts do, and the different types can be mixed through nesting. As an admin, you of course know this. And you also know just how difficult it can be to get a clear view of those group relations. This post will help you sort that out.

Just like with Pt. 1, hopefully this blog post will prove interesting to non vScope users as well, as it will give you some pointers on good practice and give you ideas on how to prepare for audits. While working with new resource types, the first sections of this text will be repeating some steps from Pt. 1. The latter part will be more advanced, trying to give you a picture of just how complicated access control can be.

Types of groups

In this blog post we are focusing on the group types used in what you might call a classic Microsoft environment set up for granting access. It deals mainly with different Active Directory groups (often referred to as domain groups), and local groups. There are others, of course. One important type is the ones built in to your different applications. Apart from that, you might be moving into more advanced set ups like JEA (Just Enough Administration). This post is intended to inspire you in regards to the things you can do to document access, and how vScope can help. So we are keeping it quite basic.

Group nesting

Different groups have different limitations as to what kind of objects can be members, and what resources they can give access to. The architecture behind groups and group nesting makes documenting access control a complicated task. The possibilities, very simply put, look something like this:

• Domain groups can include
  • Domain accounts in way of:
    • Direct membership
    • Through domain groups with nesting
  • Domain groups in way of:
    • Direct membership
    • Through other domain groups with nesting
• Local groups can include
  • Local accounts in way of:
    • Direct membership
    • Through local groups with nesting
  • Domain accounts in way of:
    • Direct membership
    • Through other domain groups with nesting
    • Through local groups with nesting
  • Local groups in way of:
    • Direct membership
    • Through other local groups with nesting
  • Domain groups in way of:
    • Direct membership
    • Through other domain groups with nesting
    • Through other local groups with nesting

The groups in your Active Directory have something called Group Scope built into them as well. Group Scope determines how/if groups can be nested across a forest. In the coming text, you will learn how to look that up in vScope. Domain groups can be further divided into two subtypes: Security Groups (granting access to data) and Distribution Groups (for distributing information).

Identifying groups

Just like with our users, we’ll be starting out with a fresh new table. This time, from Table Explorer, open up New Table and select the resource User Groups. There is a tag available for this resource, that you will recognize from our table on Users Accounts. That tag is Type. Let’s try that again. As you can see, User Groups are presented in domain- and local types too.

You might want to save three tables this time. One for local, one for domain, and one for a mixed environment showing both types. The former two are great to keep at hand for auditing, or for preparing some changes to the access set up of your environment. The mixed table will come in handy when trying to grasp the complete picture of you group nesting.

Start out looking at Domain Groups. Investigate your two subtypes Security Groups (granting access to data) and Distribution Groups (for distributing information). That information is found under the tag “Group Type”. We want to be looking at both here. Why not just Security Groups? Because we are looking at possible access to sensitive data. In everyday work, sensitive data is distributed in different ways, one of them being by email. Always keep more or less informal flows and processen in mind when security auditing!

Speaking of Email, try that tag* on your Security type Domain Groups. Any values in that field? Those Security Groups are mail enabled! A Security Group double acting as a Distribution Group is generally a bad idea. Why? Because, for example, all the staff receiving the “golf club weekly”-emails might end up granted access to the share where the administrator of the golf committee stores their personal contact data. Maybe not the worst example in the world, but still not high compliance. The effects can of course get even worse. You might want to make a note on creating separate groups for access and distribution in the cases you run into.

*Note Tag Email under resource type User Groups is available from release 3.3.1, planned release date 2018-04-12

Open up the tag “Managed by”. That will show you if any of the groups in your AD have been set up to be managed by someone outside of your standard team. You might want to pass results like these on to for example Human Resources or directly to a division manager, as it is likely impossible for IT to determine if the set up looks correct. Consider using Viewer-accounts to safely share information with parties outside of IT. This is also a great target for tracking! Build a tracker notifying you if the Managed By-field has changed values since the previous discovery.

Now let’s switch to a mixed view, showing both domain- and local groups. Have a look at the tag Description. This is another tag that will interest us in our analysis. The value of this field is imported from any groups Description field found both locally and in your Active Directory. Empty fields? It is a good idea to bring this to attention. The Description-field is a practical contributor to your documentation. Want to make some separate notes on top of the Description-field? Have a look at the property page of a group. Use the Note-field found there!

Tip#1 Any resource that you have allowed vScope to scan has it’s own property page. You can search for it using OmniSearch, or just right click it in Table Explorer and choose “Open in properties”. All property pages have Note fields.

Both Domain- and Local Groups have tags showing relationship by means of membership. We want to include those in our basic analysis:

• Group Members Count (this is the total number of groups that are direct members of the subject group)
• Group Members (these are the names of the direct group members of the subject group)
• Users Count (this is the total number of users that are direct members of the subject group)
• Users (these are the names of the user accounts that are direct members of the subject group)

Tip#2 vScope can show resources from different domains, as long as they are all part of the same forest. The tag Domain shows up under several resource types. When dealing with Users and User Groups, that tag will show you the domain name for accounts from Active Directory or the server name for local accounts.

If you are working with more than one domain, the tag Group Scope will be of importance to you. That tag tells you if a domain group is Universal, Global or Domain Local.  The group scope determines some of the possibilities for nesting. Consult this table on Microsoft TechNet, and determine if the group scope is set up correctly.

As you can see, we are on our way to obtaining a view of the group nesting laying grounds for access permissions across our environment!

Identifying group usage

One way to track changes to a group is by looking it it’s history either from Table Explorer or by simply checking the timeline on it’s property page. History and timeline will, among other things, provide you with a change log!

Groups not in use can’t really be disabled the same way accounts can be. To “disable” a group, you can try using some different options in combination, like removing it’s members and membership, moving it to a specific OU for archiving, and renaming it in some way according to your IT policy. Do you already have a OU in your AD for groups not in use? Filter them out in Table Explorer using the filter panel, and check their memberships. They should be empty.

Identifying groups granting elevated permissions

Basically, a user with elevated permissions is an account that is member of some sort of admin- or special access group. Identifying which groups grant elevated permissions can be more than a little tricky. The obvious ones are the different built in groups. We looked at one of those in Pt. 1 when we opened up the tag Domain Admin = True/False under the resource type User Accounts. Another example is the local Administrators found on servers.

Built in groups can be found both in Active Directory and locally on your servers. Standard members can vary, but for a local admin group they are very likely among others the local account Administrator and the domain group Domain Administrators, along with a few more like for example a domain group named “Workstation Administrators” (you might want to run through the members of that one, in case you are working with a software blacklist/whitelist and want to bring unwanted software to a minimum.).

Higher up in this text, groups built into apps are mentioned. Membership in those can be documented by starting from the inside out. What groups are members of the built in app groups? Look them up in vScope. Are those in turn local or domain groups? What do their memberships look like? Eventually, you will end up with a list of users. The same logic can be applied over and over again to track what users can access your systems. Start from the resource, work your way all the way back to the user accounts

Recap: Results of GDPR User Groups analysis

This text has given some pointers into different ways of approaching groups and access control in an audit situation. It has:

• Brought attention to different types of groups
• Mentioned some good practice
• Described ways of documenting using built in fields in AD, built in fields locally, and with help of vScope functionality

Sharing is caring! This guide will help you pass all this new information on to your colleagues!

In Pt. 3 of this GDPR series, we are going to be continuing along with access control, discussing different types of possibly sensitive data that are often handled directly by IT Operations, and how we can tag it and track it.

Read more

• Read more about vScope Directory on our product page, and give it a try yourself!
• Learn about documentation with vScope

Sign up for newsletter

Join our community and 1000+ IT professionals by signing up for blogs, news and business insight through our newsletter