The follow-on to the domain-join lab: the forest, domain and OU hierarchy and how to read a distinguished name, what an OU is actually for, group scopes and Microsoft's nesting recipe, effective permissions when share and NTFS disagree or a deny is involved, Group Policy precedence, and a diagnostic order for a policy that will not apply.
Subject: IT Support & Networking · 61 slides · applied lesson
Open the interactive version of this deck · Homework for this lesson
Title
IT · Windows Server
Where objects live, how groups grant access, and why a policy does not apply
Objectives
The previous session got a client joined to a domain. This one is about administering it, and every task here is doable in that same two-machine lab.
Microsoft Learn — Active Directory Domain Services overview — the reference this deck follows
Section
Section 1
Warm-up
Two minutes, from memory.
Discussion prompt
You joined a Windows 11 client to a Server 2022 domain controller. What actually changed on the client at the moment it joined?
Hint: Something was created on the server, and something changed about name resolution on the client.
Answer:
A computer account was created in the directory, and the client got a machine password it uses to authenticate to the domain.
Its DNS now has to resolve the domain's service records, or it cannot find a domain controller at all.
And domain accounts became usable at the logon screen, which is the visible part of all of the above.
Microsoft Learn — Active Directory Domain Services overview — domain join and computer accounts
Concept
Active Directory Domain Services is a directory: a database of users, computers, groups and policies, replicated between domain controllers and queried over LDAP.
domain controller — A server holding a writable copy of the directory and answering authentication requests for the domain.
Everything else in this deck is either an object in that database or a rule about who may touch one.
Microsoft Learn — Active Directory Domain Services overview — AD DS overview
Concept
A client does not know where its domain controllers are. It asks DNS, using service records published under the domain name.
Which is why a client with the wrong DNS server cannot log on, cannot apply policy, and cannot join. The error it shows is rarely about DNS, and the cause almost always is.
Microsoft Learn — Windows Server documentation — DNS requirements for AD DS
Picture it
Four steps, and the first one is the one that breaks.
Figure (svg): A four step flow from the client querying DNS for service records, through receiving the domain controller list, to Kerberos authentication, with a warning that DNS failure stops everything
First diagnostic question for almost any domain problem: what does this machine have as its DNS server?
Prediction
It worked yesterday. Nothing was changed on the server.
Predict first
What do you check first?
Correct: The client's DNS server setting.
Why: A domain member must use a DNS server that hosts the domain's records, normally the domain controller itself. A DHCP change or a manually set public resolver breaks the service-record lookup, and every symptom that follows looks like something else.
Section
Section 2
Concept
A forest is the outermost boundary and the unit of trust. A domain is a replication and policy boundary inside it. An organisational unit is a container inside a domain.
Only the first two are security boundaries. An OU exists to make administration manageable, not to keep anyone out.
Microsoft Learn — Active Directory Domain Services overview — the AD DS logical structure
Picture it
One forest, two domains, organisational units inside each.
Figure (svg): A tree from a forest down through two domains to organisational units and finally to user and computer objects
Concept
Every object has a distinguished name that spells out its position, read from the object upwards to the domain.
CN=Ada Reyes,OU=Sales,DC=corp,DC=example,DC=com| component | stands for | means here |
|---|---|---|
| CN | common name | the object itself |
| OU | organisational unit | the container it sits in |
| DC | domain component | one label of the DNS domain name |
The domain components spell corp.example.com backwards, one label at a time. Once you see that, distinguished names stop looking arbitrary.
RFC 4519 — Lightweight Directory Access Protocol (LDAP): Schema for User Applications — the attribute types used in a distinguished name
Picture it
Five components, and the direction of travel is right to left.
Figure (svg): A distinguished name broken into its five components with labels showing the object, the container and the three domain components
Notation
Same rules, a different object. Read it right to left and say out loud what each component is.
Annotate
Nested containers are read the same way as nested folders, and the nesting is exactly what decides policy precedence in section five.
RFC 4519 — Lightweight Directory Access Protocol (LDAP): Schema for User Applications — the attribute types
Concept
Two jobs, and only two: linking Group Policy, and delegating administration to someone without making them a domain admin.
It is not a group. You cannot grant a permission to an OU, and putting a user in one does not give them anything.
NIST SP 800-53 Rev. 5, control family AC (Access Control) — least privilege and separation of duties AC-6 — least privilege, which delegation exists to support
Sorting
Both look like containers of users. They do completely different jobs.
Sort into buckets
Which one does each job?
The commonest beginner mistake is building a beautiful OU structure and then wondering why nobody can reach the file share.
Worked example
Two commands, and the order matters: the container has to exist before an object can be placed in it.
Create the organisational unit
Why: The path is the distinguished name of its parent, which here is the domain root.
Create the user inside it
Why: The path parameter puts the object straight into the right container, which is much easier than moving it later.
New-ADOrganizationalUnit -Name 'Sales' -Path 'DC=corp,DC=example,DC=com'
New-ADUser -Name 'Ada Reyes' -SamAccountName 'areyes' `
-Path 'OU=Sales,DC=corp,DC=example,DC=com' `
-AccountPassword (Read-Host -AsSecureString 'Password') `
-Enabled $true| parameter | what it sets | why it matters |
|---|---|---|
| -Name | the display name | what you see in the console |
| -SamAccountName | the logon name | what the user actually types |
| -Path | the container | decides which policies apply |
| -Enabled | account state | New-ADUser creates disabled accounts by default |
Verify: that the account is enabled and in the right OU
Why: Run Get-ADUser areyes -Properties DistinguishedName,Enabled. A disabled account created by accident is the most common reason a brand-new user cannot log on.
Picture it
The new user sits under the OU you created, and its distinguished name records that.
Figure (svg): A directory tree showing the new user object inside the Sales organisational unit inside the corp domain
Which also means every policy linked to the old OU stops applying and every policy on the new one starts. Moving a user is a policy change.
Section
Section 3
Concept
A security group can be given permissions. A distribution group cannot; it exists only for mail. Choosing the wrong type is the reason a group with the right members grants nothing.
| scope | can contain | can be used |
|---|---|---|
| Global | accounts and global groups from its own domain | anywhere in the forest |
| Domain Local | accounts and groups from any domain in the forest | only in its own domain |
| Universal | accounts and groups from any domain | anywhere in the forest |
Microsoft Learn — Active Directory Domain Services overview — group scopes
Concept
Accounts go into global groups by role. Global groups go into domain local groups by resource. The domain local group is what gets the permission.
The point is that role membership and resource access change for different reasons and at different times. Nesting keeps the two independent.
Microsoft Learn — Active Directory Domain Services overview — group nesting guidance
Picture it
Four layers, each one changing for a different reason.
Figure (svg): A four step flow from a user account into a global role group, into a domain local resource group, and finally to a permission
When someone changes department you edit one global group. When a folder's access changes you edit one domain local group. Neither touches the other.
Worked example
Four steps, in the order the recipe gives.
Create the role group, global
Why: Named after the job, not after the folder. It will outlive any particular share.
Create the resource group, domain local
Why: Named after the resource and the level of access, so its purpose is unambiguous a year from now.
Nest the role group inside the resource group
Why: This is the single join between the two halves.
Grant the permission to the resource group only
Why: No user and no role group is ever named on the folder itself.
New-ADGroup -Name 'Sales-Staff' -GroupScope Global -GroupCategory Security
New-ADGroup -Name 'FS-SalesData-Modify' -GroupScope DomainLocal -GroupCategory Security
Add-ADGroupMember -Identity 'Sales-Staff' -Members 'areyes'
Add-ADGroupMember -Identity 'FS-SalesData-Modify' -Members 'Sales-Staff'| object | scope | contains | named on the folder? |
|---|---|---|---|
| areyes | - | - | no |
| Sales-Staff | Global | areyes | no |
| FS-SalesData-Modify | Domain Local | Sales-Staff | yes |
Verify: by checking the folder's permission list
Why: Only the domain local group should appear on it. If a username appears directly, the recipe has been broken and the next person to audit it will not be able to tell who has access or why.
Picture it
Compare the work when someone moves department.
Figure (svg): Two bars comparing one group edit under the nesting recipe against many folder permission edits without it
Elimination
The Sales team needs Modify on a shared folder.
Eliminate the wrong options
Which object gets the permission?
Survives elimination: A
Why: The resource group is the only object whose whole purpose is to represent access to this folder. Naming anything else on the folder mixes the two axes the recipe exists to separate.
Section
Section 4
Concept
A shared folder has share permissions, which apply only to access over the network, and NTFS permissions, which apply always.
Over the network both are evaluated and the more restrictive result wins. Locally, only NTFS applies.
Microsoft Learn — Windows Server documentation — file and folder permissions
Picture it
The two disagree. One of them decides.
Figure (svg): Two panels showing a share permission of Change and an NTFS permission of Read, with the effective network result being Read
Common practice is to set the share to Everyone Full Control and do all the real work in NTFS, precisely so there is only one place to look.
Prediction
Share permission is Read. NTFS permission is Modify. The user connects over the network.
Predict first
What can they do?
Correct: Read only.
Why: Both systems apply over the network and the more restrictive result wins. NTFS would allow modification, the share does not, so the answer is Read. Sitting at the console instead, where the share is not involved, the same user could modify.
Concept
Permissions from all of a user's groups add together. Allow entries accumulate.
With one exception: an explicit deny beats every allow. And an explicit entry on the object beats one inherited from its parent.
Microsoft Learn — Windows Server documentation — NTFS permission inheritance and precedence
Picture it
The same person, in two groups, with two different answers.
Figure (svg): Three stacked rows showing an allow from one group, a deny from another, and the effective result being no write access
Which is why blanket deny entries are discouraged: they are invisible from the group that granted the access, and they are the hardest permission problem to diagnose.
Worked example
Ada is in Sales-Staff, which is allowed Modify, and in Contractors, which is denied Write. She connects over a share set to Full Control.
Combine the NTFS allows
Why: Modify from Sales-Staff, and nothing else grants more.
Apply any explicit denies
Why: Contractors denies Write, and deny wins. Modify includes writing, so the write part is removed.
Now apply the share permission
Why: Full Control on the share restricts nothing, so it does not change the answer.
Take the more restrictive of the two
Why: NTFS is more restrictive here, so NTFS decides.
| source | grants | effect |
|---|---|---|
| Sales-Staff, NTFS | Modify | read, write, delete |
| Contractors, NTFS | Deny Write | removes write and delete |
| share | Full Control | no restriction |
| effective | - | read only |
Verify: with the Effective Access tab
Why: Windows will compute this for you on the Security tab of the folder's properties. Use it to check your reasoning rather than instead of it, because it cannot tell you why.
Picture it
Two allows, one deny, one share, and the result they combine to.
Figure (svg): Four bars showing an NTFS Modify allow, an NTFS Write deny, a Full Control share and the effective read-only result
Notice that the answer is smaller than every individual input. That is the signature of a deny, and it is why a deny is the first thing to look for.
Estimation
Do not reason it through. Guess from the shape.
Predict first
A user is in six groups. Five allow various things and one denies Write. Roughly how much of the allowed access survives?
Correct: Everything except writing.
Why: Allows accumulate, so the five grant their union. The single deny then removes writing from that union and nothing else. Denies are surgical rather than total, which is what makes them so hard to spot: most of the access still works.
Constraint
Contractors must not write to the Sales share, but they need to read it. You are not allowed to use a deny entry.
Discussion prompt
How would you arrange the groups instead, and why is that arrangement easier to audit?
Hint: A deny is undoing an allow that should not have been granted. What if it never was?
Answer:
Make two resource groups instead of one: FS-SalesData-Read and FS-SalesData-Modify, each granted its own level on the folder.
Put the contractors' role group into the read one and the staff role group into the modify one. Nobody needs a deny, because nobody was granted more than they should have in the first place.
It audits better because the folder's permission list now states the whole truth. With a deny, the list looks generous and the restriction lives somewhere else entirely.
NIST SP 800-53 Rev. 5, control family AC (Access Control) — least privilege and separation of duties AC-6 — least privilege by construction rather than by subtraction
Trap
A user cannot write to a folder, so they are added to a group that has Modify.
Add the user to another group with more access
Why: Reasonable, and it does nothing, because a deny is already in play.
Add them to two more
Why: Still nothing. Allows accumulate, but no quantity of allow ever outweighs a single deny.
Conclude that permissions are broken
Why: They are working exactly as designed, and the design is the thing that was not understood.
Find the deny first, then decide whether it should be there.
Open the Effective Access tab and read which entry is responsible
Why: It names the group the deny came from, which is the answer to the whole question.
Remove the user from that group, or remove the deny
Why: Whichever is correct depends on why the deny exists. Usually it exists for a reason nobody has written down.
Then re-check, rather than assuming
Why: One re-check costs ten seconds and confirms the change did what you meant.
Two truths and a lie
One user, several groups, a share and NTFS.
Eliminate the wrong options
Which statement is true?
Survives elimination: A
Why: Precedence has two rules: deny beats allow, and explicit beats inherited. Everything else about NTFS permissions is accumulation, and those two rules are the exceptions worth memorising.
Pattern
Six checks, in this order. Nearly every access problem falls out by step four.
The second check catches more real cases than the other five together, and it is the one people skip.
NIST SP 800-53 Rev. 5, control family AC (Access Control) — least privilege and separation of duties AC-3 — access enforcement
Check
Solve it on paper before you click.
Check your understanding
Share permission Read, NTFS permission Full Control, user connects over the network. What can they do?
Answer: A
Why: Both systems apply over the network and the more restrictive wins. The share caps access at Read regardless of how generous NTFS is.
Section
Section 5
Concept
A Group Policy object is a collection of settings. It does nothing until it is linked to a site, a domain, or an organisational unit, and it then applies to the objects inside that container.
Which means moving a user between OUs changes which policies they get, and that is by design.
Microsoft Learn — Group Policy processing and precedence — linking and scope of management
Concept
Policies apply local first, then site, then domain, then organisational units from the outside in. A later setting overwrites an earlier one.
So the OU closest to the object normally wins. Two modifiers change that: a link marked Enforced cannot be overridden, and a container marked Block Inheritance ignores everything from above unless it is Enforced.
Microsoft Learn — Group Policy processing and precedence — processing order and precedence
Picture it
Four levels, applied in order, later overwriting earlier.
Figure (svg): Five stacked boxes showing the group policy processing order from local policy through site and domain to nested organisational units
Prediction
A domain-linked policy sets the screen lock to 15 minutes. An OU-linked policy sets it to 5.
Predict first
What does a user in that OU get?
Correct: 5 minutes.
Why: The OU is processed after the domain, so its setting overwrites. Note that this has nothing to do with which value is stricter: if the OU had said 30 minutes, the user would get 30. Later wins, full stop, unless the domain link is Enforced.
Worked example
A drive-mapping policy is linked to the Sales OU. The user is in Sales. Nothing is mapped.
Force a refresh and watch for errors
Why: Policy refreshes on a timer, so a change may simply not have arrived yet.
Ask the client what it thinks it applied
Why: The report lists both the applied policies and the ones filtered out, with the reason.
Read the filtered-out reason
Why: Denied for security means the user or computer lacks Read and Apply on the policy object itself, which is how security filtering works.
Check the half you are looking at
Why: A user setting in a policy linked to an OU full of computers applies to nobody, and this is the single most common cause.
gpupdate /force
gpresult /r /scope:user
gpresult /h C:\policy-report.html| symptom in gpresult | meaning | fix |
|---|---|---|
| not listed at all | the object is not in a linked container | check which OU the object is really in |
| Denied: Security | no Read and Apply permission on the policy | fix the security filtering |
| Denied: WMI Filter | the WMI query did not match this machine | check the filter, or remove it |
| applied, but no effect | a later policy overwrote the setting | check precedence order |
Verify: that the object is in the container you think it is
Why: Get-ADUser areyes -Properties DistinguishedName. Assuming the OU rather than checking it is how this problem survives an hour of investigation.
Picture it
Two commands, and the second one is the one that answers the question.
Figure (svg): A PowerShell session running gpupdate force and then gpresult, showing one applied policy and one filtered out for security
The HTML report from gpresult /h is easier to read and shows precedence, which the text output does not.
Trap
A policy configures a user-side setting and is linked to an OU containing only computers.
Link it where the machines are
Why: Reasonable, since the machines are what you want affected.
Get no error anywhere
Why: The policy is valid, the link is valid, and the setting is simply never evaluated for anyone.
Spend an hour on security filtering
Why: Which is fine, and is not the problem.
Match the half of the policy to the kind of object in the container.
Link user settings to an OU containing users
Why: The two halves of a policy object are scoped independently and each needs the right kind of object beneath the link.
Or turn on loopback processing, deliberately
Why: That makes user settings apply based on the computer, which is what you want for kiosks and shared machines, and is a decision rather than an accident.
Check with gpresult for both scopes
Why: Run it with the user scope and the computer scope separately. Half the answer is invisible if you only look at one.
Ranking
A policy is not applying. Work through these in order.
Put in order
Why: The first three cost seconds and account for most cases. Running the tools first is tempting and usually means reading a lot of correct output about a policy that was never in scope.
Matching
Five commands worth knowing by name.
Match the pairs
Why: The fourth is the underused one: it tells you whether the DNS-based discovery from section one is working, which is the root cause behind a surprising share of problems that present as policy or authentication failures.
Socratic
Worth two minutes.
Discussion prompt
Why does Group Policy reapply every ninety minutes or so, rather than only at logon?
Hint: What is the alternative, and what would it cost the domain controllers?
Answer:
Because machines stay logged on for weeks, and a setting changed centrally has to reach them without waiting for a reboot.
The offset is randomised so that thousands of clients do not all query the domain controllers at the same instant.
Which also means a change you make now may take up to two hours to appear on a client, and gpupdate exists so you do not have to wait to test it.
Microsoft Learn — Group Policy processing and precedence — refresh intervals
Section
Section 6
Concept
Everything in this deck, in the order you would actually run it in the lab.
# 1. structure
New-ADOrganizationalUnit -Name 'Sales' -Path 'DC=corp,DC=example,DC=com'
# 2. the account
New-ADUser -Name 'Ada Reyes' -SamAccountName 'areyes' -Enabled $true `
-Path 'OU=Sales,DC=corp,DC=example,DC=com' `
-AccountPassword (Read-Host -AsSecureString 'Password')
# 3. the two groups
New-ADGroup -Name 'Sales-Staff' -GroupScope Global -GroupCategory Security
New-ADGroup -Name 'FS-SalesData-Modify' -GroupScope DomainLocal -GroupCategory Security
# 4. the nesting
Add-ADGroupMember -Identity 'Sales-Staff' -Members 'areyes'
Add-ADGroupMember -Identity 'FS-SalesData-Modify' -Members 'Sales-Staff'
# 5. verify before touching the folder
Get-ADUser areyes -Properties DistinguishedName, Enabled, MemberOf| step | creates | check it with |
|---|---|---|
| 1 | the container | Get-ADOrganizationalUnit -Filter * |
| 2 | the user, enabled, in the OU | Get-ADUser areyes -Properties Enabled |
| 3 | the role and resource groups | Get-ADGroup -Filter * |
| 4 | the single join between them | Get-ADGroupMember 'FS-SalesData-Modify' |
| 5 | nothing; it confirms | read the output |
Microsoft Learn — ActiveDirectory PowerShell module reference — every cmdlet used here
Comparison
Four choices this build made, and why.
Comparison matrix
| decision | chosen | because |
|---|---|---|
| user placed in an OU | OU=Sales | so the Sales policies apply |
| role group scope | Global | role membership is a property of the domain |
| resource group scope | Domain Local | the resource lives in this domain |
| what is named on the folder | the domain local group only | one place to look, and it is auditable |
Every one of these is reversible in five minutes now and painful in a year. That asymmetry is the argument for getting the shape right first.
Missing information
The lab version above is fine. A real deployment is not.
Discussion prompt
Name three things you would need to know that the exercise does not state.
Hint: Two of them are about people rather than objects.
Answer:
The naming convention already in use, since a second convention is worse than an imperfect first one.
Who is allowed to administer the OU, since delegation is one of the two reasons the OU exists.
What the password and account-lockout policy is, and whether it comes from the domain or a fine-grained policy.
And one more that always matters: what happens when someone leaves, because an offboarding process nobody defined is how stale accounts accumulate.
Explain it
Two sentences, out loud.
Discussion prompt
Why not just put users straight into a group and grant that group access to the folder?
Hint: What has to change when someone moves from Sales to IT, under each design?
Answer:
Because role and resource change for different reasons. Someone moving department is a role change; a folder needing tighter access is a resource change.
Nesting keeps them separate, so each change touches exactly one group and neither one grows into a list nobody understands.
Microsoft Learn — Active Directory Domain Services overview — group nesting guidance
Commit first
Answer, then rate your confidence honestly.
Predict first
A user is added to a group that grants access to a share. They try immediately and are refused. Why?
Correct: Their access token was built at logon and does not yet include the new group.
Why: Windows builds the token containing group memberships when the user logs on. A new membership does not appear in an existing session, so the user must sign out and back in. This is the single most common false alarm in access troubleshooting.
Pattern
Six rules that cover everything here.
| question | the answer to reach for |
|---|---|
| client cannot find the domain | check DNS before anything else |
| where does this object live | read the distinguished name right to left |
| what is an OU for | linking policy and delegating administration, nothing else |
| how do I grant access | account into a global group, into a domain local group, onto the resource |
| why can they not open it | check the token first, then look for a deny |
| why is the policy not applying | check the container, then the link, then the half, then gpresult |
Microsoft Learn — Active Directory Domain Services overview — the full documentation set
Check
Solve it on paper before you click.
Check your understanding
A domain-linked policy is marked Enforced and sets a setting to A. An OU-linked policy sets the same setting to B. What does a user in that OU get?
Answer: A
Why: Enforced inverts the usual order: a link marked Enforced wins over anything applied after it, and it also survives Block Inheritance on a lower container. That is the entire purpose of the flag.
Exit ticket
One honest answer, and it decides where the next session starts.
Predict first
Which of these is still murkiest?
Correct: Whichever you named is where we start.
Why: The third and fourth are the two that come up most in real work and on certification exams, and both are drillable against the lab you already built: change one thing, predict the result, then check it.
Connect it up
Twenty minutes with the lab open.
Draw it
Draw your domain: the OUs you have, the groups, and which policies link where. Then pick one shared folder and trace, on paper, exactly how one user gets their access to it.
Anywhere the trace has a gap is a place the design has a gap. Bring the drawing.
Recap
Six sections, and the two in the middle are where the certification questions and the real tickets both live.
| scenario | answer |
|---|---|
| share Read, NTFS Full Control, over the network | Read |
| share Full Control, NTFS Read, at the console | Read |
| Modify from one group, Deny Write from another | read only |
| domain sets 15 minutes, OU sets 5 | 5 minutes |
| domain Enforced sets 15, OU sets 5 | 15 minutes |
| user added to a group mid-session | sign out and back in |
Microsoft Learn — Active Directory Domain Services overview — every concept above, with the full administrative detail
Want this taught 1-on-1? Alexander tutors IT Support & Networking — $55/session, free consultation.