An allowed login shows that one path worked. It doesn't establish that the right people were allowed, the wrong people were blocked, or your intended policy caused the outcome.
Test an allowed case and a comparable denied case. Then explain which condition makes the results different.
That gives an access-control lab a stronger conclusion than a successful screenshot alone. Keep the accounts, resource, and session conditions clear so you can distinguish a permission decision from an unrelated failure such as disabled sign-in.
Write the expected behavior before configuring access
Use a small fictional example: members of a purchasing group may read supplier documents. A user outside that group may not read them. Neither account should be able to edit the documents.
Now you have separate requirements to test. Read access and write access are different actions, and a test of one does not establish the other.
Microsoft's security principals documentation explains the account and group identities involved in Windows access control. Your exercise adds the specific resource and expected permissions.
Write the test cases before looking at the result. Otherwise, it is easy to redefine success around whatever happened.
Make the denied user a fair comparison
The denied account should reach the same resource through a comparable path. It should not fail simply because the computer is offline or the account cannot authenticate at all.
If one account can find the server and the other cannot resolve its name, you have not isolated authorization.
Check the prerequisites that both accounts need. Then vary the access-relevant condition, such as group membership.
This is the reason a red error message by itself is weak evidence. The failure must correspond to the behavior you intended to test.
Test the action, not just the screen
Opening a folder is different from reading a file. Reading is different from modifying. A visible application icon is different from permission to use the application's functions.
State exactly what the user attempted and record the result for that action.
For a small permissions lab, three tests may be enough: authorized read succeeds, unauthorized read fails, and an authorized reader cannot write. The scenario determines the right set.
Use ordinary test accounts for these checks. Testing as an administrator can hide the very restrictions you are trying to demonstrate.
Retest after removing the permission you rely on
Add a controlled change to your allowed and denied cases:
- Remove the relevant membership from the previously authorized user.
- Check alternate access paths, such as another group or a direct permission.
- Establish appropriate fresh session conditions for the system you're testing.
- Repeat the same resource action and record the result.
This gives you three access-control test cases: intended access, intended denial, and a permission change.
Keep other conditions comparable. An account prevented from signing in doesn't test the same boundary as an authenticated account denied access to a file.
If access remains, investigate before declaring the removal ineffective. The user may still have another valid assignment or a session state that affects the test.
Your explanation should connect the change to the behavior, not just present two screenshots with no account context.
Document the limits of your conclusion
A good conclusion might be: “In this isolated lab, the configured group allowed read access to this resource, while the comparison account was denied. Neither test account could modify the file.”
That is narrower and more credible than “implemented enterprise least privilege.”
Record the accounts, the resource, the relevant configuration, and the session conditions. Keep secrets and real organizational information out of public evidence.
If a test fails unexpectedly, preserve the observation and explain the correction. A useful lab is allowed to reveal a mistake.
The Six-Figure IAM Career Playbook includes practical lab areas that can become stronger evidence when you test them this way. The $9 guide helps connect those results with the IAM role you are working toward.
When someone asks whether your access model works, you should have evidence for who gets in and who stays out.