Active Directory Password Incident Lab

Build an AWS Active Directory lab to diagnose and resolve password incidents.

Introduction

30 Second Summary

When someone cannot sign in at work, a quick password reset can leave the real cause untouched. Support staff need a safe place to reproduce the failure before they change a live employee account.

In this project, you will build a temporary two-server support lab on Amazon EC2. You will use Active Directory Domain Services to reproduce account lockouts, forgotten passwords, disabled accounts, and weak-password rejections through Windows graphical tools.

What You'll Build

Picture the locked-out user's Windows desktop finally opening after you diagnose the account from your domain controller.

By the end of this project, you'll have:

A working company domain lab where ordinary accounts can sign in to a separate Windows server through Windows App.
A repeatable help desk workflow in Active Directory Users and Computers for resolving lockouts, forgotten passwords, disabled accounts, and weak-password rejections.
A domain policy demo in Group Policy Management Console that demonstrates why a password reset can leave a locked user blocked.
Secret Mission: Apply a stricter fine-grained password policy to the Privileged Operators group. Verify that the policy governs Morgan's account.

Are there any prerequisites?

You'll need an Apple silicon Mac with internet access, an AWS account with billing enabled, and Windows App installed. All Windows work runs in AWS, so local Windows virtualization is not required.

Before We Start

This first checkpoint locks in the password incident you want to practise and why it matters for an infrastructure support role. Your learning goal gives the hands-on lab a clear purpose before any resources exist.

Launch the Windows Lab

Your password-incident goal needs two Windows Server 2025 machines that can communicate through a private network. The first server becomes the domain controller in the next step.

The second server gives each test user a separate place to attempt authentication. This separation makes every lockout visible from both the administrator view and the affected user's view.

You will host both machines with Amazon EC2. A dedicated security group limits Remote Desktop Protocol (RDP) access to your current public IP.

You will manage the launch through the AWS Management Console. You will prove that both servers are reachable through Windows App.

In this step, get ready to:

Launch two paid Windows Server instances in one default VPC and subnet.
Restrict RDP to your current public IP while allowing private communication between the servers.
Decrypt both local Administrator passwords and connect to each Windows desktop.

Create the first server and network boundary

An RSA key pair gives AWS a public key for the server. The downloaded .pem file contains the private key used to decrypt the local Administrator password.

This Lab Starts Billing

Launching these instances starts usage-based billing. You will review the regional estimate before creating each server.

EC2 charges continue while the instances remain in the running state.

The attached Amazon EBS volumes also incur storage charges.

The two public IPv4 addresses add usage charges while assigned. The cleanup section shows you how to stop or delete everything.

Your AWS account may request its usual verification during sign-in. This confirms that you control the billing-enabled account before paid resources are created.

Press Cmd+Space on your Mac to open Spotlight.
Type Safari into Spotlight.
Press Enter to open Safari.
Search for AWS Management Console in Safari.
Choose the official AWS result.
Sign in to your AWS account.
Complete any account verification that appears.
Select US East (N. Virginia) from the region selector.

Use the console search to open Amazon EC2.
Confirm that the console header still shows US East (N. Virginia).

You are signed in with the lab's region fixed. Every resource you create next stays together in the same regional EC2 environment.

Click Launch instance in the EC2 console.
Set the instance Name tag to AD-DC1.
Choose the latest AWS Windows Server 2025 Base image under Application and OS Images (Amazon Machine Image).
Select t3.medium under Instance type.
Start creating a new key pair under Key pair (login).
Enter a memorable lab key pair name: your lab key pair name.
Select RSA as the key pair type.
Select .pem as the private key file format.

Finish creating the key pair.
Confirm that the downloaded .pem file appears in Safari's downloads.

Protect the Private Key

Keep the downloaded .pem file on your Mac. Never share its contents or upload the file as evidence.

The file is required to decrypt both local Administrator passwords. Losing it blocks the password-retrieval workflow for these instances.

Keep the default VPC selected under Network settings.
Select one subnet from the default VPC.
Record the selected subnet: your selected default subnet.
Configure a new dedicated security group.
Name the security group AD-Lab-RDP.
Set its RDP inbound rule to TCP port 3389 with My IP as the source.

Keep the default gp3 root volume under Configure storage.
Review the region-specific estimate shown in the launch summary.
Click Launch instance.

Windows needs a short wait to complete its first boot. The instance is ready for the next configuration when its state changes to running.

Return to the EC2 instances list.
Wait until AD-DC1 shows the running state.
Open the EC2 security groups page.
Select AD-Lab-RDP.
Start editing its inbound rules.
Add an inbound rule that permits all protocols and ports from the AD-Lab-RDP security group itself.
Save the inbound rule changes.
Confirm that the inbound list shows the RDP rule from My IP.

