13 – Microsoft Active Directory Group Administration: PowerShell-Based Access Control and Automation

Overview

Following the Active Directory user-administration work in the previous laboratory, this exercise moved to another fundamental component of enterprise identity management: Active Directory group administration.

Groups provide an important abstraction between an identity and the resources that identity is authorised to access.

Instead of assigning permissions individually to every user, organisations can use groups to represent access requirements, administrative roles and security boundaries.

This laboratory therefore focused on administering Active Directory security groups with Windows PowerShell 5.1, while continuing the evidence-based methodology established in the previous exercises.

The work covered:

Active Directory security-group classification
group scopes
group membership
direct versus nested membership
controlled group creation
membership modification
controlled deletion
membership analysis
PowerShell automation
precondition validation
post-operation validation
independent verification
controlled cleanup

The complete commands, PowerShell output and validation evidence are maintained in the accompanying GitHub repository:

View the complete Lab 2.5 technical evidence on GitHub

Objectives

The laboratory objectives were to:

Inspect existing Active Directory security groups.
Distinguish security groups from distribution groups.
Examine Active Directory group scopes.
Inspect existing group membership.
Create and validate a controlled security group.
Add and remove a user from a group.
Independently validate group membership.
Investigate nested group membership.
Analyse group membership counts programmatically.
Safely test group deletion.
Develop a controlled PowerShell group-administration workflow.
Implement precondition checks and error handling.
Validate the resulting Active Directory state independently.
Clean up temporary laboratory objects.

The complete implementation and command-level evidence are maintained in GitHub rather than reproduced throughout this article.

Environment

The laboratory continued using the Windows Server infrastructure established during the previous Active Directory exercises.

Component	Configuration
Virtualisation Platform	Oracle VirtualBox
Host Operating System	Windows 11
Guest Operating System	Windows Server 2025 Standard Evaluation
Administration Method	Windows PowerShell 5.1
Server Name	WIN-URRN4NJRE9I
Active Directory Domain	corp.lab

The PowerShell environment, Active Directory module, domain and administrative security context were validated before making changes.

Windows PowerShell 5.1 was confirmed inside the Windows Server virtual machine, and the session was operating under the expected corp\administrator context.

Understanding Active Directory Groups

The first stage was to examine the existing Active Directory group structure.

Active Directory groups can be broadly divided into:

Security Groups

and

Distribution Groups

Security groups can participate in access-control decisions, whereas distribution groups are primarily intended for communication and mail distribution.

The laboratory queried the domain for distribution groups and found none.

The existing environment therefore consisted predominantly of security groups, including built-in groups such as:

Domain Users
Domain Admins
Remote Desktop Users
Administrators
Enterprise Admins

alongside the groups created during the laboratory work.

This provided practical exposure to the group structures that support Windows authorisation and administration.

Group Scope

The laboratory also examined the different Active Directory group scopes present in the environment:

Global
Domain Local
Universal

The scope of a group affects how it can be used within the Active Directory environment and forms part of the design of group-based access control.

The controlled groups created during the laboratory were deliberately configured as:

Global Security Groups

This provided a consistent and predictable test environment.

Inspecting Domain Users

The built-in Domain Users group was inspected before creating new laboratory relationships.

The membership query confirmed that the existing laboratory identities, including:

labuser01

and

labauto01

were members of the group.

The properties of Domain Users were also queried, confirming that it was a Global Security Group located in the expected corp.lab directory structure.

This provided a useful baseline for understanding how user identities were already represented within the directory.

Creating a Controlled Security Group

The first dedicated group created for the exercise was:

Lab-IT-Support

Before creation, PowerShell was used to confirm that the group did not already exist.

This established an explicit precondition:

The target group must not already exist.

The group was then created as a Global Security Group and independently queried to confirm its properties.

This followed the administrative pattern:

Check → Change → Query → Verify

Rather than assuming that successful execution meant that the desired state existed, the resulting directory object was queried directly.

Group Membership Administration

The existing laboratory identity:

labauto01

was then validated before being added to the new group.

The membership operation produced the relationship:

Lab-IT-Support → labauto01

The group was queried directly to verify the relationship.

The user’s memberships were then queried independently using Get-ADPrincipalGroupMembership.

This produced a second validation path:

Who belongs to the group?

and:

Which groups does the user belong to?

Both queries confirmed the same relationship.

This is stronger evidence than relying on only one direction of the relationship.

Testing Membership Removal and Restoration

The laboratory deliberately tested the inverse operation as well.

labauto01 was removed from Lab-IT-Support.

The group was queried again and no members were returned.

The user was then re-added and the resulting membership was independently validated.

The complete state transition was therefore:

Add → Verify → Remove → Verify → Restore → Verify

This demonstrated both sides of the membership operation rather than only testing successful creation.

Direct Versus Nested Membership

The laboratory also investigated whether Lab-IT-Support contained other groups.

No nested groups were found.

The resulting structure was therefore:

Lab-IT-Support

↓

labauto01

rather than:

Lab-IT-Support

↓

Another Group

↓

Users

This distinction is important when analysing effective access.

In a larger Active Directory environment, nested groups can create considerably more complex authorisation relationships.

Understanding those relationships is particularly relevant to identity-security investigations, where the question may not simply be:

“Is this user a member of this group?”

but rather:

“Why does this identity ultimately have this access?”

Programmatic Group Analysis

PowerShell was then used to enumerate security groups and calculate their direct member counts.

This provided a programmatic inventory of the directory’s group structure.

The analysis identified both groups containing members and groups with zero direct members.

An important observation was that an empty group is not automatically evidence of a configuration problem.

