ACLActive DirectoryDFSRGroup PolicyHardeningSecurity

SYSVOL default permissions in Active Directory: baseline, drift, and essential controls

10 August 2026

Context

SYSVOL and NETLOGON are critical directories in any Active Directory infrastructure. They contain scripts, templates, and GPTs (Group Policy Templates) that domain clients read during every Group Policy Refresh cycle. As we have already seen, if the permissions protecting them are not correct, the operational and security risk is immediate.

The most common problem is not the initial configuration. Windows Server sets a reasonable baseline when promoting a Domain Controller. The problem is drift over time: an urgent fix applies overly broad permissions that are never revisited, a legacy tool adds a service account with Full Control and leaves it in place, or an error propagated via inheritance silently contaminates the ACLs of dozens of GPTs.

This guide defines the expected baseline, the most frequent drift signals, and the minimum checks to keep it under control.

To understand who can actually modify a GPO and how to conduct a complete assessment, the reference reading is Audit SYSVOL permissions in Active Directory: how to verify who can really modify GPOs.

Scope

This guide covers:

expected NTFS and Share permissions on SYSVOL and NETLOGON after a standard promotion;
difference between nominal permissions (visible in GUI) and effective permissions (applied via SMB);
most frequent drift patterns in enterprise environments;
PowerShell commands for quick verification and periodic review;
remediation criteria without impact on DFSR replication.

It does not cover the complete audit procedure for individual GPOs, GPMC delegation, or the GPC/GPT mechanism. For these topics, refer to the main guide on SYSVOL ACL assessment.

Structure of SYSVOL and NETLOGON

On every Domain Controller, SYSVOL is exposed both as a local path and as a network share. Below is the default, unless otherwise specified during promotion:

Local path:        C:\Windows\SYSVOL\sysvol\<domain.local>\
UNC path:          \\<domain.local>\SYSVOL\<domain.local>\
                   \\<domain.local>\NETLOGON    (alias for scripts\ subfolder)

Main subfolders:
  Policies\     -> GPT (Group Policy Template) for each GPO
  scripts\      -> Logon/logoff/startup/shutdown scripts

The NETLOGON share is an alias for the scripts\ subfolder within SYSVOL. Clients access both via SMB, so effective permissions depend on the intersection of NTFS and Share permissions.

Expected baseline: NTFS permissions

The following NTFS permissions represent the expected baseline after a standard promotion on a domain with functional level Windows Server 2008 R2 or later where DFSR replication has been implemented.