Confirm that the inbound list also shows the self-referencing rule for all protocols and ports.

Why Use a Self-Reference?

The self-reference lets both instances exchange private domain traffic through the dedicated security group. Their communication uses private IP addresses inside the VPC.

The separate RDP rule keeps port 3389 reachable only from your current public IP. Active Directory service ports remain closed to the internet.

Instance Missing or Security Rules Look Wrong?

Confirm that the console still shows US East (N. Virginia).
Check that AD-DC1 uses the AD-Lab-RDP security group.
Check that the RDP rule uses My IP instead of an unrestricted internet source.

Ask for help with the exact state you see: help me troubleshoot my AD-DC1 EC2 launch or security group rules.

Add AD-CLIENT1 and record both addresses

Both servers need the same VPC and subnet so their private traffic follows one predictable path. Reusing the key pair and security group also keeps the access model consistent.

Return to the EC2 instances list.
Click Launch instance.
Set the instance Name tag to AD-CLIENT1.
Choose the latest AWS Windows Server 2025 Base image under Application and OS Images (Amazon Machine Image).
Select t3.medium under Instance type.
Select the existing key pair named your lab key pair name under Key pair (login).

Why Reuse the Same Access Controls?

The shared security group gives both instances the same restricted RDP rule. Its self-reference also permits private communication between every instance attached to it.

The shared key pair lets one local .pem file decrypt both Administrator passwords. Each server still receives a different password.

Keep the default VPC selected under Network settings.
Select this subnet: your selected default subnet.
Select the existing AD-Lab-RDP security group.
Keep the default gp3 root volume under Configure storage.
Review the region-specific estimate shown in the launch summary.
Click Launch instance.

The second Windows boot also needs a short wait. Keep the EC2 page available until both state values settle on running.

Return to the EC2 instances list.
Wait until AD-CLIENT1 shows the running state.
Confirm that AD-DC1 also remains in the running state.
Confirm that both instances use the AD-Lab-RDP security group.

That is the infrastructure layer in place. Your two Windows servers now share one restricted network boundary.

Private and Public IPv4 Addresses

A private IPv4 address identifies a server inside the VPC. The next steps use the domain controller's private address for internal network configuration.

A public IPv4 address gives Windows App a route from your Mac to the server. It is the address you use for the remote PC entry.

Select AD-DC1 in the EC2 instances list.
Record its private address: AD-DC1 private IPv4 address.
Record its public address: AD-DC1 public IPv4 address.
Select AD-CLIENT1 in the EC2 instances list.
Record its private address: AD-CLIENT1 private IPv4 address.
Record its public address: AD-CLIENT1 public IPv4 address.

Connect to both Windows desktops

AWS encrypts each initial Administrator password against your key pair. The matching .pem file proves that you hold the private key before AWS reveals the password.

Password generation can take several minutes after a new Windows instance launches. If password data is empty, give AWS up to 15 minutes before trying again.

Select AD-DC1 in the EC2 instances list.
Choose Connect.
Choose Get Password.
Provide the downloaded .pem private key file.
Choose Decrypt Password.
Store the Administrator password in your secure password manager under AD-DC1.

You now have the local credential for the future domain controller. Keep the decrypted password out of screenshots and shared notes.

Select AD-CLIENT1 in the EC2 instances list.
Choose Connect.
Choose Get Password.
Provide the same downloaded .pem private key file.
Choose Decrypt Password.
Store the Administrator password in your secure password manager under AD-CLIENT1.

Keep Credentials Out of Evidence

Never capture the decrypted password page in a screenshot. Your EC2 instances list and Windows desktops prove the setup without exposing credentials.

Press Cmd+Space on your Mac to open Spotlight.
Type Windows App into Spotlight.
Press Enter to open Windows App.
Select the Devices tab.
Select the plus icon.
Enter AD-DC1 public IPv4 address in PC Name.
Choose Add.

The first remote PC entry now points to AD-DC1. Its public address routes the session to the correct EC2 instance.

Select the plus icon again.
Enter AD-CLIENT1 public IPv4 address in PC Name.
Choose Add.
Confirm that the Devices tab shows two remote PC entries.

Before you connect, do you expect both entries to open the same server or two separate Windows desktops?

Open the remote PC entry for AD-DC1 public IPv4 address.
Sign in with Administrator and the saved AD-DC1 password.
Confirm that you reach a Windows Server desktop.
Return to the Devices tab in Windows App.
Open the remote PC entry for AD-CLIENT1 public IPv4 address.
Sign in with Administrator and the saved AD-CLIENT1 password.
Confirm that you reach a separate Windows Server desktop.
Return to the EC2 console in Safari.