Some built-in Active Directory groups legitimately have no direct members in a particular environment.

This is a useful distinction when performing automated directory analysis: the presence of an unusual-looking state does not necessarily mean that the state is incorrect.

Controlled Deletion Testing

A separate temporary group was created specifically to test deletion:

Lab-Temp-Delete

The purpose was to test the complete lifecycle of a disposable directory object:

Create

↓

Validate

↓

Delete

↓

Validate deletion

The group was created and its properties independently confirmed.

It was then deleted using PowerShell.

A subsequent query confirmed that the object could no longer be found.

This allowed a potentially destructive operation to be tested without targeting an important built-in Active Directory group.

PowerShell Group Automation

The final stage translated the group-administration workflow into a controlled PowerShell automation process.

A second dedicated temporary group was used:

Lab-IT-Automation

The automation first established several preconditions:

the expected domain was corp.lab
labauto01 existed
labauto01 was enabled
Lab-IT-Automation did not already exist

Only after these conditions were satisfied did the automation create the group.

It then:

Created the security group.
Added labauto01.
Validated the membership.
Retrieved the resulting group state.
Reported a successful validation.

The execution produced:

LAB 2.5 GROUP AUTOMATION: PASSED

The complete automation workflow is documented in the GitHub repository.

Interpreting Expected Errors

An interesting point occurred during the automation precondition check.

When PowerShell attempted to retrieve Lab-IT-Automation before it existed, an object-not-found message was displayed.

This was expected.

The command used -ErrorAction SilentlyContinue, and the resulting $null state was interpreted as evidence that the target group did not exist.

Therefore:

Object not found

did not mean:

Automation failed

It meant:

The required precondition was satisfied.

This was a useful practical demonstration of why administrators must interpret command output in the context of the expected system state rather than treating every error message as a failure.

Independent Verification and Cleanup

After the automation reported success, the resulting group was independently retrieved.

The final state confirmed that:

Lab-IT-Automation existed.
It was a Security Group.
It was a Global Group.
labauto01 was a direct member.

The temporary automation group was then deleted.

The directory was queried again afterwards.

The final independent validation confirmed:

labauto01 existed.
labauto01 remained enabled.
Lab-IT-Support existed.
labauto01 remained a member of Lab-IT-Support.
Lab-IT-Automation no longer existed.

The other temporary test object, Lab-Temp-Delete, had also already been removed.

The laboratory therefore ended in a controlled state without unnecessary temporary automation objects remaining.

Evidence-Based Administration

One deliberate design decision throughout this laboratory was to use PowerShell output as the primary evidence.

No separate CSV collection or large set of screenshots was required.

The repository instead records:

the command used
the relevant PowerShell output
the interpretation of that output
the validation performed
the resulting state

This keeps the repository reproducible without creating unnecessary evidence artefacts.

The principle is straightforward:

The PowerShell output is the evidence.

The documentation explains why that evidence matters.

Security Perspective

The central security lesson from this laboratory is that group administration is access-control administration.

A simplified relationship is:

Identity

↓

Group Membership

↓

Authorisation

↓

Resource

Changing group membership can therefore change what an identity is authorised to access.

This becomes particularly important when groups are:

privileged
nested
associated with sensitive resources
used for administrative delegation
modified through automation

The laboratory therefore reinforced a principle already established in the previous exercise:

More automation requires stronger validation, not weaker validation.

A manual mistake may affect one identity.

An incorrectly designed automated process can potentially affect many identities or groups.

From Group Administration to Identity Security

The progression from the previous laboratory is becoming increasingly relevant to identity-security work.

The sequence is now:

User Administration

↓

Group Administration

↓

Access Control

↓

Identity Lifecycle

↓

Privileged Access

↓

Identity Security

↓

Detection Engineering

Understanding Active Directory at this level provides a practical foundation for later identity-focused security work.

Many identity investigations eventually become relationship-analysis problems:

Which groups is this identity a member of?
Is the membership direct or nested?
Which group provides the access?
Was the membership change authorised?
When did the relationship change?
Which other identities could be affected?

The ability to answer those questions begins with understanding how the underlying directory objects actually work.

Key Learning Outcome

The most important lesson from this laboratory was:

Group administration is fundamentally state management applied to access control.

The workflow repeatedly followed:

Establish the expected state

↓

Perform the controlled action

↓

Query the resulting state

↓

Compare it with the expected state

↓

Independently verify where appropriate

↓

Clean up temporary objects

↓

Verify the final environment

This is more valuable than simply memorising Active Directory cmdlets because the methodology can be applied to broader infrastructure and identity-management tasks.

Conclusion

This laboratory extended the Active Directory work from individual user administration into group-based access control and PowerShell automation.

The work demonstrated practical administration of:

security groups
group scopes
group membership
membership removal and restoration
nested-group analysis
programmatic group analysis
controlled deletion
PowerShell automation
precondition validation
post-operation validation
independent verification
controlled cleanup

More importantly, the exercise shifted the focus from individual directory objects towards the relationships between identities, groups and authorisation.

That distinction becomes increasingly important when progressing from traditional Windows administration towards hybrid identity, Microsoft Entra ID and identity security.

The core principle remains simple:

Do not assume that an administrative command produced the intended state. Query it, validate it and verify it.

The complete technical evidence for Lab 2.5 is available in the accompanying GitHub repository:

View the complete Lab 2.5 technical evidence on GitHub

Repository Context

This laboratory forms part of:

Phase 2 — Microsoft Infrastructure Administration Foundations

Portfolio progression:

Windows Infrastructure

↓

Windows Administration

↓

Active Directory

↓