SYSVOL root (`\SYSVOL\sysvol\<domain.local>\`)

Identity	NTFS Permissions	Scope	Type
NT AUTHORITY\SYSTEM	Full Control	This folder, subfolders, and files	Explicit
BUILTIN\Administrators	Full Control	This folder, subfolders, and files	Explicit
`<DOMAIN>`\Domain Admins	Full Control	This folder, subfolders, and files	Explicit
`<DOMAIN>`\Enterprise Admins	Full Control	This folder, subfolders, and files	Explicit
`<DOMAIN>`\Enterprise Domain Controllers	Read & Execute	This folder, subfolders, and files	Explicit
NT AUTHORITY\Authenticated Users	Read & Execute, List, Read	This folder, subfolders, and files	Explicit
CREATOR OWNER	Full Control	Subfolders and files only	Special

`Policies\` subfolder and individual GPTs (`{GUID}\`)

By inheritance, the same ACLs propagate from the root to the entire Policies\ hierarchy. Each subfolder corresponding to a GPO ({GUID}\) inherits these settings, unless modified by GPO governance tools or manual intervention.

The absence of CREATOR OWNER applied to the current folder (only to subfolders and files) is correct and expected. If it appears with broader scope, it is a signal to verify.

Expected Share permissions

Share	Identity	Share Permission
SYSVOL	Everyone	Read
NETLOGON	Everyone	Read

The Everyone: Read permissions on the Share are correct by design. Write access must be controlled exclusively at the NTFS level, not at the Share level. The presence of Change or Full Control on the Share for non-system identities is always a critical signal.

Nominal permissions vs effective permissions

The NTFS+Share intersection mechanism — with real-world lab scenarios and operational impact demonstration — is covered in detail in the guide Audit SYSVOL permissions in Active Directory: how to verify who can really modify GPOs. This section serves as a quick reference for reading the baseline correctly.

On remote SMB access, the most restrictive layer between NTFS and Share always prevails:

Account	NTFS	Share SYSVOL	Remote access result
Account A	Modify	Read	Read — the Share restricts
Account B	Read	Change	Read — NTFS restricts
Account C	Full Control	Full Control	Full Control
Account D	Write	Read	Read — the Share restricts
Account E	Read & Execute	— (not listed)	Read & Execute

Consequence for baseline reading: checking only NTFS or only Share always returns an incomplete picture. The two layers must be read together.

Typical drift

These are the most frequent patterns I have personally observed in enterprise environments after months or years of operations.

1. Legacy service account with Full Control

Tools like AGPM, Quest GPOAdmin, or Quest Recovery Manager often require access to SYSVOL during installation. The service account is added with Full Control and rarely removed after a migration, tool replacement, or project dismissal.

Concrete risk: an unmonitored service account with an old or shared password that has Full Control over the entire Policies\ hierarchy.

2. Operational groups with inherited Write permissions

During an urgent situation, Modify is added to a support team group on a specific GPT folder. Inheritance propagates the permission to other GPTs not involved in the original operation. The change is never revoked.

3. Inheritance break without documentation

To isolate a specific GPT, inheritance is disabled and a custom ACL is applied. After months, no one remembers why that exception exists and the custom permission is broader than the baseline. In standard reviews, the folder appears "normal" because it does not have obviously anomalous ACLs — but the fact that inheritance is disabled is already a signal.

4. Pre-Windows 2000 Compatible Access

Origin

The Pre-Windows 2000 Compatible Access group exists in every Active Directory domain since Windows 2000. It originates from a choice made during the promotion of the first Domain Controller: the dcpromo wizard asked whether the environment should be compatible with pre-Windows 2000 applications, such as legacy RAS servers, third-party NTLM applications, or software that enumerated domain users and groups without Kerberos authentication.

If legacy compatibility was chosen, the Everyone group — and in some cases Anonymous Logon — was automatically added as a member of Pre-Windows 2000 Compatible Access. This membership remained unchanged in domains that went through subsequent upgrades without an explicit review.

What it does

The group grants its members read permissions on certain objects in Active Directory — user accounts, groups, membership attributes — that would otherwise be accessible only to authenticated accounts. Historically, it was meant to allow legacy services to query the directory without having a domain account or a valid Kerberos session.

The typical channel was the null session SMB: an anonymous connection to IPC$ that, with legacy permissions active, allowed domain enumeration without credentials. This attack surface was documented and exploited for years before it was closed by default in subsequent Windows versions.

Why it ends up on SYSVOL

In domains promoted with legacy compatibility, the SYSVOL ACL inherits permissions that include members of this group — effectively Everyone or Anonymous Logon with read access. In the most severe cases, upgrades from NT4 or Windows 2000 propagated these permissions to the entire Policies\ hierarchy without anyone removing them.

The result: the contents of GPTs (scripts, Registry.pol, security settings) are readable by anyone, including unauthenticated users if Anonymous Logon is present.

How to verify current membership

Get-ADGroupMember -Identity "Pre-Windows 2000 Compatible Access" |
    Select-Object Name, objectClass, distinguishedName |
    Format-Table -AutoSize

In a modern environment, this group should be empty or contain only accounts explicitly documented for legacy applications still in production. The presence of Everyone or Anonymous Logon is a critical finding that should be addressed immediately.

5. Accidental removal of SYSTEM

An incorrect modification during aggressive hardening can remove NT AUTHORITY\SYSTEM from the SYSVOL ACL. This does not impact direct user access, but can interfere with system operations, agentless backups, and the functioning of DFSR replication itself.

6. Everyone or Domain Users with Read+Write on the Share

During troubleshooting of a replication or client access issue, Change is set on Everyone on the SYSVOL or NETLOGON share. The problem is "resolved" this way and the permission remains indefinitely.

PowerShell quick check

Verify Share permissions

# Share permissions for SYSVOL and NETLOGON
Get-SmbShareAccess -Name SYSVOL  | Format-Table -AutoSize
Get-SmbShareAccess -Name NETLOGON | Format-Table -AutoSize

Expected output: Everyone with Read. Any Change or Full Control for non-system identities is a signal to address immediately. For Share layer analysis in a complete assessment context, including abuse scenarios, see the SYSVOL ACL assessment guide.

Verify NTFS ACL on Policies root

$domain      = $env:USERDNSDOMAIN
$policiesPath = "\\$domain\SYSVOL\$domain\Policies"

(Get-Acl -Path $policiesPath).Access |
    Select-Object IdentityReference, FileSystemRights, AccessControlType, IsInherited |
    Sort-Object IdentityReference |
    Format-Table -AutoSize

Detect Write/Modify outside the baseline

$domain      = $env:USERDNSDOMAIN
$policiesPath = "\\$domain\SYSVOL\$domain\Policies"

$baseline = @(
    "NT AUTHORITY\SYSTEM",
    "BUILTIN\Administrators",
    "$env:USERDOMAIN\Domain Admins",
    "$env:USERDOMAIN\Enterprise Admins",
    "$env:USERDOMAIN\Enterprise Domain Controllers",
    "CREATOR OWNER"
)

(Get-Acl -Path $policiesPath).Access |
    Where-Object {
        ($_.FileSystemRights -match "Write|Modify|FullControl") -and
        ($_.IdentityReference.Value -notin $baseline) -and
        ($_.AccessControlType -eq "Allow")
    } |
    Select-Object IdentityReference, FileSystemRights, IsInherited |
    Format-Table -AutoSize

If this script returns results, each row is a candidate for immediate review. Empty output is the expected result.

Detect GPTs with inheritance disabled

$domain      = $env:USERDNSDOMAIN
$policiesPath = "\\$domain\SYSVOL\$domain\Policies"

Get-ChildItem -Path $policiesPath -Directory | ForEach-Object {
    $acl = Get-Acl -Path $_.FullName
    if ($acl.AreAccessRulesProtected) {
        [PSCustomObject]@{
            GPT               = $_.Name
            Path              = $_.FullName
            InheritanceBlocked = $true
        }
    }
} | Format-Table -AutoSize

Empty output is the expected result. If folders appear with InheritanceBlocked = True, manually verify the reason and document it if legitimate.

Quick side-by-side of both layers

To have Share and NTFS on the same screen during a review:

$domain = $env:USERDNSDOMAIN

Write-Host "=== SHARE PERMISSIONS ===" -ForegroundColor Cyan
Get-SmbShareAccess -Name SYSVOL | Format-Table -AutoSize

Write-Host "=== NTFS ACL - Policies ===" -ForegroundColor Cyan
(Get-Acl -Path "\\$domain\SYSVOL\$domain\Policies").Access |
    Select-Object IdentityReference, FileSystemRights, AccessControlType, IsInherited |
    Format-Table -AutoSize

Periodic review model

A one-time verification is not sufficient. SYSVOL permissions tend to degrade over time with every urgent operational change, every new tool installation, and every team reorganization.

The recommended model includes at least three levels:

Frequency	Activity	Tool
Weekly	Compare ACL snapshot with saved baseline	PowerShell + CSV reference file
Monthly	Manual review of inheritance breaks and service accounts	PowerShell + AD review
Quarterly	Complete Share + NTFS + delegated groups membership review	Complete assessment

Save a baseline snapshot

$domain      = $env:USERDNSDOMAIN
$policiesPath = "\\$domain\SYSVOL\$domain\Policies"
$snapshotDir  = "C:\ACL-Baseline"

if (-not (Test-Path $snapshotDir)) { New-Item -ItemType Directory -Path $snapshotDir | Out-Null }

$snapshotFile = Join-Path $snapshotDir "sysvol-policies-acl-$(Get-Date -Format 'yyyyMMdd').csv"

(Get-Acl -Path $policiesPath).Access |
    Select-Object IdentityReference, FileSystemRights, AccessControlType, IsInherited |
    Export-Csv -Path $snapshotFile -NoTypeInformation -Encoding UTF8

Write-Host "Snapshot saved: $snapshotFile"

Execute this script before any change and after every intervention. Comparing two consecutive snapshots immediately highlights undocumented variations.

Compare current snapshot with reference one

$baseline = Import-Csv "C:\ACL-Baseline\sysvol-policies-acl-<APPROVED-DATE>.csv"
$current  = (Get-Acl -Path "\\$env:USERDNSDOMAIN\SYSVOL\$env:USERDNSDOMAIN\Policies").Access |
                Select-Object IdentityReference, FileSystemRights, AccessControlType, IsInherited

Compare-Object -ReferenceObject $baseline -DifferenceObject $current `
    -Property IdentityReference, FileSystemRights, AccessControlType |
    Format-Table -AutoSize

Lines marked with => indicate ACEs present in the current but not in the baseline (additions). Lines marked with <= indicate removed ACEs. Both require verification.

Remediation criteria

Removing a permission on SYSVOL requires care because it can impact:

DFSR replication between Domain Controllers;
service accounts that read scripts or GPTs in production;
clients that access NETLOGON for logon scripts.

Before intervening

Document the current ACL with a snapshot.
Identify the reason why that permission exists: it could be an active tool in production.
Verify if the identity is still active in AD (account not disabled, group with actual members).
Plan in a change window. Never on urgent production basis.
Test on a single GPT before applying to the root Policies or the entire SYSVOL hierarchy.

Removal of a specific ACE

$domain        = $env:USERDNSDOMAIN
$targetPath    = "\\$domain\SYSVOL\$domain\Policies"
$targetAccount = "DOMAIN\OldServiceAccount"

$acl = Get-Acl -Path $targetPath

$acl.Access |
    Where-Object { $_.IdentityReference -eq $targetAccount } |
    ForEach-Object { $acl.RemoveAccessRule($_) | Out-Null }

Set-Acl -Path $targetPath -AclObject $acl
Write-Host "ACE removed for: $targetAccount"

Restore inheritance on a GPT

If a GPT folder has inheritance disabled without documentation or valid reason:

$domain  = $env:USERDNSDOMAIN
$gptPath = "\\$domain\SYSVOL\$domain\Policies\{GUID-TO-REPLACE}"

$acl = Get-Acl -Path $gptPath
# SetAccessRuleProtection($false, $true): re-enables inheritance and preserves existing explicit ACEs
$acl.SetAccessRuleProtection($false, $true)
Set-Acl -Path $gptPath -AclObject $acl

Write-Host "Inheritance restored on: $gptPath"

After restoring, verify that the GPT correctly receives ACLs inherited from the root and that any remaining explicit ACEs are as expected.

Do not modify SYSVOL/NETLOGON shares without a plan

The SYSVOL and NETLOGON shares are exposed by all DCs in the domain. A modification to Share permissions does not replicate automatically via DFSR: it must be executed manually on each node or via a coordinated script. Before any intervention, verify the expected behavior on a non-critical DC in a test or staging environment.

Baseline checklist

Before declaring the baseline compliant, verify all of the following points: