Active Directory | PowerShell | Identity Administration | Automation | Enterprise Security
Overview
Following the deployment of Active Directory Domain Services in the previous laboratory, the next step was to move from building the identity infrastructure to administering identities within it.
This laboratory focused on Active Directory user administration using Windows PowerShell 5.1, with particular emphasis on account lifecycle operations, password management, account-state control and controlled automation.
The exercise began with individual administrative tasks performed manually. These operations were then translated into a repeatable PowerShell workflow incorporating precondition checks, secure password handling, error handling and post-operation validation.
The objective was therefore not simply to learn individual Active Directory commands.
It was to understand how identity administration can be transformed into a controlled, repeatable and verifiable process.
The complete PowerShell commands, automation workflow and validation evidence are available in the accompanying GitHub repository:
Objectives
The laboratory objectives were to:
- Administer Active Directory users with PowerShell.
- Reset and manage user passwords.
- Configure password-change requirements.
- Disable and enable user accounts.
- Validate account state programmatically.
- Develop a controlled PowerShell automation workflow.
- Implement precondition checks and failure handling.
- Use secure password input.
- Validate the resulting Active Directory state independently.
- Test PowerShell syntax.
- Document the administration process as reproducible technical evidence.
The complete implementation and command-level evidence are maintained in GitHub rather than duplicated throughout this article.
Environment
The laboratory continued using the Windows Server infrastructure established during the previous Active Directory deployment.
| 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 server was already operating as a Domain Controller for the corp.lab Active Directory domain.
The environment was therefore ready for the next stage: administration of identities within the newly established directory.
From Infrastructure Deployment to Identity Administration
The previous laboratory established the infrastructure required for enterprise identity.
This laboratory changed the focus from:
How do we build Active Directory?
to:
How do we administer identities within Active Directory safely and consistently?
This distinction is important.
A functioning Domain Controller is only the beginning of identity administration. Enterprise environments require continuous management of:
- user accounts
- passwords
- account states
- access permissions
- group memberships
- onboarding
- offboarding
- privileged identities
- identity lifecycle events
PowerShell provides an effective interface for performing these operations consistently.
Manual Active Directory User Administration
The first stage involved performing common user administration operations manually.
A dedicated laboratory user was used to demonstrate the basic workflow.
The account was subjected to:
- Password configuration.
- Password-state validation.
- Password-change-at-logon configuration.
- Account disablement.
- Account-state validation.
One useful observation occurred during password configuration.
An initial password was rejected because it did not satisfy the domain’s password requirements.
Rather than treating this simply as an error, the result provided evidence that the Active Directory password policy was being enforced correctly.
This illustrates an important administrative principle:
An error can also be evidence about the state of the system.
The complete commands and outputs are documented in the GitHub repository.
Account State Management
The laboratory then demonstrated the relationship between account configuration and account state.
PowerShell was used to determine whether the account was:
- enabled or disabled
- subject to a password change
- configured with an expiring password
- configured with a non-expiring password
The account was subsequently disabled and the resulting state independently queried.
This established a simple but important administration pattern:
Change → Query → Verify
Instead of assuming that a command succeeded, the resulting directory object was queried again to confirm its actual state.
This state-based approach becomes increasingly important when administrative operations are automated.
Why Automation?
Manual administration is appropriate for learning individual operations and for occasional administrative tasks.
It becomes less attractive when the same process has to be repeated across many identities.
Repetition introduces opportunities for:
- inconsistent execution
- human error
- incomplete validation
- accidental modification of the wrong account
- poor auditability
- reduced scalability
The laboratory therefore moved from individual commands towards a controlled automation workflow.
The principle was:
Define the expected state → perform the action → validate the resulting state.
The complete automation implementation is available in the GitHub evidence repository.
Controlled Automation
A separate laboratory account was used as the automation target.
This was deliberate.
The existing manually administered account was not reused for the automated test. Instead, a dedicated account was created specifically for testing the workflow.
This provided isolation between:
Manual administration
and
Automated administration
The automation workflow then performed a controlled sequence:
Validate domain
↓
Check whether the target account exists
↓
Stop if it already exists
↓
Request the password securely
↓
Create the account
↓
Validate the initial state
↓
Disable the account
↓
Validate the disabled state
↓
Re-enable the account
↓
Validate the enabled state
↓
Perform independent final validation
This approach introduced a basic safety boundary around the automation.
Precondition and Post-Condition Validation
One of the most important lessons from this laboratory was that automation should not simply execute commands sequentially.
It should understand the state of the environment before and after an operation.
For example, before creating the test account, the script checked whether the account already existed.
If it did, the script stopped rather than modifying the existing identity.
Similarly, after disabling the account, the script queried Active Directory and verified that:
Enabled = False
The account was then re-enabled and the resulting state checked again:
Enabled = True
This converts automation from a sequence of commands into a state-aware administrative process.
Secure Password Handling
The automation also demonstrated an important security consideration.
The password was requested interactively using PowerShell’s secure-string input mechanism rather than being hard-coded into the script.
This meant that the credential was not stored in:
- the PowerShell script
- the GitHub repository
- the documented evidence
This is a basic but essential principle when developing identity automation.
Automation should improve consistency without creating new credential-management problems.
Error Handling
The PowerShell workflow also incorporated explicit error handling.
Active Directory operations were configured to stop execution when critical errors occurred.
This prevents a dangerous situation in which an earlier operation fails but the script continues executing subsequent actions under the assumption that the environment is in the expected state.
The automation therefore followed the principle:
Failure should be visible, not silently ignored.
This is particularly important for identity administration because an incorrect account state can have direct security and operational consequences.
Independent Verification
After the automated workflow completed, the resulting account was queried independently.
This was intentionally separate from the validation logic contained within the automation itself.
The final account state confirmed that the test identity:
- existed in Active Directory
- was enabled
- required a password change
- was not configured with a non-expiring password
This provided a second verification path.
The distinction is important:
A script reporting success is not, by itself, proof that the intended directory state exists.
Independent verification reduces the risk of validating the automation’s assumptions rather than validating the actual environment.
The complete validation output is available in the GitHub repository.
PowerShell Syntax Validation
The saved automation script was also tested using the PowerShell language parser.
The parser reported no syntax errors in the saved .ps1 file.
An interesting troubleshooting event occurred during the laboratory when an else statement was entered incorrectly at the interactive PowerShell prompt.
The resulting error initially looked like a scripting problem, but further investigation demonstrated that the issue was caused by entering the if and else blocks as separate interactive submissions.
The saved script itself passed parser validation.
This provided a useful reminder that:
Interactive PowerShell behaviour and execution of a saved .ps1 script are not always equivalent.
Troubleshooting therefore required distinguishing between an actual script defect and an issue with how commands were entered.
Security Perspective
Although this laboratory concentrated on user administration, the security implications are significant.
User accounts represent one of the most important control points within an enterprise identity system.
Operations such as:
- creating accounts
- disabling accounts
- resetting passwords
- enforcing password changes
- managing privileged identities
directly affect organisational security.
Automation can strengthen these processes by making them more consistent.
However, automation also increases potential impact.
A manual mistake may affect one identity.
A poorly designed automation workflow can potentially affect hundreds or thousands.
Therefore:
More automation requires stronger validation, not weaker validation.
This principle becomes increasingly relevant when progressing towards enterprise identity platforms such as Microsoft Entra ID and Microsoft Graph.
From Active Directory Administration to Identity Engineering
This laboratory also helped connect traditional systems administration with the longer-term identity and security workflow.
The progression now looks increasingly like:
Windows Server
↓
Active Directory
↓
User Administration
↓
PowerShell Automation
↓
Identity Lifecycle Management
↓
Hybrid Identity
↓
Microsoft Entra ID
↓
Identity Security
↓
Detection Engineering
Understanding the mechanics of user administration at the Active Directory level provides useful context for more modern identity platforms.
The underlying concepts remain familiar:
- identities have states
- access must be controlled
- changes should be authorised
- administrative actions should be auditable
- automation should be validated
- failures should be handled safely
The technology changes, but many of the administrative principles persist.
Key Learning Outcome
The most important lesson from this laboratory was that identity administration is fundamentally a state-management problem.
A useful administrative workflow is not simply:
Run command → assume success
It is:
Establish precondition
↓
Perform controlled action
↓
Verify post-condition
↓
Handle failure
↓
Independently confirm final state
This methodology provides a stronger foundation for future work involving identity lifecycle management, privileged access, access reviews and security automation.
Conclusion
This laboratory extended the Active Directory environment created in the previous exercise into practical user administration and PowerShell-based automation.
The work demonstrated how common identity-management operations can first be performed manually and then translated into a controlled automation workflow.
The laboratory covered:
- Active Directory user administration
- password management
- account-state management
- secure password handling
- conditional logic
- error handling
- precondition validation
- post-operation validation
- independent verification
- PowerShell syntax validation
- controlled automation
More importantly, the exercise reinforced a methodology that extends beyond Windows Server:
Never assume that an administrative action produced the intended state. Verify it.
The complete commands, PowerShell automation, execution evidence and validation results are maintained in the accompanying GitHub repository:
View the complete Lab 2.4 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
↓
Active Directory User Administration
↓
PowerShell Automation
↓
Hybrid Identity
↓
Microsoft Entra ID
↓
Azure Administration
↓
Identity Security
↓
Detection Engineering
Skills Demonstrated
- Windows Server administration
- Active Directory user administration
- Windows PowerShell 5.1
- Password management
- Account lifecycle administration
- Account-state validation
- PowerShell automation
- Conditional logic
- Error handling
- Secure credential input
- Precondition validation
- Post-condition validation
- Independent verification
- Troubleshooting
- Evidence-based administration
- Identity security fundamentals
- Controlled automation