Focus: Microsoft Infrastructure Administration, Active Directory, PowerShell, Group Administration, Identity Automation
Technology: Windows Server 2025 Standard Evaluation | Oracle VirtualBox | Windows PowerShell 5.1 | Active Directory Domain Services (AD DS)
Domain: Microsoft Infrastructure Administration | Identity and Access Management | Enterprise Security Foundations
Objective
Following the Active Directory user-administration work from the previous laboratory, this exercise extended identity administration into Active Directory security-group management and controlled PowerShell automation.
The laboratory focused on creating, validating, managing and deleting Active Directory security groups, while demonstrating how group membership can be used to represent access relationships between identities.
The objectives were to:
- Administer Active Directory security groups with PowerShell.
- Create and inspect security groups.
- Configure group scope and category.
- Add users to security groups.
- Validate group membership.
- Implement precondition checks.
- Automate group administration with PowerShell.
- Use controlled test objects rather than modifying unnecessary production-like objects.
- Validate administrative actions through post-operation checks.
- Independently verify the resulting Active Directory state.
- Safely remove temporary laboratory objects after testing.
This laboratory therefore extends the previous progression from user administration into group-based identity and access management.
Environment Overview
Platform: Oracle VirtualBox
Operating System: Windows Server 2025 Standard Evaluation
Administration Method: Windows PowerShell 5.1
Active Directory Domain: corp.lab
Server: WIN-URRN4NJRE9I
Phase: Phase 2 — Microsoft Infrastructure Administration Foundations
Active Directory Group Administration
The laboratory began by examining an existing Active Directory security group and its membership.
The Lab-IT-Support group was queried using:
Get-ADGroupMember-Identity"Lab-IT-Support"|Select-ObjectName,SamAccountName,ObjectClass
The resulting membership confirmed that:
Lab Automation User01labauto01user
was a member of the group.
The associated user account was independently validated as existing and enabled.
This demonstrated an important identity-management relationship:
User → Group → Access
Rather than assigning permissions individually to users, security groups provide a mechanism for organising identities into administrative or access-control boundaries.
Controlled Group Creation
A temporary security group was created specifically for controlled deletion testing:
Lab-Temp-Delete
The group was configured as:
- Group category: Security
- Group scope: Global
- Description: Temporary laboratory group for controlled deletion testing
After creation, the group was queried again to confirm its properties and distinguished name.
The group was then removed and its absence independently verified.
This demonstrated a complete administrative lifecycle:
Create → Validate → Delete → Verify
The temporary object provided a safe way to test destructive administration without unnecessarily modifying an existing group.
PowerShell Group Automation
The main automation exercise used:
Lab-IT-Automation
as a controlled test group.
The PowerShell workflow implemented:
Validate Active Directory domain
↓
Validate target user
↓
Confirm target group does not already exist
↓
Create security group
↓
Add controlled user
↓
Validate group membership
↓
Perform final state verification
↓
Delete test group
↓
Independently verify deletion
This extended the state-based automation methodology introduced in the previous laboratory.
Precondition Validation
Before making changes, the automation established that the expected environment and target objects existed in the required state.
The script validated:
- the Active Directory domain was
corp.lab - the target user
labauto01existed - the target user was enabled
- the target group did not already exist
If the expected environment was not detected, the workflow was designed to stop rather than continue against an unexpected state.
This creates an important administrative control:
Do not perform a change until the required preconditions are satisfied.
Security Group Creation
The automation created the group using PowerShell:
New-ADGroup
The group was configured as a Security group with Global scope.
The resulting object was then retrieved from Active Directory and its properties inspected.
The final group was confirmed as:
Name : Lab-IT-AutomationSamAccountName : Lab-IT-AutomationGroupCategory : SecurityGroupScope : GlobalDistinguishedName : CN=Lab-IT-Automation,CN=Users,DC=corp,DC=lab
This demonstrated that successful command execution was followed by verification of the actual directory object.
Group Membership Management
The controlled automation then added:
labauto01
to the newly created group.
Membership was retrieved using:
Get-ADGroupMember
The resulting membership confirmed:
Name : Lab Automation User01SamAccountName : labauto01ObjectClass : user
The automation explicitly checked that the expected user was present in the resulting membership collection.
This established another state-management pattern:
Add membership → Query membership → Confirm expected member
Validation and Error Handling
The automation used explicit error handling with:
-ErrorActionStop
This ensured that critical Active Directory failures would stop the workflow rather than allowing subsequent operations to continue against an unexpected state.
The workflow also distinguished between:
Command execution
and
Desired directory state
For example, the group was not considered successfully configured simply because New-ADGroup completed without a terminating error.
The group was subsequently queried and its membership independently examined.
This reinforced the principle:
Successful execution is not the same as successful state.
Destructive Operation Testing
The laboratory deliberately included deletion testing.
The temporary automation group was removed with:
Remove-ADGroup-Identity"Lab-IT-Automation"-Confirm:$false-ErrorActionStop
The deletion was then independently tested by querying Active Directory for the group.
The resulting ADIdentityNotFoundException demonstrated that the object could no longer be resolved in the domain.
The same methodology was previously applied to the dedicated Lab-Temp-Delete test group.
This provided practical experience with an important administrative principle:
Destructive operations require verification just as creation operations do.
Independent Final Verification
After the automation and cleanup operations, the resulting Active Directory state was independently queried.
The final validation confirmed:
UserExists : TrueUserEnabled : TrueSupportGroupExists : TrueLabAuto01Member : TrueAutomationGroupExists : False
This demonstrated that:
- the laboratory user still existed
- the user remained enabled
- the existing support group remained present
- the user remained a member of the intended support group
- the temporary automation group had been removed
The final state therefore matched the expected post-laboratory condition.
Automation Safety
The laboratory incorporated several safeguards into the automation workflow:
- Expected-domain validation.
- Target-user existence validation.
- Target-user enabled-state validation.
- Existing-group detection.
- Controlled test-object creation.
- Explicit error handling.
- Post-operation membership validation.
- Final-state verification.
- Controlled deletion of temporary objects.
The resulting administrative control model was:
Precondition
↓
Controlled action
↓
Post-condition validation
↓
Cleanup
↓
Independent verification
This is particularly important for group administration because group membership can influence access to systems and resources.
Security Perspective
Active Directory groups are an important component of identity and access management.
A user may have no direct permission on a resource but inherit access through group membership.
Therefore, seemingly simple operations such as:
- creating a security group
- adding a user
- removing a user
- deleting a group
can have security consequences.
The laboratory therefore demonstrated why group administration should be treated as an access-control operation rather than merely an organisational task.
The principle is:
Group membership can represent effective access.
This becomes increasingly significant when progressing towards:
- privileged groups
- role-based access control
- Microsoft Entra ID groups
- access reviews
- privileged identity management
- identity governance
- identity-focused detection engineering
From User Administration to Group-Based Access Control
The progression from the previous laboratory can now be viewed as:
Active Directory infrastructure
↓
User administration
↓
Group administration
↓
Group-based access control
↓
Identity lifecycle management
↓
Hybrid Identity
↓
Microsoft Entra ID
↓
Identity Security
↓
Detection Engineering
The technical mechanisms differ between on-premises Active Directory and cloud identity platforms, but the underlying concepts remain closely related.
Identities belong to groups.
Groups can represent roles or access boundaries.
Changes to those relationships can alter effective access.
Therefore, group membership is an important security signal as well as an administrative object.
Key Takeaway
The main lesson from this laboratory was that Active Directory group administration is fundamentally another state-management problem.
A robust administrative workflow should establish:
- What environment is being modified.
- What objects should already exist.
- What objects should not already exist.
- What change should be performed.
- What membership or configuration should result.
- What should happen if an unexpected condition occurs.
- How the resulting state will be verified.
- How temporary test objects will be safely removed.
The resulting methodology can be summarised as:
Establish precondition
↓
Perform controlled change
↓
Verify post-condition
↓
Clean up
↓
Independently confirm final state
This provides a practical foundation for more advanced identity and access-control automation.
Evidence
The complete PowerShell commands, automation workflow, validation logic and execution evidence are documented in the laboratory repository.
GitHub laboratory documentation:
2.5 Active Directory Group Administration & Automation
The repository contains the technical implementation and evidence demonstrating group creation, membership administration, validation, deletion and independent final-state verification.
Skills Demonstrated
- Active Directory group administration
- Windows PowerShell 5.1
- Security-group creation
- Global group configuration
- Group membership management
- User-to-group relationship validation
- PowerShell automation
- Conditional logic
- Error handling
- Precondition validation
- Post-condition validation
- Independent verification
- Controlled destructive testing
- Administrative cleanup
- Identity and access-control fundamentals
- Evidence-based technical documentation
Portfolio Context
This laboratory forms part of:
Phase 2 — Microsoft Infrastructure Administration Foundations
Learning progression:
2.1 Windows Server Administration Foundations
↓
2.2 Windows Server Administration Fundamentals
↓
2.3 Active Directory Administration Fundamentals
↓
2.4 Active Directory User Administration Fundamentals
↓
2.5 Active Directory Group Administration Fundamentals
↓
Hybrid Identity
↓
Microsoft Entra ID
↓
Azure Administration
↓
Identity Security
↓
Detection Engineering
This phase progressively develops the infrastructure and identity knowledge required for:
- Windows Server administration
- Active Directory administration
- User and group lifecycle management
- Role and access management
- Hybrid identity
- Microsoft Entra ID
- Azure administration
- Identity security
- Detection Engineering
Laboratory 2.5 therefore extends the practical identity-administration layer from individual user objects into group-based access management, providing a foundation for more advanced identity security and access-control work.