The First Identity Lab I'd Give an Experienced Help Desk Technician

The first IAM lab I'd give an experienced help desk technician uses two fictional employees and one shared folder.

One employee should be allowed to read a file. The other should be denied. Your job is to configure that access, test both accounts, and explain the difference.

That small project connects familiar account-management work to authorization. It also gives you a clear interview example without installing a dozen products or pretending a home lab is an enterprise deployment.

Write down who should be allowed and denied

Use fictional employees such as Riley in finance and Jordan in another department. Put a harmless text file in a test finance folder; don't use real payroll data.

Define the result before you configure permissions:

This table becomes your test plan. Keep the permission requirement narrow: reading a file is not the same as changing or deleting it.

You should be able to explain the scenario to someone who has never used Active Directory. “Finance can read this file; other departments cannot” is enough.

If you can't make the intended result clear, simplify the requirement before adding accounts, groups, or extra software.

Build a safe environment you control

Use an isolated lab, authorized evaluation software where applicable, and accounts that have no relationship to your employer.

For a Windows directory example, you'll need a working directory environment and a client or resource server appropriate to the test. A domain controller is important infrastructure, not a general-purpose place to practice risky changes.

Use separate administrative and ordinary test accounts. Don't expose the lab to the public internet just to make it accessible. Don't reuse workplace credentials. Take a recoverable checkpoint before changes that could leave the environment difficult to restore.

The goal is to learn permissions, not to create an uncontrolled copy of your employer's network.

Grant access through a group

Create a clearly named security group for the intended access and add Riley.

Assign the appropriate resource permission to that group. Keep Jordan outside it.

Microsoft documents security groups as a way to assign permissions to shared resources. Source: Active Directory security groups.

For a Windows file share, inspect both the sharing configuration and the file-system permissions. Avoid unrelated broad grants that make the result ambiguous.

You don't need an explicit denial entry just to demonstrate that someone lacks access. First understand why the ordinary permission model should reject the second account.

Document the exact design you chose.

Test as the employee, not the administrator

Sign in as Riley using a fresh session appropriate to the environment. Attempt the allowed action and record the result.

Repeat as Jordan. Keep the tests comparable: same resource, same requested action, and known account identity.

If both succeed, don't immediately declare the requirement impossible. Investigate which permission is granting the unexpected access. If both fail, check whether the intended grant is effective and whether the resource is reachable.

A failed test is useful when it leads to an explanation.

A screenshot taken while signed in as a privileged account is not proof that the employee's permissions work.

Change one thing and test again

Remove Riley from the access group. Account for how your environment refreshes group membership and sessions, then repeat the test. Record the conditions under which you verified the changed access.

Now you have more than a static configuration.

You have demonstrated a grant, a refusal, and a change. You can explain the difference between the account existing and the account being permitted to use a particular resource.

Don't overstate what you proved. This exercise says nothing about every application, every token, or an enterprise-wide offboarding process.

Publish the requirement and the evidence together

Your project page needs a short problem statement, a small diagram, the permission matrix, and the test results.

Include one mistake you investigated when you have a genuine example. Don't manufacture a failure to make the story more interesting.

Keep the page free of credentials and identifying workplace information.

The Six-Figure IAM Career Playbook includes directory access among its three IAM lab directions and explains how to turn the work into a usable portfolio. The ebook is $9.

Start with this before adding a second domain, a cloud tenant, or another product.

Two employees and one folder give you plenty to explain when you actually test the design.