A directory-access lab should show what an account can do, not just that the account exists.
Use a permissions matrix to connect users, groups, resources, and allowed actions. Two fictional roles and one folder can be enough to demonstrate the difference between reading and changing information.
Define the expected behavior before configuring the environment. Then test each relevant action and explain any mismatch. That produces a more useful IAM example than a user-creation screenshot because the project is testing an actual access requirement.
Separate read access from permission to change files
Use a fictional purchasing team and a supplier folder. Define the requirements before you build:
| Role | Required action | Action outside the requirement |
|---|---|---|
| Reviewer | Read the test documents | Change their contents |
| Editor | Update the test documents | Anything beyond the defined editing requirement |
| Other employee | No access through this design | Read or change the supplier documents |
“Access to the folder” is too broad to test. Reading, creating, modifying, and deleting are different actions, so choose the ones your scenario actually requires.
Don't assume an editing label settles every permission detail. State which actions you'll verify and what this version leaves untested.
Start with those few checks. You can expand the scenario once you understand the first permission path and can explain its results.
Use groups to represent the intended access
Create fictional test identities and appropriate lab groups for the defined roles. Configure the resource permissions through the intended groups.
Microsoft's security-principal guidance explains the use of groups to manage shared rights and permissions rather than assigning everything separately to individual accounts.
Record which membership is supposed to provide which capability. Keep group names descriptive enough that the diagram and evidence remain understandable.
Don't use broad administrative membership to avoid permission problems. That would bypass the learning question rather than answer it.
Test each role against each relevant action
Use a reviewer account to attempt reading and modifying. Use an editor account for the corresponding actions. Then use an unrelated account to test the intended exclusion.
Record expected and actual results in the same matrix. Confirm the active identity and use appropriate fresh-session conditions after membership changes.
If you're accessing a Windows resource through a network share, account for the relevant permission layers rather than assuming one visible setting explains the result. Use current platform documentation for your implementation.
An unexpected success is as important as an unexpected failure. Both mean the behavior needs investigation.
Investigate the permission path, not just the error
When the result differs from your expectation, trace how the user receives access.
Check the memberships and permissions relevant to your lab, including inheritance or other assignments that may affect the outcome. Change one relevant condition at a time where possible.
Avoid adding a broad allow rule because it makes the test pass quickly. Your goal is to match the defined role, including the actions it should not perform.
Document the original result, the cause you established, the correction, and the retest. That sequence shows more understanding than presenting only the final working configuration.
Turn the matrix into the portfolio summary
Put the business requirement and the final test matrix near the top of the write-up. Add a simple diagram and the configuration details needed to support the conclusion.
State the limits: one resource, fictional roles, and the specific actions tested. This isn't a complete enterprise access model.
Then explain the career connection. You practiced translating a requirement into group-based permissions, checking behavior, and troubleshooting a mismatch. Those are more informative claims than “built an Active Directory lab.”
Keep the original matrix even when a test fails. Mark the unexpected outcome instead of silently changing the requirement to fit the configuration. The mismatch is what gives the troubleshooting work a clear purpose and makes the correction understandable.
My The Six-Figure IAM Career Playbook places directory access work alongside sign-in and lifecycle projects. It helps you build evidence that connects familiar account administration to the access decisions identity roles are responsible for supporting. The ebook is $9.