Learn Active Directory - Access Control & Permissions

#Introduction

After episodes 13 and 14, which covered how identity is proven — via modern Kerberos and the NTLM that must be left behind — it's now time for the second side of security: authorization. Authentication answers "who are you?", authorization answers "what are you allowed to do?". In Windows, the answer to the second question is governed by permissions and access control.

Imagine AD and file servers as an office building with a layered locking system. Two types of keys work together: the building door key (share permissions), which determines who may enter the building, and the room door key (NTFS permissions), which determines who may enter a specific room. Someone with the building key but no room key can't get into the server room. Conversely, having a room key doesn't mean passing the building door. You need both — and you must understand both to avoid misconfiguration.

#NTFS Permissions: The Room Keys

NTFS permissions are filesystem-level permissions attached to folders and files on NTFS volumes. They go much deeper than just Read/Write. The basic permissions commonly used:

NTFS also supports highly granular advanced permissions — changing attributes, reading extended attributes, deleting subfolders, and more. This matters for scenarios demanding precision, such as "allowed to create files, but not delete others' files".

NTFS's strength is that it attaches to the data itself, so wherever a folder is moved or re-shared, its permissions follow. That's why NTFS is the most relied-upon authorization layer.

#Share Permissions: The Building Door Keys

Share permissions work at the network protocol level — it's the "door" users see when accessing a folder over the network. The permissions are simple: Read, Change, and Full Control. What to remember: share permissions don't apply when a user accesses the folder locally on the computer where it resides.

Because these two layers work together, the combined rule is:

• Effective permission = the strictest intersection. For network access, Windows uses the most restrictive combination of share and NTFS. So if the share grants Full Control but NTFS only grants Read, the end result is Read.
• Local access is NTFS only. When a user sits at the same computer, only NTFS applies.

The practical implication: many admins use the pattern "share wide open (Everyone: Full Control), with the real security held by NTFS". This isn't a mistake — as long as you understand NTFS is the last line of defense. What's commonly wrong is granting strict share permissions, loose NTFS, then being confused why a user can't access something they were "given permission" to.

net share DATA
icacls D:\data

#ACL, DACL, and SACL: Permission Anatomy

Behind the scenes, every secured object (folder, file, AD object, registry key) carries a security descriptor containing a list of who is allowed to do what. Its two main components:

• DACL (Discretionary Access Control List) — the list determining which accesses are allowed or denied. This is what the system uses to answer "may I or may I not?". Each row in it is called an ACE (Access Control Entry) — a single pair of who (SID) and what (right).
• SACL (System Access Control List) — the list for auditing. It doesn't govern access; it records it: tell Windows which access events to log to the security log (e.g. "log every attempt to delete a file in this folder").

An ACE contains a SID (Security Identifier) — the unique identifier of every user, group, or computer in the domain. The SID is the "national ID number" of the Windows world: names can change, but SIDs don't. That's why permissions always reference SIDs, not names — so if a user is renamed, their permissions survive.

#Inheritance and Propagation: Permissions That Descend

Inheritance is the mechanism that automatically flows parent folder permissions down to child folders. This is what keeps a folder structure clean — you set permissions once at the top, and everything below stays organized.

What you need to understand is the difference between the two permission types:

• Explicit permissions — set directly on a specific object.
• Inherited permissions — inherited from the parent and automatically follow parent changes.

When you look at a folder's properties, inherited permissions (shown dimmed/tabbed) can't be edited directly — they can only be changed at the source or by blocking inheritance. Disabling inheritance is an important tool: e.g. a secret project folder that must not receive its parent's permissions.

Deny takes precedence over Allow. When there's a conflict, Deny entries always win — even if Allow grants Full Control. This is a useful tool for hard exceptions ("everyone may read, but this account is forbidden"), yet also a classic source of confusion. Use Deny sparingly and always document it.

Get-Acl D:\data | Format-List Owner, AccessToString

#Delegating Permissions in Active Directory

Access control in Windows doesn't stop at files. AD objects themselves — users, groups, OUs — also have permissions determining who can see, create, or change what. This is what makes administration delegation possible: you can give the IT-Support team the right to create and reset user passwords in one specific OU — without making them Domain Admins.

The main tool is the Delegation of Control Wizard in Active Directory Users and Computers — or dsacls from the command line. With this wizard, you choose:

1. The folder/OU being delegated.
2. The group receiving the authority (not individual users).
3. The specific tasks allowed — e.g. "reset user passwords", "create, delete, and manage user accounts", or advanced permissions.

dsacls "OU=Karyawan,DC=corp,DC=local" /G "CORP\IT-Support:CA;Reset Password;user"

Once delegated, all the group's activity is recorded — and here auditing (episode 12) plays its part again: good delegation is always paired with good auditing.

#Ownership and Take Ownership

Every secured object has an owner — usually the user who created it. The owner holds a privilege no one else has: they can always view and change the object's permissions, even if its DACL denies everyone.

Two things about ownership:

• The owner can always change the DACL — including granting themselves full access. This is Windows' last safety net.
• Admins aren't automatically owners. Administrators can take over ownership (Take Ownership) — because administrators must always be able to access anything — but this action is usually logged and should be an exception, not a habit.

takeown /f D:\data /r /d y
icacls D:\data /setowner "CORP\Administrators" /t /c

Why does ownership matter practically? When troubleshooting "why can't I change a folder's permissions even though I'm an admin", the answer is almost always ownership. And when an attacker successfully exploits an object, ownership becomes one of the traces you must check in the audit.

#Permission Best Practices

Now that you understand the mechanics, here's a summary of habits that save production environments:

• Use groups, not users. Permissions are granted to groups; users are placed in groups. Changing group membership is far easier than repairing dozens of per-user permissions.
• Hold least privilege (episode 12) down to the file and object level.
• Audit permissions periodically — not just when there's a problem. Check for folders that are too open, groups that are no longer active, and leftover explicit permissions after structural changes.
• Document exceptions. Special permissions that are "off-pattern" must be recorded along with their reasons — otherwise they'll become a puzzle for the next admin.
• Clean up unnecessary permissions — permissions that pile up without an owner make the structure unpredictable.

#Conclusion

In this episode we dissected access control in Windows and Active Directory: the difference between NTFS permissions as data guardians and share permissions as network doors with a most-restrictive combined rule, the ACL concept with DACL and SACL along with ACEs and SIDs, the inheritance mechanism and the rule that Deny beats Allow, delegating AD object permissions via the Delegation of Control Wizard and AdminSDHolder, and ownership with Take Ownership.

The takeaway: good authorization is predictable authorization — and that predictability is born from structured permissions, simplified with groups, and documented.

In the next episode 16, we move to the mechanism that keeps all these objects and permissions consistent across the domain: Active Directory Replication — how multi-master replication, USNs, and the KCC keep every domain controller holding the same copy. Keep the momentum going!