This guide provides step-by-step instructions for completing all 12 Identification & Authentication labs. Each lab presents a real-world identity management problem that you must find and fix using tools on the domain controller: Active Directory Users and Computers (ADUC), PowerShell, Task Scheduler, and file-based evidence artifacts.
LabUser!2026#ia). Your own sign-in password is shorter than this andYou will work on a Windows Server domain controller to identify and remediate identity and authentication problems. Unlike the Access Control labs (which focus on group membership), the IA labs use a wider range of tools:
These labs align with CMMC Level 1 Identification & Authentication (IA) requirements:
You will connect to the lab through Apache Guacamole — a web-based remote desktop gateway. There is nothing to install; everything runs in your web browser.
student01student05student12| Connection Name | What It Is |
|---|---|
| PODXX-SRV | Your own pod member server — use this for all IA labs |
This is the only connection you get: every IA lab is done on this desktop.
studentXX@acs-p01.local (or ACS-P01\studentXX) with your domain passwordTip: Press Ctrl+Alt+Shift to open the Guacamole side menu (to return Home or switch connections).
Option 1: Click the "Check Your Progress — Pod XX" banner at the top of the Guacamole interface.
Option 2: Go directly to https://training.status.tcecure.com/pod/XX (replace XX with your pod number).
Active Directory Users and Computers (ADUC)
dsa.mscYou are a local administrator of your own server, so ADUC, GPMC and
Server Manager → Tools all open normally — approve any elevation prompt with
your own account. ADUC connects over the network to DC01-P01 / DC02-P01 and
shows the same directory as before; the oldRunAsInvokerworkaround was only
needed when students worked on the shared domain controller. Your domain
rights are unchanged: you can modify objects in your ownOU=PodXXonly, so an
Access denied on another pod's objects is expected.
PowerShell
powershell → EnterEvery command in this guide works with your own delegated permissions, so a
normal PowerShell window is enough. Windows PowerShell (Admin) also works
on your own server if you want it — elevation there is yours to approve, but it
grants no extra rights in the domain.
Task Scheduler (needed for M2-L1)
taskschd.msc → EnterFile Explorer
All pods share one domain (acs-p01.local), so every object in your pod is prefixed with your pod prefix to keep your work separate. If you are Pod 03, your prefix is P03:
| Thing | Example for Pod 03 |
|---|---|
| Shared reception account | P03-frontdesk |
| Terminated employee | P03-tom.davis |
| Generic accounts | P03-admin, P03-user1, P03-test |
| Backup task owner | P03-s.jenkins |
| Service accounts | P03-svc_backup, P03-svc_web, P03-svc_print |
| Security group | P03-SG-ACS-Sales |
| Scheduled task | Pod03 ACS Nightly Backup |
| Evidence root | C:\CyberLab\Pod03\ |
Critical: when you create an account, you must include your prefix (
PXX-k.omalley, notk.omalley). The automated checker looks for the prefixed name.
acs-p01.local
└── Students
└── PodXX ← your pod
├── Users
│ ├── Admins
│ ├── Staff ← most user accounts live here
│ └── Terminated ← move terminated accounts here
├── Groups
│ ├── Security ← PXX-SG-ACS-* groups
│ └── Distribution
└── Resources
└── Departments
├── Executive, IT, Finance, HR, Consulting
└── Sales ← PXX-tom.davis starts here
Tip: in ADUC use Edit → Find and search for your prefix (e.g.
P03-) to list all of your pod's objects quickly.
All IA files live under C:\CyberLab\PodXX\ on the domain controller (replace XX with your pod number):
| Path | Purpose |
|---|---|
C:\CyberLab\PodXX\ |
Evidence root — write M1-L1.txt, M3-L1.txt, M3-L3.txt, M4-L1.txt, M4-L3.txt here |
C:\CyberLab\PodXX\IA-Artifacts\ |
IA artifacts (CSV inventories, reports, device list, hardening standard) |
C:\CyberLab\PodXX\IA-Artifacts\Vault\ |
Vault entries file (Module 4) |
C:\CyberLab\PodXX\LabArtifacts\ |
Support files placed by the seed process (e.g. rogue_mac.txt) |
C:\CyberLab\PodXX\LabArtifacts\Scripts\ |
Script to review and fix (db_connect.py) |
C:\CyberLab\PodXX\LabArtifacts\Scans\ |
Scan report to analyze (openvas_scan_report.txt) |
C:\CyberLab\PodXX\_LAB_READY_IA-*.txt |
Markers confirming each lab was seeded |
Important: the automated verification checks these exact paths and file names, including your pod folder. Saving to
C:\CyberLab\IA-Artifacts\(withoutPodXX) will fail.
Module 1 is about making sure every person has a unique, individual, accounted-for identity — and that shared, zombie, and generic accounts are remediated.
Difficulty: Beginner | Time: 20 minutes | Type: Hands-on (ADUC)
The front desk uses one shared account, PXX-frontdesk, that multiple reception staff log into. Shared accounts break individual accountability. Two people use it: Karen O'Malley and a temporary agency worker.
Disable the shared account:
Create Karen O'Malley's account:
Karen, Last name: OMalleyPXX-k.omalley — the prefix is requiredLabUser!2026#ia), uncheck "User must change password at next logon",Create the temporary worker's account the same way, with logon name PXX-temp.agency01
Write the evidence file:
Open Notepad and write a short summary, for example:
IA M1-L1 Remediation
Date: 2026-06-10 Performed by: <your name>
- Disabled shared account PXX-frontdesk
- Created individual account PXX-k.omalley (Karen O'Malley)
- Created individual account PXX-temp.agency01 (Temporary Agency Worker)
Save as C:\CyberLab\PodXX\M1-L1.txt
PowerShell alternative:
$p = "PXX" # your prefix, e.g. P03
Disable-ADAccount -Identity "$p-frontdesk"
Get-ADUser -Identity "$p-frontdesk" | Select-Object SamAccountName, Enabled
PXX-frontdesk exists and is disabledPXX-k.omalley existsPXX-temp.agency01 existsC:\CyberLab\PodXX\M1-L1.txt existsIA.L1-3.5.1 requires every system user to be individually identified. With a shared account there is no way to tell who did what.
Difficulty: Beginner | Time: 20 minutes | Type: Hands-on (ADUC)
Tom Davis left the company, but PXX-tom.davis is still enabled, still in the Sales OU, and still a member of the Sales security group. That is a "zombie account".
Find the account: ADUC → Students → PodXX → Resources → Departments → Sales (or Edit → Find for PXX-tom.davis)
Disable it: double-click the account → Account tab → check "Account is disabled" → Apply
Strip group memberships: Member Of tab → select PXX-SG-ACS-Sales → Remove → Yes → remove any other groups (Domain Users cannot be removed) → Apply → OK
Move it: right-click PXX-tom.davis → Move... → Students → PodXX → Users → Terminated → OK
PowerShell alternative:
$p = "PXX"
Disable-ADAccount -Identity "$p-tom.davis"
Get-ADUser "$p-tom.davis" -Properties MemberOf | Select-Object -ExpandProperty MemberOf |
ForEach-Object { Remove-ADGroupMember -Identity $_ -Members "$p-tom.davis" -Confirm:$false }
$parent = (Get-ADUser "$p-tom.davis").DistinguishedName.Split(',', 2)[1]
$ou = (Get-ADOrganizationalUnit -Filter "Name -eq 'Terminated'" `
-SearchBase $parent).DistinguishedName
Move-ADObject -Identity (Get-ADUser "$p-tom.davis").DistinguishedName -TargetPath $ou
(If the last two lines are awkward, just move the account in ADUC.)
PXX-tom.davis is disabledFormer employees' credentials show up in password dumps. A disabled, stripped, relocated account removes that entry point and shows a controlled termination process.
Difficulty: Beginner | Time: 25 minutes | Type: Hands-on (ADUC) + CSV
Three generic accounts exist in your pod: PXX-admin, PXX-user1, and PXX-test. None can be traced to a person, and there is no inventory of authorized users.
Disable each generic account: ADUC → Students → PodXX → Users → right-click each of PXX-admin, PXX-user1, PXX-test → Disable Account
PowerShell alternative:
$p = "PXX"
"$p-admin","$p-user1","$p-test" | ForEach-Object { Disable-ADAccount -Identity $_ }
Create the inventory. Open Notepad and enter something like:
Username,FullName,Department,Status,Justification
PXX-k.omalley,Karen OMalley,Reception,Active,Individual reception account
PXX-temp.agency01,Temp Agency Worker,Reception,Active,Temporary agency staff
PXX-tom.davis,Tom Davis,Sales,Disabled,Terminated employee
PXX-admin,Admin Account,N/A,Disabled,Generic account - no individual owner
PXX-user1,User1 Account,N/A,Disabled,Generic account - no individual owner
PXX-test,Test Account,N/A,Disabled,Generic account - no individual owner
Save as C:\CyberLab\PodXX\IA-Artifacts\Authorized_User_Inventory.csv
.csv.txtPXX-admin, PXX-user1, PXX-test are all disabled (or deleted)Authorized_User_Inventory.csv exists in your pod's IA-Artifacts folder and is not emptyIf "admin" does something malicious, nobody can say who that was. An authorized user inventory proves the organization knows and approves every account it has.
Module 2 covers the identities that are not people — service accounts, automated processes, and devices. CMMC requires them to be identified and managed just like human users.
Difficulty: Intermediate | Time: 10 minutes | Type: Hands-on (ADUC) — task retarget step is instructor-credited this cohort
Read first — this cohort: Step 2 (repointing the scheduled task) cannot be done from a student account on the shared domain controller. Windows only lets a local administrator save a task credential, and students are intentionally not administrators there. Complete Step 1 (create
PXX-svc_backup), read Step 2 so you know how it is done, then move on to M2-L2. Step 2 is credited automatically and no longer affects your completion status. Pods get their own member servers in a later release, where you will perform this step yourself.
The nightly backup task PodXX ACS Nightly Backup runs under a real employee's account, PXX-s.jenkins. Automated jobs should run as dedicated service accounts: when Steve leaves, the backup breaks, and his credentials are needlessly exposed.
PXX-svc_backupCreate the service account:
PXX-svc_backupService account for nightly backup automationPoint the task at the service account (reference only this cohort — expect "Access is denied"; do not troubleshoot it):
taskschd.msc)PodXX ACS Nightly BackupACS-P01\PXX-s.jenkinsPXX-svc_backup, click Check Names → OKLook at the task, read-only. You can open the task and view its settings;
you cannot save a change to the account it runs under. This command shows the
account it currently uses:
(Get-ScheduledTask -TaskName "PodXX ACS Nightly Backup").Principal.UserId
It still returns PXX-s.jenkins, and that is the expected result this cohort.
PXX-svc_backup exists in Active DirectoryPODXX-SRVIA.L1-3.5.1 covers "processes acting on behalf of users". A dedicated service account gives the automated process its own identity and its own accountability.
Difficulty: Beginner | Time: 20 minutes | Type: CSV analysis
A device scan detected MAC address AA-BB-CC-11-22-33, which is not in the authorized device list. You must record it as unauthorized and open a configuration record for investigation.
UNAUTHORIZEDReview the evidence:
C:\CyberLab\PodXX\IA-Artifacts\Authorized_Device_List.csv — three authorized devices (DC, workstation, printer)C:\CyberLab\PodXX\LabArtifacts\rogue_mac.txt — the detected MAC AA-BB-CC-11-22-33Add the rogue device to the bottom of Authorized_Device_List.csv (open it in Notepad), keeping the existing columns:
UNKNOWN-DEVICE,AA-BB-CC-11-22-33,Unknown,UNAUTHORIZED,Unknown,2026-06-10
Save the file (do not delete the existing rows).
Create the configuration record. Open Notepad and enter:
MACAddress,DeviceName,Status,Location,Notes
AA-BB-CC-11-22-33,Unknown Device,UNAUTHORIZED,Network scan,Rogue device detected - requires investigation
Save as C:\CyberLab\PodXX\IA-Artifacts\Device_Config_Record.csv (All Files type).
Heads-up: Lab M4-L2 adds a second finding to this same
Device_Config_Record.csv. When you get there, append to the file — do not overwrite it, or M2-L2 will stop passing.
Authorized_Device_List.csv contains AA-BB-CC-11-22-33 and the word UNAUTHORIZEDDevice_Config_Record.csv exists and is not emptyIA.L1-3.5.1 requires devices to be identified, not just users. An undocumented device on the network is an unmanaged entry point.
Difficulty: Beginner | Time: 25 minutes | Type: Hands-on (ADUC) + CSV
Three service accounts exist — PXX-svc_backup, PXX-svc_web, PXX-svc_print — but their Description fields are empty, and there is no matrix documenting the non-person accounts.
Set the descriptions in ADUC (Students → PodXX → Users) — double-click each account, fill Description, click OK:
PXX-svc_backup → Automated nightly backup servicePXX-svc_web → IIS web application pool identityPXX-svc_print → Print spooler service accountPowerShell alternative:
$p = "PXX"
Set-ADUser "$p-svc_backup" -Description "Automated nightly backup service"
Set-ADUser "$p-svc_web" -Description "IIS web application pool identity"
Set-ADUser "$p-svc_print" -Description "Print spooler service account"
Create the matrix. In Notepad:
AccountName,Description,Owner,Purpose,PasswordRotation,LastReview
PXX-svc_backup,Automated nightly backup service,IT Operations,Runs the nightly backup scheduled task,90 days,2026-04-01
PXX-svc_web,IIS web application pool identity,Web Team,Hosts internal web applications,90 days,2026-04-01
PXX-svc_print,Print spooler service account,IT Operations,Manages network print services,90 days,2026-04-01
Save as C:\CyberLab\PodXX\IA-Artifacts\Service_Account_Matrix.csv.
Service_Account_Matrix.csv exists and is not emptyNote: If
PXX-svc_weborPXX-svc_printis missing, create it the same way you createdPXX-svc_backupin M2-L1.
An undocumented service account is an identity nobody owns. The matrix records what it does, who owns it, and when it was last reviewed — the basis of lifecycle management for non-person identities.
Module 3 is about how users prove who they are: password policy, documented review, and credential handling.
Difficulty: Beginner | Time: 15 minutes | Type: PowerShell + evidence
A domain password policy exists, but there is no exported report and no record that anyone reviewed it. Auditors need written evidence.
Export the policy (PowerShell, replace PodXX):
Get-ADDefaultDomainPasswordPolicy |
ConvertTo-Html -Title "Password Policy Report" |
Out-File "C:\CyberLab\PodXX\IA-Artifacts\PasswordPolicy_Report.html"
Open and read it:
Start-Process "C:\CyberLab\PodXX\IA-Artifacts\PasswordPolicy_Report.html"
Note MinPasswordLength, ComplexityEnabled, LockoutThreshold, PasswordHistoryCount, MaxPasswordAge.
Write the evidence file in Notepad and save as C:\CyberLab\PodXX\M3-L1.txt:
IA M3-L1 Password Policy Review
Date: 2026-06-10 Reviewed by: <your name>
Current policy settings:
- Minimum password length: <value>
- Password complexity: <Enabled/Disabled>
- Lockout threshold: <value>
- Password history: <value>
- Maximum password age: <value> days
Assessment: policy exported and reviewed as required by CMMC IA.L1-3.5.2.
PasswordPolicy_Report.html exists in your pod's IA-Artifacts folder and is not emptyC:\CyberLab\PodXX\M3-L1.txt existsHaving a policy is not enough — you must be able to show it exists and is reviewed. Missing documentation is one of the most common audit findings.
Difficulty: Intermediate | Time: 15 minutes | Type: Review and verify
This cohort: changing the domain password policy requires Domain Admin
rights, and the policy is shared by all 20 pods — one student's change would
apply to everyone. The instructor has therefore applied the hardened policy
centrally. Work through the settings below and verify the live policy in
step 2; do not attempt theSet-command or the GPO edit (both will be denied).
When pods move to their own servers you will set this policy yourself, on your
own server.
The domain password policy was dangerously weak: minimum length 6, complexity disabled, and no account lockout.
Note: the password policy is domain-wide, shared by every pod — it is the one IA lab whose change is not isolated to your pod.
| Setting | Seeded (FAIL) | Required (PASS) |
|---|---|---|
| Minimum password length | 6 | 12 |
| Password complexity | Disabled | Enabled |
| Account lockout threshold | 0 (no lockout) | 10 attempts |
Verify the live policy (this is what is graded):
Get-ADDefaultDomainPasswordPolicy | Select-Object MinPasswordLength, ComplexityEnabled, LockoutThreshold, PasswordHistoryCount, MaxPasswordAge, MinPasswordAge
Confirm minimum length 12, complexity True, and lockout threshold 10 — then
note in your own words which weakness each setting removes.
Reference — how the policy is applied (administrator step, do not attempt this cohort):
Set-ADDefaultDomainPasswordPolicy -Identity (Get-ADDomain).DNSRoot `
-MinPasswordLength 12 `
-ComplexityEnabled $true `
-LockoutThreshold 10 `
-PasswordHistoryCount 24 `
-MaxPasswordAge (New-TimeSpan -Days 90) `
-MinPasswordAge (New-TimeSpan -Days 1)
gpupdate /force
The equivalent GUI path is gpmc.msc → Forest → Domains → acs-p01.local →
Default Domain Policy → Computer Configuration → Policies → Windows
Settings → Security Settings → Account Policies, setting minimum password
length, complexity, and the lockout threshold.
MinPasswordLength is 12 or moreComplexityEnabled is TrueLockoutThreshold is 10 or moreA 6-character password with no complexity and no lockout can be brute-forced in seconds. IA.L1-3.5.2 requires authentication that actually resists common attacks.
Difficulty: Beginner | Time: 15 minutes | Type: Hands-on (ADUC) + evidence
David Chen (PXX-d.chen) had his password reset by the helpdesk, but the "must change password at next logon" flag was never set — so he can keep using the temporary password forever, and whoever set it still knows it.
PXX-d.chenIn ADUC: Students → PodXX → Users → Staff → right-click PXX-d.chen → Reset Password... → enter a new temporary password → check "User must change password at next logon" → OK
PowerShell alternative:
$p = "PXX"
Set-ADUser -Identity "$p-d.chen" -ChangePasswordAtLogon $true
Get-ADUser "$p-d.chen" -Properties pwdLastSet | Select-Object SamAccountName, pwdLastSet # expect 0
Verify in the account's Account tab that the flag is set (or that pwdLastSet is 0)
Write the evidence file and save as C:\CyberLab\PodXX\M3-L3.txt:
IA M3-L3 Password Reset Incident
Date: 2026-06-10 Remediated by: <your name>
User: PXX-d.chen (David Chen)
Issue: password was reset without "must change at next logon"
Action: reset the password and enabled the must-change-at-next-logon flag
Result: the user must set their own password at next sign-in
PXX-d.chen has the must-change-password flag set (pwdLastSet = 0)C:\CyberLab\PodXX\M3-L3.txt existsA temporary password that is never changed is a shared secret between the user and whoever issued it — which defeats individual authentication.
Module 4 covers default credentials, hardcoded passwords, and undocumented authentication configuration — among the most commonly exploited weaknesses in real attacks.
Difficulty: Beginner | Time: 20 minutes | Type: Document editing + evidence
Your organization has a hardening standard (Hardening_Standard.txt), but it never requires default passwords to be changed on new equipment.
Read C:\CyberLab\PodXX\IA-Artifacts\Hardening_Standard.txt — it covers OS hardening, network security, accounts, logging, and physical security, and ends by admitting it is incomplete
Append a section in Notepad and save the file:
6. DEFAULT CREDENTIALS
- All default passwords on newly deployed hardware and software must be
changed before the system is placed into production, including:
network equipment (routers, switches, firewalls), server OS default
accounts, application default admin accounts, SNMP community strings,
and database default credentials.
- Responsibility: IT Operations must verify default credentials are
changed as part of the deployment checklist.
- Reference: CMMC IA.L1-3.5.2 - authenticate identities before granting access
The checker looks for wording that ties default to password/credential — keep those words in the text.
Write the evidence file and save as C:\CyberLab\PodXX\M4-L1.txt:
IA M4-L1 Hardening Standard Update
Date: 2026-06-10 Updated by: <your name>
Action: added a default credentials section to Hardening_Standard.txt
Location: C:\CyberLab\PodXX\IA-Artifacts\Hardening_Standard.txt
The standard now requires all default passwords to be changed before
production deployment, per CMMC IA.L1-3.5.2.
Hardening_Standard.txt contains a default password/credential requirementC:\CyberLab\PodXX\M4-L1.txt existsDefault credentials are the easiest way in. The Mirai botnet took over hundreds of thousands of devices using nothing else.
Difficulty: Beginner | Time: 20 minutes | Type: Scan report analysis + CSV
A vulnerability scan flagged a network device using the default SNMP community string public — anyone on the network can read its configuration.
Read the scan report: C:\CyberLab\PodXX\LabArtifacts\Scans\openvas_scan_report.txt
[HIGH] finding is SNMP community string public on 10.50.1.30 (PRINT-P01), port 161/udpAppend the finding to C:\CyberLab\PodXX\IA-Artifacts\Device_Config_Record.csv.
Do not overwrite this file — it still has to contain your M2-L2 rogue-device row (
AA-BB-CC-11-22-33/UNAUTHORIZED) or M2-L2 will fail. Open it in Notepad and add a line at the end, for example:
10.50.1.30,PRINT-P01,SNMP community string is 'public' (HIGH) - change to a complex value and restrict SNMP,OPEN,Network scan,From openvas_scan_report.txt
Keeping both findings in one file is what the checker expects: the file must mention SNMP (M4-L2) and the rogue MAC marked UNAUTHORIZED must still be in Authorized_Device_List.csv (M2-L2).
Add an SNMP clause to Hardening_Standard.txt (good practice, and it reinforces M4-L1):
7. SNMP CONFIGURATION
- Default SNMP community strings (public, private) must be changed on all
network devices. Use SNMPv3 with authentication and encryption where
supported. SNMP v1/v2c with default strings is a critical finding.
Device_Config_Record.csv mentions SNMPSNMP with public hands out interface details, routing tables, and sometimes credentials to anyone who asks. Documenting the finding is the first step of correcting it.
Difficulty: Intermediate | Time: 25 minutes | Type: Hands-on (file editing) + evidence
db_connect.py connects to the inventory database using a hardcoded password (password123). Anything that touches that file — a repo, a backup, a file share — leaks the credential.
Open C:\CyberLab\PodXX\LabArtifacts\Scripts\db_connect.py in Notepad and find:
DB_PASSWORD = "password123"
Change it to a vault reference and save:
DB_PASSWORD = "VAULT_REF:db_production_password"
The literal password123 must no longer appear anywhere in the file, and VAULT_REF must appear.
Create the vault entries file. In Notepad:
VaultKey,Description,Owner,RotationSchedule,LastRotated
db_production_password,Production database connection credential,DBA Team,90 days,2026-04-01
Save as C:\CyberLab\PodXX\IA-Artifacts\Vault\Vault_Entries.txt
Write the remediation summary and save as C:\CyberLab\PodXX\M4-L3.txt:
IA M4-L3 Hardcoded Password Remediation
Date: 2026-06-10 Remediated by: <your name>
Finding: db_connect.py contained the hardcoded password "password123"
Location: C:\CyberLab\PodXX\LabArtifacts\Scripts\db_connect.py
Remediation:
1. Replaced the hardcoded password with VAULT_REF:db_production_password
2. Documented the credential in IA-Artifacts\Vault\Vault_Entries.txt
3. The password is now retrieved from the vault at runtime, not stored in code
Impact: eliminated credential exposure through script files.
db_connect.py no longer contains password123db_connect.py contains VAULT_REFVault_Entries.txt exists in IA-Artifacts\Vault\ and is not emptyC:\CyberLab\PodXX\M4-L3.txt existsHardcoded credentials are CWE-798, a top software weakness. They end up in version control, backups, and logs. A vault reference keeps the secret out of code and makes rotation possible.
| Command | Purpose |
|---|---|
Get-ADUser -Filter "SamAccountName -eq 'PXX-name'" |
Find a specific AD user |
Disable-ADAccount -Identity "PXX-name" |
Disable a user account |
New-ADUser -SamAccountName "PXX-name" -Name "PXX-name" ... |
Create a new user |
Set-ADUser -Identity "PXX-name" -Description "text" |
Set a user description |
Set-ADUser -Identity "PXX-name" -ChangePasswordAtLogon $true |
Force a password change |
Get-ADDefaultDomainPasswordPolicy |
View the current password policy |
Set-ADDefaultDomainPasswordPolicy |
Change the password policy |
Get-ScheduledTask -TaskName "PodXX ACS Nightly Backup" |
View the backup scheduled task |
gpupdate /force |
Force a Group Policy refresh |
| Task | How To |
|---|---|
| Create a text file | Notepad → File → Save As → choose the path and name |
| Create a CSV file | Notepad → type comma-separated data → Save As → change type to All Files → name it .csv |
| Open a path quickly | Paste the path into the File Explorer address bar |
| Check a file exists | Test-Path "C:\CyberLab\PodXX\M1-L1.txt" |
| Shortcut | Action |
|---|---|
| Windows + R | Open the Run dialog |
| Windows + E | Open File Explorer |
| Ctrl+Alt+Shift | Open the Guacamole side menu |
PXX-) in every account name you createPodXX folder.txt, .csv, .html)C:\CyberLab\IA-Artifacts\ — it must be C:\CyberLab\PodXX\IA-Artifacts\Device_Config_Record.csv in M4-L2 — append to it| Problem | Solution |
|---|---|
| "Access denied" when saving | Save under C:\CyberLab\PodXX\, not a protected system folder |
| Verification says an account was not found | You probably left off the PXX- prefix — rename or recreate the account |
| Verification says a file was not found | Check for the PodXX folder in the path, and for a hidden .txt on your .csv |
| Can't find a user in ADUC | Edit → Find, search for your prefix (e.g. P03-) |
| PowerShell AD commands not recognized | Run Import-Module ActiveDirectory first |
| Task Scheduler won't save the change | Enter the service account password when prompted |
File saved as .txt instead of .csv |
In Save As, set Save as type to All Files (*.*) |
| New password rejected as too weak | The domain requires 12+ characters with complexity (M3-L2) |
| Lab | Name | Status |
|---|---|---|
| M1-L1 | Shared Reception Account | ☐ |
| M1-L2 | Zombie Account | ☐ |
| M1-L3 | Generic Accounts Present | ☐ |
| M2-L1 | Scheduled Task Running as a Human Account | ☐ |
| M2-L2 | Rogue Device Artifact | ☐ |
| M2-L3 | Service Account Matrix Required | ☐ |
| M3-L1 | Password Policy Report Missing | ☐ |
| M3-L2 | Weak Password Policy | ☐ |
| M3-L3 | User Must Change Password at Next Logon | ☐ |
| M4-L1 | Default Credentials in the Hardening Standard | ☐ |
| M4-L2 | SNMP Community String Set to "public" | ☐ |
| M4-L3 | Script Contains a Hardcoded Password | ☐ |
Evidence files you should end up with in C:\CyberLab\PodXX\: M1-L1.txt, M3-L1.txt, M3-L3.txt, M4-L1.txt, M4-L3.txt
Artifacts you should end up with in C:\CyberLab\PodXX\IA-Artifacts\: Authorized_User_Inventory.csv, Authorized_Device_List.csv (updated), Device_Config_Record.csv, Service_Account_Matrix.csv, PasswordPolicy_Report.html, Hardening_Standard.txt (updated), Vault\Vault_Entries.txt
This guide was created for the Digital Resilience Community Clinic (DRCC) Cyber Range.
CMMC Level 1 — Identification & Authentication (IA) Module