Confirm that both instance states still show running.

Both entries open separate Windows Server desktops with local Administrator access. The EC2 console shows AD-DC1 and AD-CLIENT1 in the running state.

That is a strong first win. Your Mac can now reach both halves of the isolated support lab.

Remote Desktop Connection Failing?

Check that each Windows App entry uses the matching public IPv4 address.
Check whether your Mac changed networks after you created the RDP rule.
Update the RDP source to My IP if your current public address changed.
Remove any saved failed credential before retrying with the newly decrypted password.
Confirm that the username is Administrator.

Ask for targeted help: help me diagnose my Windows App connection to the EC2 servers.

Your two-server Windows lab is live and accepting administrator connections. Next, you will turn AD-DC1 into the domain controller for corp.example.com.

Build the Active Directory Forest

Both Windows Server instances are running. You can reach each one through Windows App.

Active Directory Domain Services turns AD-DC1 into a domain controller. That working server becomes the smallest visible directory environment you need before any password ticket can exist.

In this step, get ready to:

Install Active Directory Domain Services with its management features on AD-DC1.
Promote AD-DC1 into a new corp.example.com Active Directory forest.
Verify the new domain through Active Directory Users and Computers.

Install Active Directory Domain Services

Server Manager installs Windows roles through a guided wizard. The AD DS role adds directory services. Its management features support the configuration work that follows.

Switch back to the AD-DC1 remote PC in Windows App.
Select Manage in Server Manager.
Select Add Roles and Features.

The role installation wizard opens on AD-DC1. It guides you through choosing the installation type plus the server role.

Select Role-based or feature-based installation.
Advance to the server role selection page.
Select Active Directory Domain Services.

Windows now asks permission to include the management features required by AD DS.

Select Add Features.
Advance to the confirmation page.

The installation can remain on its progress screen while Windows adds the role. The moving progress indicator means AD-DC1 is still working.

Select Install.

The result page shows that the role installation has completed. AD-DC1 now has the components required for promotion.

What did the role installation add?

The role provides the directory service components. Promotion activates those components by creating a forest.

The management features add the graphical tools you use to administer the finished domain.

Role installation not completing?

Confirm the Windows App session is connected to AD-DC1.
Check that Active Directory Domain Services remains selected in the wizard.

Help me diagnose an AD DS role installation problem on AD-DC1.

Create the corp.example.com forest

The installed role becomes active when AD-DC1 is promoted. Promotion creates the corp.example.com forest with AD-DC1 as its first domain controller.

Why self-managed AD DS?

This lab uses self-managed AD DS so you operate the domain controller directly. AWS Managed Microsoft AD handles more of the infrastructure for you.

The self-managed route keeps your practice focused on the graphical administration work used in infrastructure support roles.

Select Promote this server to a domain controller on the installation result page.
Select Add a new forest.

The wizard now needs the DNS name for the first domain in the forest.

Enter corp.example.com as the root domain name.
Advance to the domain controller options page.

Protect the recovery password

Directory Services Restore Mode is a recovery environment for the directory. This password only protects that recovery mode for your disposable lab.

A unique lab-only value keeps the recovery credential separate from the passwords you use for normal administration.

Keep the DNS server option selected.

This selection installs DNS on AD-DC1. Domain members use that service to discover the directory later.

Enter a unique lab-only DSRM password in the first password field.
Re-enter the same DSRM password in the confirmation field.

Both fields display masked characters. Your recovery credential is ready to be stored securely.

Store the DSRM password in a secure password manager.
Continue to the additional options page.
Keep CORP as the NetBIOS name.

The wizard shows CORP as the short domain name. Windows uses this name in account references such as CORP\Administrator.

Continue to the prerequisite check.
Wait for the prerequisite check to finish.

The completed check confirms whether AD-DC1 is ready for promotion. Resolve any blocking item before continuing.

The next action installs the forest. Windows App disconnects because AD-DC1 restarts automatically after the promotion.

Select Install.

The wizard creates the forest. Windows App disconnects when AD-DC1 begins its automatic restart.

Promotion not reaching the restart?

Confirm the Windows App session is connected to AD-DC1.
Use the prerequisite check's linked explanation to correct the reported setting.

Help me resolve a domain controller promotion problem.

Verify the new domain

Promotion gives AD-DC1 a domain sign-in context. You now use the CORP domain account to administer the server.

The first startup after promotion can take several minutes. A temporary connection failure during this window usually means AD-DC1 is still restarting.

