AD groups for developer access control

For developer teams working in an enterprise Windows server environment, it is customary to use Active Directory groups for access control to systems and services. In our scenario, every time onboarding starts for a new developer, this results in a big bunch of IT maintenance orders to add new users to the proper groups. Over time, the access profiles for each developer tends to deviate, making it very time consuming to figure out what that new resource should actually have.

To resolve this, we decided to introduce a couple of team roles (implemented as AD groups):

• for the regular developer account
• for the administrative account (used for RDP of servers and similar tasks)

So far so good, but how do you figure out which groups this new role is assigned to?

The net command

To query which groups the user adUser belongs to on the domain level, one can use

net user /domain adUser

This was helpful to figure out which groups needs to be added to the new roles. But beware, the group names are truncated!

To find full names of truncated group names, one can use

net group /domain

which lists all groups in the domain without truncation. If there are multiple possible matches, one can proceed with the next command to find the correct group.

To query which users belong to the group adGroup, one can use

new group /domain adGroup

This prints out all users that are members of that group. This was also helpful when in doubt if a certain group should apply to all the devs in the team or not. However, this command does not show members that are groups!

Powershell to the rescue

The following powershell will list all AD groups that contain members which are AD groups. If there are multiple group members, they will all be printed with a comma separator.

Putting all of these together, we were able to properly specify and validate our team roles.

Why not the Domain Controller?

Naturally, the above use case could also be resolved directly on the domain controller, where group members can be examined directly with a GUI. But most developers are not allowed access to the DC, so I find it convenient to be able to get the required info through alternate methods.