Users, security groups, and organizational units serve different purposes in Active Directory. Seeing them together in a console doesn't mean they control access in the same way.
Trace the permission decision instead of relying on the organization chart. A useful directory lab explains which identity acts, which assignment grants permission, and what the resource allows.
You don't need a large collection of departments to demonstrate this. Build a small model, test the effective behavior, and use any unexpected result to investigate the actual permission path.
Users represent the identities in your scenario
Start with a few fictional people and clear responsibilities.
For example, create a project contributor, a finance employee, and a contractor. Write down which resources each should use and which actions should be denied.
Do this before creating the accounts. Otherwise, the lab becomes an exercise in filling a directory rather than testing a requirement.
Use separate administrative and ordinary test activity where appropriate. Testing every resource with a powerful administrator account can hide the permission boundaries you're trying to understand.
Security groups help assign permissions to a set of identities
A security group can be used to grant permissions to its members.
Instead of assigning the same permission individually to several people, you can make the group part of the access model and maintain membership according to approved requirements.
Microsoft's security-group documentation explains the available group concepts and scopes. For an early lab, use a simple design you can explain rather than introducing nesting you don't understand.
A group name is not proof of its effect. Inspect where the group is used and test the resulting access.
Organizational units organize and support administration
An organizational unit can help structure directory objects, support delegated administration, and provide a place to link applicable Group Policy.
Putting a user in an OU is not the same operation as granting that user permission to a shared folder through a security group.
That distinction is worth testing. Move a fictional user between appropriately designed lab OUs and examine which behaviors change because of actual policy or delegation. Don't assume the OU name itself creates access.
Explain the configured mechanism rather than treating the directory tree as a permissions diagram.
Keep the organization chart separate from the access model
A company's departments can inform the design, but every organizational relationship doesn't need to become a direct permission rule.
A project may involve people from several departments. A finance employee may require one application role but not another. A contractor may need temporary access across a narrow resource set.
Design the lab around those requirements. Use groups and permissions to express access, and use OUs for the administrative purposes they actually serve in your setup.
This avoids a common explanation problem: pointing at a tidy tree while being unable to show why a user can open a file.
Test resource actions rather than only checking membership
Create a matrix containing the user, resource, action, and expected result. Include:
- Permitted read: The intended user can read the test resource.
- Prohibited write: The account cannot perform an action outside its requirement.
- Unauthorized user: A comparison account is denied the relevant access.
Use the actual test identities, not an administrator session, and record what happens.
If a result surprises you, inspect the relevant permission path. Direct assignments, other memberships, inheritance, and current identity context may affect the result.
Change one factor at a time so the observation has an interpretable cause. A successful screenshot produced after several unrelated changes won't explain which control mattered.
The learning goal is to understand how access is determined—not simply to create objects or memberships that look correct in the directory console.
Use the project to explain your design choices
Your portfolio can include a simple diagram, the access matrix, and a short explanation of why you separated accounts, groups, and administrative organization.
State the project's limits. A small directory example is not evidence of every enterprise design consideration.
Use the distinction between creating users and designing access as the next step once the basic relationships are clear.
The Six-Figure IAM Career Playbook includes directory-access work and guidance for turning it into career evidence. The $9 guide helps give familiar Windows objects a more deliberate IAM learning purpose.