Return to the AD-DC1 remote PC from earlier in Windows App.

The Windows sign-in screen returns when the domain controller is ready.

The Windows Server desktop opens under the domain administrator account.

Select Tools in Server Manager.
Select Active Directory Users and Computers.

Before you expand the console tree, which domain name do you expect to find?

Expand corp.example.com in the console tree.

You should see corp.example.com expand into the domain's built-in containers. This confirms that AD-DC1 is serving the new forest.

That is the directory foundation every password incident in this lab depends on. Your domain controller is live plus ready for user administration.

Domain missing from the console tree?

Confirm you signed in as CORP\Administrator.
Confirm the Windows App connection points to AD-DC1.
Allow Server Manager to finish loading after the restart.

Help me find corp.example.com in Active Directory Users and Computers.

AD-CLIENT1 remains a workgroup server. Next, you will point it to AD-DC1 for domain discovery before joining it to corp.example.com.

Join the Test Server and Create Users

Your Active Directory forest is live on AD-DC1. A separate server still needs to discover the domain before user sign-ins can prove it works.

AD-CLIENT1 uses DNS on AD-DC1 to locate corp.example.com. This step turns that discovery into a domain member with three accounts that can use Remote Desktop.

In this step, get ready to:

Point AD-CLIENT1 to AD-DC1 for domain name resolution.
Join AD-CLIENT1 to the domain.
Create three users with group-based Remote Desktop access.

Join AD-CLIENT1 to the domain

A domain join depends on DNS-based discovery. AD-CLIENT1 needs to ask AD-DC1 where the domain services live.

Switch back to the AD-CLIENT1 session in Windows App.
Select Local Server in Server Manager.
Select the network adapter hyperlink beside Ethernet.
Right-click the active Ethernet adapter.
Select Properties.
Select Internet Protocol Version 4 (TCP/IPv4).
Select Properties.
Keep Obtain an IP address automatically selected.

Why keep the IP address automatic?

AWS continues assigning AD-CLIENT1 its private network address. You only replace the DNS server setting so domain discovery goes through AD-DC1.

Select Use the following DNS server addresses.
Enter AD-DC1's recorded private IPv4 address in Preferred DNS server.
Select OK.
Select Close in the adapter properties window.

AD-CLIENT1 keeps its automatic network address. Its domain lookups now go to the DNS service on AD-DC1.

Return to Server Manager.
Select Local Server.
Select the Workgroup hyperlink.
Select Change.
Select Domain.
Enter corp.example.com.
Select OK.
Enter CORP\Administrator when the credential prompt appears.

Enter the domain Administrator password.
Select OK.
Acknowledge the successful domain welcome message by selecting OK.

The restart can take a few minutes while Windows applies the new computer identity. A short disconnect from AD-CLIENT1 is expected.

Restart AD-CLIENT1 when Windows prompts you.
Return to the AD-CLIENT1 remote PC entry in Windows App after the restart.
Sign in as the local Administrator.
Select Local Server in Server Manager.

You should see corp.example.com beside Domain. That is the first cross-server proof that AD-CLIENT1 can find the domain controller.

Domain join did not complete?

Confirm that Preferred DNS server contains AD-DC1's private IPv4 address.
Confirm that both EC2 instances still use the AD-Lab-RDP security group.
Retry the domain join with CORP\Administrator.

Ask for help with the details you can see: help me troubleshoot why AD-CLIENT1 cannot join corp.example.com

Create the users and access group

An organizational unit keeps the lab accounts together. A security group lets you grant one permission to all three users.

Switch back to the AD-DC1 session.
Return to Active Directory Users and Computers from earlier.
Right-click corp.example.com in the console tree.
Select New.
Select Organizational Unit.
Enter Lab Users as the name.
Select OK.

You should see Lab Users beneath corp.example.com in the console tree.

Right-click Lab Users.
Select New.
Select Group.
Enter Lab RDP Users in Group name.
Select Global under Group scope.
Select Security under Group type.
Select OK.

You should see Lab RDP Users inside the Lab Users OU.

Why use one global group?

All three accounts belong to the same domain. A global security group collects those accounts behind one reusable access rule.

AD-CLIENT1 only needs the group added to its local Remote Desktop Users group. Future members inherit the same sign-in permission.

These passwords stay inside the disposable lab. Keep them out of screenshots.

What counts as a complex password?

Each temporary password needs at least 14 characters for this lab. Complexity uses characters from at least three categories: uppercase letters, lowercase letters, numerals, or special characters.

Right-click Lab Users.
Select New.
Select User.
Enter Avery as the user's name.
Enter avery in User logon name.
Select Next.
Create a unique temporary password with at least 14 characters.
Enter the same password in Confirm password.

