Diagnosing Windows Access Denied Errors with SDL ACL Checks

Problem: correct credentials, still access denied

You try to open a file, registry key, or network share and Windows returns error `0x80070005` (access denied). The account password works, and the user can log on, but the specific object rejects the request. The useful takeaway is that this is an authorization problem, not an authentication problem: Windows knows who the user is, but the security descriptor attached to the object does not grant the needed access.

Applies to Windows 10, Windows 11, and Windows Server 2016 and later on NTFS volumes. Security Descriptor Language (SDL, often seen as SDDL in string form) is the format Windows uses to describe object access. The descriptor contains a discretionary access control list (DACL) made of access control entries (ACEs). Each ACE grants or denies a specific right to a user or group. When a process requests access, Windows evaluates the ACEs in order.

Recognizable condition

• Error code `0x80070005` or “Access is denied” in File Explorer, PowerShell, or an application.
• The user can log on to the machine and reach other objects normally.
• The failure happens for one specific file, folder, registry key, or share path.

Cause and diagnostic table

Condition	What it means	First check
Missing allow ACE	The user or group is not listed in the DACL.	`icacls "C:\Path"`
Explicit deny ACE	A deny entry for the user or group overrides any allow entry.	`Get-Acl "C:\Path"`
Inheritance disabled	The object does not inherit permissions from its parent container.	`icacls "C:\Path"`
Ownership mismatch	Another account owns the object and has not granted access to the requester.	`Get-Acl "C:\Path" | Select-Object Owner`

Ordered checks

1. Confirm the error code. `0x80070005` indicates access denied after authentication. If you see logon failure or account lockout messages instead, stop here; that is an authentication issue.
2. Read the current ACL from an elevated Command Prompt or PowerShell session. Required permission: administrator or owner of the object. Replace `C:\Folder\Path` with the actual object:

   icacls "C:\Folder\Path"

   Look for the user or group name and the rights listed after it, such as `(F)` for full control or `(RX)` for read and execute.
3. Check for explicit deny in PowerShell:

   Get-Acl "C:\Folder\Path" | Select-Object -ExpandProperty Access | Where-Object { $_.AccessControlType -eq 'Deny' }

   If a deny ACE appears for the user or any group the user belongs to, it takes precedence over allow entries.
4. Verify inheritance. In the `icacls` output, inherited ACEs are marked. If the object is protected or inheritance is disabled, permissions from the parent folder do not apply.
5. Check ownership:

   Get-Acl "C:\Folder\Path" | Select-Object Owner

   If the owner is a different account or a deleted account, ownership may be blocking expected access.

Fixes tied to findings

Missing allow ACE

Add an allow ACE for the user or group from an elevated prompt:

icacls "C:\Folder\Path" /grant "DOMAIN\username":(R,W)

Replace `DOMAIN\username` and the path. `(R,W)` grants read and write. Risk: granting broader rights than intended can expose data. Test changes on a non-production copy first.

Explicit deny ACE

Remove or modify the deny ACE. Because `icacls /remove` removes all ACEs for a trustee, review the output before running:

icacls "C:\Folder\Path" /remove "DOMAIN\username"

Then re-add only the allow ACEs needed. Risk: removing a deny may unintentionally grant access through a broader allow ACE or group membership.

Inheritance disabled

Re-enable inheritance so the object receives parent permissions:

icacls "C:\Folder\Path" /inheritance:e

Risk: this can add unexpected allow or deny ACEs from the parent. Review the resulting ACL before granting access.

Ownership mismatch

Take ownership, then set the desired owner:

takeown /f "C:\Folder\Path" /r /d y
icacls "C:\Folder\Path" /setowner "DOMAIN\admin"

Required permission: administrator. Risk: changing ownership can affect auditing logs and compliance requirements. Document the change.

Rollback

Because ACL changes modify system state, capture the current ACL before editing:

icacls "C:\Folder\Path" /save "C:\Temp\original.acl"

To restore:

icacls "C:\Folder\Path" /restore "C:\Temp\original.acl"

This restore method applies to file-system objects. For registry keys, export the key first with `reg export` and re-import if needed.

Escalation criteria

Escalate to the security administration team when:

• The ACL looks correct but access still fails.
• The conflict involves domain Group Policy or domain local groups.
• The fix requires changing system-wide security policies or protected system directories.
• You cannot determine which deny ACE is responsible because of nested group membership.

Limitations and verification

This guide covers NTFS file-system objects, registry keys, and SMB network shares. Share permissions and NTFS permissions are evaluated separately; a share can allow access while NTFS denies it, or vice versa. Effective access also depends on the user’s group token at logon, so group membership changes may require a new logon session.

After applying a fix:

1. Re-run `icacls "C:\Folder\Path"` and confirm the user’s effective rights include the previously denied operation.
2. Attempt the original operation again. Success means the issue is resolved.
3. If it still fails, capture the exact error code and the full `icacls` output before escalating.

Do not modify production ACLs without a maintenance window and a tested rollback file. Changes to auditing or ownership may appear in security event logs; review them after the change.