To understand Windows permissions, test the actual resource actions with ordinary user accounts—not only with an administrator account.
One account may be able to read a file but not change it. Another may be denied entirely. Those differences are the point of the exercise.
Use an isolated Windows lab, dummy documents, and fictional users. Keep personal files and employer resources out of the experiment, then record which identity attempted each action and what actually happened.
Define two users and one clear requirement
Create a fictional project reader and a fictional user with no project access. Use a test folder containing harmless sample files.
The requirement is straightforward: the reader can open the files but cannot modify them; the other user cannot read them.
Write those expectations before changing permissions. You now have a small access matrix instead of the vague goal “make the folder secure.”
Keep the setup within an environment you can recover. Do not change permissions on system folders or remove the administrative recovery path.
Configure permissions through a clearly named group
Use a project-reader group to represent the intended membership, then inspect the folder's permissions and inheritance.
Microsoft's access-control overview explains how permissions, security principals, and inheritance affect access to Windows resources.
Check for broader inherited grants that might make your test meaningless. Do not assume the new group is the only route to the folder.
For the first exercise, you do not need a complicated set of explicit deny rules. You need a configuration whose effective access matches the stated requirement.
Test reading and modifying as separate operations
Sign in with the intended reader account and test the actions explicitly.
| Identity and action | Intended result |
|---|---|
| Approved reader opens a sample file | Allowed |
| Approved reader tries to modify and save it | Denied under the read-only requirement |
| Unapproved user tries to open the file | Denied |
Record the observed results beside the expectations. Being able to browse to a folder does not prove the user can read every file, and reading does not prove modifying is allowed.
Keep the active identity visible in your private test record. Accidentally testing with an administrator account can make a permission error look like success.
If the outcome differs from the requirement, investigate the access path and relevant permissions before changing anything. The mismatch is useful evidence to understand, not a result to hide.
Keep local access and network-share access distinct
A local folder test and a test through a network share are not identical.
If you extend the project to sharing, inspect both the share configuration and the file-system permissions. Document the route used for each test rather than mixing local and network results in one unexplained table.
Microsoft provides separate guidance for share and NTFS permissions.
You do not need to add a network share to make the first project useful. Add it when you are ready to explain the extra control boundary.
Remove membership and retest under documented conditions
Remove the reader from the project group, then establish a fresh sign-in session for the retest. Close existing resource connections as appropriate for your setup.
Record exactly what you did. Do not interpret one result as proof that every existing session or open handle would behave the same way.
This gives you a lifecycle test as well as an initial-access test.
The value of proving an action was correctly denied becomes clearer when the result follows a deliberate change rather than an unrelated failure.
Document the result in a small table
Include the test identity, attempted action, expected result, observed result, and session conditions.
Add a short explanation of the group and permission relationship. Keep screenshots limited to the evidence that supports your claim, and remove identifying information before publication.
The finished project should let someone understand why access was allowed, why it was denied, and what changed when membership was removed.
The Six-Figure IAM Career Playbook includes directory access as one of three practical IAM lab areas. The $9 guide helps connect a manageable exercise like this with role selection and career positioning, without requiring a large environment before you can demonstrate a useful skill.