The wizard now has Avery's domain identity and matching password confirmation.

Clear User must change password at next logon.
Keep Account is disabled clear.
Select Next.
Select Finish.

You should see avery in the Lab Users OU.

Repeat the User wizard to create morgan with a different temporary password.
Repeat the User wizard to create priya with another different temporary password.
Keep all three temporary passwords available for the later sign-in tests.
Confirm that avery, morgan, and priya appear in the Lab Users OU.

The OU now contains three enabled test users. Each account has its own temporary password.

Right-click Lab RDP Users.
Select Properties.
Select the Members tab.
Select Add.
Enter avery in the object name field.
Select Check Names.
Select OK.

Avery now appears in the group's Members list.

Repeat the Add workflow for morgan.
Repeat the Add workflow for priya.
Confirm that all three users appear under Members.
Select OK to save the group membership.

Grant Remote Desktop access and test Avery

A domain account still needs permission on the member server. Adding the domain group to the local Remote Desktop Users group grants that permission to every member.

Switch back to the local Administrator session on AD-CLIENT1.
Return to Server Manager.
Select Tools.
Select Computer Management.
Expand System Tools.
Expand Local Users and Groups.
Select Groups.
Right-click Remote Desktop Users.

What changes on AD-CLIENT1?

The domain group lives in corp.example.com. The local group controls who can use Remote Desktop on this specific server.

Select Add to Group.
Select Add.
Enter CORP\Lab RDP Users under Enter the object names to select.
Select Check Names.
Select OK.
Select OK in the group properties window.

AD-CLIENT1 now grants Remote Desktop access to members of CORP\Lab RDP Users.

Sign out of the local Administrator session on AD-CLIENT1.
Select Devices in Windows App on your Mac.
Select the ellipses on the AD-CLIENT1 card.
Select Edit.
Select Add Saved Credential from the Saved credential list.
Enter CORP\avery in Username.
Enter Avery's temporary password in Password.
Select Add.

Select Save on the AD-CLIENT1 connection.

Before you connect, do you expect membership in the domain group to give Avery access to the server?

Select the AD-CLIENT1 remote PC to connect as CORP\avery.

You should reach the Windows desktop on AD-CLIENT1 as Avery. That successful sign-in proves the domain join and both layers of group membership work.

Avery cannot reach the desktop?

Confirm that the saved username is CORP\avery.
Confirm that avery appears in the domain group's Members list.
Confirm that CORP\Lab RDP Users appears in AD-CLIENT1's local Remote Desktop Users group.

Ask for help with the failed sign-in: help me trace Avery's Remote Desktop access through both groups

Your domain now has a separate member server with working user access. Next, you will enforce the password and lockout rules that create the support incidents.

Enforce Password and Lockout Policy

Your domain member now accepts ordinary users from corp.example.com. The next support lesson begins when a valid user loses access because domain rules change the account's state.

Active Directory Domain Services tracks password state separately from account lockout state. That distinction explains why a reset can complete while the ticket remains unresolved.

In this step, get ready to:

Configure the domain password policy and account lockout policy.
Lock Avery after refreshing the domain policy.
Test a password-only reset while Avery remains locked.

Configure the domain policy

The Group Policy Management Console applies account rules across the domain. Editing Default Domain Policy gives every domain user the same baseline controls.

Switch back to AD-DC1 in Windows App.
Return to Server Manager from earlier.
Select Tools.
Select Group Policy Management.

Why Group Policy here?

A local policy affects one server. A domain-linked policy gives the directory one shared set of password and lockout rules.

Expand the forest for corp.example.com in the console tree.
Expand Domains.
Expand corp.example.com.
Expand Group Policy Objects.
Right-click Default Domain Policy.
Select Edit.

Expand Computer Configuration in the Group Policy Management Editor.
Expand Policies.
Expand Windows Settings.
Expand Security Settings.
Expand Account Policies.
Select Password Policy.

Double-click Minimum password length.
Enter 14 in the value field.
Select OK.
Double-click Password must meet complexity requirements.
Select Enabled.
Select OK.

The Password Policy details now show a minimum length of 14 characters. Password complexity is enabled.

Select Account Lockout Policy in the console tree.
Double-click Account lockout threshold.
Enter 3 invalid attempts.
Select OK.
Accept the proposed values if Windows opens an extra confirmation dialog.

The details pane now shows an account lockout threshold of 3 invalid attempts.

How Do the Lockout Controls Work?

The threshold counts invalid sign-in attempts before Windows locks the account.
The duration controls how long the account stays locked without administrator intervention.
The reset period controls when Windows clears an incomplete count of failed attempts.

Double-click Account lockout duration.
Enter 15 minutes.
Select OK.
Double-click Reset account lockout counter after.
Enter 15 minutes.
Select OK.

The Account Lockout Policy details now show a threshold of 3. Both timing values show 15 minutes.

Why Use These Values?

These short-lived controls make the incidents reproducible within one lab session. They are lab settings instead of a universal production recommendation.

Policy Values Not Staying?

Confirm that you edited Default Domain Policy under corp.example.com. Reopen each policy setting to check its saved value.

Make sure both timing settings use 15 minutes. Help me check why my Default Domain Policy values are not saving.

Trigger Avery's lockout

The policy must reach the domain controller before you test it. A forced refresh applies the current computer-side settings immediately.

Use Windows search on AD-DC1 to open an elevated Command Prompt.
Apply the current domain policy by running this command:

gpupdate /force

What Does This Command Do?

The gpupdate /force command reapplies every Group Policy setting. This makes the updated domain controls available for your lockout test.

You should see confirmation that the computer policy refresh completed successfully. The user policy refresh should also report success.

Policy Refresh Did Not Succeed?

Confirm that Command Prompt is running with administrator privileges. Check that AD-DC1 is still connected to the domain.

Help me troubleshoot the Group Policy refresh.

Switch to the AD-CLIENT1 session currently signed in as CORP\avery.
Sign out Avery from the Windows Start menu.
Return to Windows App on your Mac.

Before you test the new threshold, do you think the third rejected sign-in changes only the current connection or Avery's domain account state?

Attempt to sign in to AD-CLIENT1 as CORP\avery with a deliberately incorrect password.
Retry the sign-in with the same incorrect password.
Retry the sign-in a third time with the same incorrect password.

The third attempt is denied. Avery has crossed the threshold and is now locked for 15 minutes.

Avery Did Not Lock?

Confirm that all three attempts used CORP\avery. Make sure Windows App submitted the deliberately incorrect password on each attempt.

If Windows App reused a saved credential, edit or remove that credential before repeating the three attempts. Help me verify why Avery did not lock after three failed sign-ins.

Test a password-only reset

Avery's lockout lasts 15 minutes. Complete the reset and retest promptly so the lockout remains active during this experiment.

Switch back to AD-DC1 in Windows App.
Return to Active Directory Users and Computers from earlier.
Select the Lab Users organizational unit.
Right-click avery.
Select Reset Password.

Choose a new unique temporary password containing at least 14 characters.
Include characters from at least three complexity categories.
Enter the new temporary password in New password.
Enter the same temporary password in Confirm password.
Leave Unlock the user account clear.
Select OK.

Good. You have changed Avery's credential while preserving the state needed for this test. You should see confirmation that the password reset completed.

Before you reconnect, do you think the new password is enough to restore Avery's access?

Return to the AD-CLIENT1 entry in Windows App.
Attempt to connect as CORP\avery using the new temporary password.

The connection is still denied even though the password reset succeeded. You have reproduced the support trap this lab was designed to expose.

Avery's password is current. The separate account lockout state continues to block authentication because Unlock the user account remained clear.

Did the Result Differ?

If Avery signs in, the 15-minute lockout may have expired. Repeat the three incorrect attempts before resetting and retesting promptly.
If Avery signs in immediately after the reset, confirm that Unlock the user account remained clear.
If the submitted password is unclear, edit or remove the saved Windows App credential before retrying with the new password.

Help me reproduce the reset-only lockout test.

The unresolved ticket is now waiting in your queue. Next, you'll diagnose Avery's account state and complete the recovery.

Resolve the Password Incident Queue

Avery's rejected sign-in proves that a password reset can leave an account lockout in place. Your next goal is to clear that separate account state.

You will use Active Directory Users and Computers to resolve three tickets. Windows App gives each fix a real sign-in test on AD-CLIENT1.

Each ticket has a different cause: a lockout, a disabled account, or a password policy rejection.

In this step, get ready to:

Unlock Avery after assigning a compliant temporary password.
Reproduce Morgan's disabled-account failure before restoring access.
Prove Priya's weak password is rejected before assigning a compliant replacement.

Resolve Avery's locked account

Avery's new password is valid. The account's locked state still blocks authentication.

The password reset dialog can change the credential while explicitly clearing the lockout. Both controls must reflect the intended support action.

This credential belongs only to the disposable lab. A unique temporary value keeps it separate from every password you use elsewhere.

Switch back to Active Directory Users and Computers on AD-DC1 from earlier.
Select the Lab Users OU in the console tree.
Select avery in the user list.
Open Avery's Reset Password dialog from the context menu.

The dialog separates the password fields from the account-unlock option. This is the control that the earlier reset deliberately left clear.

Enter a new unique temporary password of at least 14 characters in New password.
Enter the same temporary password in Confirm password.

Both password fields now contain the same masked value.

Select Unlock the user account.

The selected option tells the directory to clear Avery's lockout when the reset is confirmed.

Select OK to apply the password reset and unlock.

Before you test Avery again, do you expect the same denied sign-in or a successful desktop session?

Return to the existing AD-CLIENT1 remote PC entry in Windows App.
Sign in as CORP\avery using the temporary password you just assigned.

You will reach the Windows Server desktop on AD-CLIENT1. Avery's successful sign-in proves that the password and lockout states are both corrected.

Is Avery Still Denied Access?

Switch back to Avery's password reset dialog and confirm that Unlock the user account was selected before you applied the reset.

Windows App may reuse a saved failed credential. Remove the saved credential from the existing remote PC entry before submitting Avery's new password again.

Help me diagnose why Avery remains locked out after I selected the unlock option in Active Directory Users and Computers.

That resolves the original incident. Avery's new password works because the account lockout is explicitly cleared.

Recover Morgan's disabled account

A disabled account blocks new sign-ins even when its password is correct. Reproducing that failure gives you evidence to distinguish disablement from a forgotten password.

Switch back to Active Directory Users and Computers on AD-DC1.
Select morgan in the Lab Users OU.
Choose Disable Account from Morgan's context menu.

Morgan's directory account is now disabled. The current password remains unchanged.

Before you try the account, do you think a known correct password can overcome the disabled state?

Return to the existing AD-CLIENT1 remote PC entry in Windows App.
Attempt to sign in as CORP\morgan using Morgan's current temporary password.

Windows App denies the sign-in. This intended failure proves that account status can block a valid credential.

Switch back to Active Directory Users and Computers on AD-DC1.
Select morgan in the Lab Users OU.
Choose Enable Account from Morgan's context menu.

Morgan's account is enabled again. The directory can now accept a new sign-in after the password is updated.

Open Morgan's Reset Password dialog from the context menu.

The password reset dialog is ready for Morgan's replacement credential.

Enter a new unique temporary password of at least 14 characters in New password.
Enter the same temporary password in Confirm password.

Both fields now contain Morgan's matching masked password.

Select OK to apply the password reset.

Before you retest Morgan, which account state should now allow the sign-in to proceed?

Return to the existing AD-CLIENT1 remote PC entry in Windows App.
Sign in as CORP\morgan using the new temporary password.

You will reach the Windows Server desktop on AD-CLIENT1. Morgan's successful session proves that the account is enabled and the replacement password works.

Is Morgan Still Rejected?

Confirm that Morgan's context menu now offers Disable Account. That option indicates the account is currently enabled.

Clear any saved Morgan credential from the existing Windows App entry before submitting the replacement password again.

Help me diagnose why Morgan cannot sign in after I enabled the account and reset the password.

Prove Priya's password policy failure

Priya's ticket tests a different control. The domain evaluates each replacement against its minimum length and complexity requirements before accepting the reset.

Switch back to Active Directory Users and Computers on AD-DC1.
Select priya in the Lab Users OU.
Open Priya's Reset Password dialog from the context menu.

The open dialog gives you a controlled place to test the domain's password rules.

Enter a lab-only test password with fewer than 14 characters in New password using uppercase letters, lowercase letters, a numeral, plus a special character.
Enter the same short test password in Confirm password.

Both fields now contain a matching value that falls below the domain's minimum length.

Before you submit the reset, do you expect the directory to accept or reject this short password?

Select OK to attempt the reset.

You will see a policy error explaining that the password does not meet the domain's requirements. This intended rejection proves that the domain policy is evaluating administrator-initiated resets.

Close the password policy error.

Priya's password reset dialog is ready for a compliant replacement.

Replace the short value in New password with a unique temporary password of at least 14 characters that satisfies complexity.
Enter the same compliant temporary password in Confirm password.

Both fields now contain Priya's matching compliant password.

Select OK to apply the compliant password reset.

Before the final sign-in, do you expect the corrected password to satisfy the same policy that rejected the short value?

Return to the existing AD-CLIENT1 remote PC entry in Windows App.
Sign in as CORP\priya using the compliant temporary password.

You will reach the Windows Server desktop on AD-CLIENT1. Priya's successful session proves that the compliant replacement passed the domain policy.

Is Priya's Compliant Password Rejected?

Confirm that the replacement contains at least 14 characters. Complexity requires characters from at least three supported categories.

Use a new value that differs from Priya's earlier temporary password. Clear any saved credential in Windows App before testing it again.

Help me diagnose why Priya's compliant password reset or sign-in is still being rejected.

You have cleared the full queue. Avery, Morgan, and Priya can each reach the AD-CLIENT1 desktop after the correct account state or password issue is resolved.

Secret mission

Add a Privileged-User Password Policy

Your domain-wide policy protects every ordinary account with one baseline. In this mission, you will scope a stricter rule to Morgan through the Privileged Operators group. You will prove which policy wins with two controlled password resets.

Clean Up Your Resources

Your two Amazon EC2 instances keep generating usage charges while they run. Decide whether to keep the lab available, pause it for later, or delete it entirely.

Cost warning

Running instances incur charges even when idle. Their assigned public IPv4 addresses also incur usage charges.

Stopping the instances ends instance-usage billing. The attached Amazon EBS root volumes continue to incur storage charges.

Choose Pause if you plan to return. Choose Delete when you have finished with the lab.

Resources you used:

Two t3.medium EC2 instances named AD-DC1 plus AD-CLIENT1.
Two gp3 root volumes containing the servers' operating systems.
The corp.example.com Active Directory Domain Services forest stored on AD-DC1.
The domain-joined member server configuration stored on AD-CLIENT1.
Two public IPv4 addresses assigned while the instances are running.
The AD-Lab-RDP security group containing the private traffic rule plus the restricted RDP rule.
Two remote PC entries in Windows App.
The local RSA .pem private key file stored on your Mac.

Keep everything running

No action is needed. Choose this if you want to continue practising password incidents immediately.

Leave AD-DC1 in the running state.
Leave AD-CLIENT1 in the running state.
Keep AD-Lab-RDP attached to both instances.
Retain both Windows App remote PC entries.
Store the local .pem private key file securely.

Pause - I'll come back to this later

Shut down the running instances to stop instance-usage charges. Your EBS root volumes remain billable while they preserve the lab.

Return to the Amazon EC2 console from earlier.
Select AD-DC1 plus AD-CLIENT1.
Choose Instance state.
Choose Stop instance.
Confirm each instance reaches the stopped state.

Your compute usage is now paused. The domain data remains on the two root volumes.

When you return:

Start AD-DC1 from Amazon EC2.
Wait until AD-DC1 reaches the running state.
Start AD-CLIENT1 from Amazon EC2.
Update the AD-DC1 remote PC entry with its new public IPv4 address.
Update the AD-CLIENT1 remote PC entry with its new public IPv4 address.

Delete - I don't want to use this again

Remove all project resources when you have finished the lab. Termination is permanent because the servers cannot be recovered afterwards.

Return to the Amazon EC2 console from earlier.
Select AD-DC1.
Confirm its root volume shows Delete on termination as Yes.
Repeat the root-volume check for AD-CLIENT1.

Both root volumes are now scheduled for removal with their instances.

Select AD-DC1 plus AD-CLIENT1.
Choose Instance state.
Choose Terminate (delete) instance.
Choose Terminate (delete).

Termination can take a short while. AWS is removing both servers plus their root volumes.

Wait until both instances finish terminating.
Delete AD-Lab-RDP from the EC2 security group list after AWS shows that it is no longer attached.
Remove the AD-DC1 remote PC entry from Windows App.
Remove the AD-CLIENT1 remote PC entry from Windows App.
Delete the local .pem private key file from its saved location on your Mac.
Confirm the two root volumes no longer appear in the EC2 volume list.
Confirm AD-Lab-RDP no longer appears in the EC2 security group list.
Confirm the local .pem file no longer appears in its saved location.

That's the billable lab infrastructure cleaned up. Your local private key file is gone too.

Nice Work!

You did it! Your two-server Active Directory Domain Services lab on Amazon EC2 now gives you a repeatable way to reproduce password incidents.

You've learned how to:

Build the corp.example.com Active Directory forest on AD-DC1. Join AD-CLIENT1 as a member server through DNS-based domain discovery.
Use Group Policy to enforce a 14-character complex password policy. Trigger a three-attempt account lockout. Prove that a password reset alone leaves Avery blocked.
Use Active Directory Users and Computers to recover Avery's locked account. Restore Morgan's disabled account. Replace Priya's rejected weak password with a compliant one. Verify every fix through successful Windows App sign-ins.
Secret Mission: Applied a fine-grained password policy to Privileged Operators. Verified Privileged Operations Policy as Morgan's effective policy in Active Directory Administrative Center.

Ready to quiz yourself?