How to Trace and Restore Missing Windows Server User Rights

Key takeaways

• and 4718.
• Correlating Event ID 4718 timestamps with WindowsUpdateClient Event ID 19 or scheduled tasks pinpoints automated updates and maintenance scripts responsible for stripping privileges.

When network users and dependent services abruptly lose remote connectivity to a Windows server despite the operating system appearing fully healthy, the failure is frequently caused by the unintended removal of the “Access this computer from the network” user right (SeNetworkLogonRight). Remote connections relying on SMB, CIFS, NetBIOS, and COM+ require this specific security assignment. Resolving the outage requires exporting current rights using secedit, identifying Group Policy overrides through gpresult, auditing Security Event IDs 4717 and 4718 under Authentication Policy Change, and correlating privilege revocations with recent cumulative updates or automated scheduled tasks before restoring authorized groups.

User rights assignment forms a cornerstone of Windows operating system security, mediating the boundary between local process execution and remote network logon sessions. When privileges are modified silently outside of standard change windows—whether by a cumulative update, an uncoordinated hardening script, or a misconfigured administrative task—the resulting failure signature often mimics catastrophic network or transport-layer outages. Systems administrators and security operations teams must adopt a structured diagnostic workflow to identify the governing policy authority, pinpoint the exact execution timestamp, and permanently restore authorized connectivity.

The Operational Impact of Missing SeNetworkLogonRight Privileges

The user right designated as “Access this computer from the network”, represented programmatically by the constant SeNetworkLogonRight, controls which security principals can authenticate across the network. According to official Microsoft documentation, this privilege is mandatory for any protocol establishing remote network sessions, including Server Message Block (SMB), Common Internet File System (CIFS), NetBIOS, and Component Object Model Plus (COM+).

Under default configurations on a Windows member server, Microsoft provisions this right to Everyone, Administrators, Users, and Backup Operators. When these entries are stripped, network-dependent operations immediately collapse. File shares become inaccessible, remote management consoles fail with access denied errors, and background service accounts cannot establish authenticated RPC sessions. Meanwhile, local console sessions, hardware health monitors, and hypervisor virtualization checks report the host as completely functional, creating significant diagnostic confusion.

This operational failure was documented across enterprise deployments of Windows Server 2022 following the installation of cumulative update KB5126655. In reported field incidents, member servers lost Authenticated Users from the privilege assignment list immediately following update installation, while in severe configurations, every group including local and domain Administrators was completely removed. When such privilege stripping occurs, conventional remediation through standard administrative sessions over the network is blocked, requiring console access or virtual machine out-of-band management.

Auditing Active Rights via Secedit Configuration Exports

Attempting to determine active user rights through the local security policy snap-in (secpol.msc) can obscure the underlying security identifier (SID) mapping. To obtain an unvarnished audit of active privileges, administrators should use the built-in secedit export command. This utility dumps the Local Security Authority database into an administrative text template file.

From an elevated PowerShell console, export the current rights configuration and extract the string corresponding to SeNetworkLogonRight:

secedit /export /cfg $env:TEMP\rights.inf /areas USER_RIGHTS
Select-String -Path $env:TEMP\rights.inf -Pattern 'SeNetworkLogonRight'

Executing this command across both an affected server and a healthy reference server allows for immediate differential analysis. In the exported configuration file, user rights entries list security principals as SIDs with a leading asterisk. For instance, the Authenticated Users built-in group appears as *S-1-5-11, while the local Administrators alias appears as *S-1-5-32-544.

If differential comparison reveals that *S-1-5-11 is absent or the entire line has been truncated, the server has suffered explicit privilege revocation. Once the exact discrepancy is established in the local configuration database, the next imperative is determining whether the setting is enforced by Active Directory Domain Services or written directly to the host security database.

Determining Group Policy Authority with Gpresult

Windows enforces a strict hierarchy of security policy processing. Any user right explicitly configured within an Active Directory Group Policy Object (GPO) linked to the server’s organizational unit (OU) will overwrite the local security policy at the next periodic Group Policy background refresh, typically occurring every 90 minutes with a randomized offset.

A quick preliminary indicator is available in the Local Security Policy graphical interface (secpol.msc) under “Local Policies” > “User Rights Assignment”. If the “Access this computer from the network” setting appears greyed out or displays a lock icon, a GPO possesses winning authority over the policy. However, to definitively identify the exact policy object, administrators must generate a computer-scoped diagnostic report using gpresult:

gpresult /scope computer /h $env:TEMP\gp.html

Opening the generated HTML report in a browser allows administrators to navigate to the “User Rights Assignment” section and locate “Access this computer from the network”. The report explicitly identifies the governing object in the “Winning GPO” column:

• Winning GPO Present: If a specific domain policy is listed, the policy originates from Active Directory. The definition within that GPO must be corrected by domain administrators, followed by executing gpupdate /force on the host.
• No Winning GPO (Local Policy Active): If the Winning GPO is listed as “Local Group Policy” or no domain GPO is specified, the privilege revocation occurred directly within the server’s local security database.

When Group Policy is ruled out as the root cause, the change was made by a local process or script executing directly on the server. Pinpointing the perpetrator requires interrogating the Windows Security event log.

Tracking Account Modifications Through Security Event Logs

Windows records additions and removals of user rights under the “Audit Authentication Policy Change” security subcategory. Specifically, granting a user right generates Event ID 4717 (“System security access was granted to an account”), while stripping a right generates Event ID 4718 (“System security access was removed from an account”).

A critical operational hurdle is that many enterprise baselines do not enable this subcategory by default. Furthermore, according to Microsoft’s Audit Authentication Policy Change documentation, this subcategory does not generate failure events. To verify whether the required auditing is active, execute:

Get the Weekly Brief

Curated analysis for tech leaders. Every Thursday.

Subscribe

auditpol /get /subcategory:"Authentication Policy Change"

If the command returns “No Auditing”, the operating system will not have logged historical changes. To capture future modifications, success auditing must be enabled immediately:

auditpol /set /subcategory:"Authentication Policy Change" /success:enable

Note that if advanced audit policies are enforced via domain GPO, this setting must be configured within the appropriate GPO to prevent it from being overridden. When auditing is active, administrators can query the Security log for relevant modification events using PowerShell:

Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4717, 4718 } |
  Select-Object TimeCreated, Id, Message | Format-List

Every logged event contains critical audit telemetry structured across three primary sections:

1. Subject: The account and security ID that executed the modification. If the change was initiated by an interactive user or service account, their identity is recorded here.
2. Account Modified: The security principal (e.g., *S-1-5-11 for Authenticated Users) that gained or lost the privilege.
3. Access Granted / Access Removed: The specific user right altered, which in this scenario must match SeNetworkLogonRight.

In automated enterprise environments, the “Subject” field in Event ID 4718 frequently reports NT AUTHORITY\SYSTEM. Microsoft documentation notes that SYSTEM is the default subject whenever changes are introduced by system services, the Group Policy client, scheduled tasks, or update installers. To determine which underlying process initiated the change under the SYSTEM context, administrators must correlate event timestamps with other system activity.

Correlating Audit Events with System Updates and Scheduled Tasks

When Event ID 4718 records a privilege revocation executed by SYSTEM, forensic triage requires aligning the exact timestamp against the system installation and maintenance timelines. A primary source of automated changes is the Windows servicing stack during patch deployment.

The WindowsUpdateClient logs package installations in the System event log under Event ID 19. Administrators can retrieve recent installation events via PowerShell:

Get-WinEvent -FilterHashtable @{ LogName = 'System'; ProviderName = 'Microsoft-Windows-WindowsUpdateClient'; Id = 19 } -MaxEvents 10 |
  Select-Object TimeCreated, Message

If the timestamp of Event ID 4718 occurs within seconds or minutes of an Event ID 19 update completion, the cumulative or quality update package is the direct source of the configuration drift. This correlation explains the observed behavior in the Windows Server 2022 KB5126655 incident reported on the DEV Community engineering blog, where post-install servicing components altered the local rights database.

If the timestamp does not align with update activity, the revocation is often driven by automated maintenance scripts or scheduled configuration tasks executing tools like secedit or the legacy ntrights utility. To identify tasks executing security commands, inspect the Task Scheduler repository:

Get-ScheduledTask | Where-Object {
  "$($_.Actions.Execute) $($_.Actions.Arguments)" -match 'secedit|ntrights|SeNetworkLogonRight'
} | Select-Object TaskPath, TaskName

Any identified task executing PowerShell or batch scripts should be reviewed for hardcoded privilege templates. Furthermore, in environments utilizing endpoint monitoring or remote management agents, process execution telemetry captured through Event Tracing for Windows (ETW) provides parent-child process lineage, enabling administrators to trace short-lived child processes that invoked secedit under the SYSTEM security context.

Remediation Strategy and Recurrence Prevention

Once the mechanism of privilege removal has been established, remediation must be executed in a manner that prevents recurrent overrides during subsequent maintenance cycles.

When Group Policy is responsible for the revocation, remediation must be performed exclusively within the Group Policy Management Console on a Domain Controller. Adding the appropriate security principals—such as Authenticated Users, Administrators, and Users—to the “Access this computer from the network” policy in the winning GPO ensures that the correction propagates domain-wide. After updating the GPO, run gpupdate /force on the target servers to refresh policy application.

When the revocation occurred within the local policy database and no domain GPO governs the setting, manual restoration is required on the local server:

1. Open the Local Security Policy console (secpol.msc) with administrative privileges.
2. Navigate to Security Settings > Local Policies > User Rights Assignment.
3. Double-click Access this computer from the network.
4. Select Add User or Group, then restore the baseline groups: Administrators, Authenticated Users, Users, and Backup Operators.
5. Apply the changes and close the console.

Validate the restored configuration by repeating the secedit /export command and verifying that the output contains the necessary SIDs. Crucially, administrators must re-execute the Event ID 4718 audit search immediately following a host reboot and again several hours later. If security principals disappear repeatedly after reboot, a persistent background service, configuration management agent, or scheduled task is actively reapplying an erroneous security baseline.

Implementation checklist

• Step 1: Validate network authentication failure. Confirm that network protocols (SMB, CIFS, RPC) fail to authenticate while local console logins remain operational.
• Step 2: Enable authentication policy change auditing. Execute auditpol /set /subcategory:"Authentication Policy Change" /success:enable to ensure privilege additions and removals are captured in the Security log.
• Step 3: Export the active user rights database. Run secedit /export /cfg $env:TEMP\rights.inf /areas USER_RIGHTS and check the SeNetworkLogonRight line for missing SIDs like *S-1-5-11 (Authenticated Users).
• Step 4: Establish policy authority via Gpresult. Generate gpresult /scope computer /h $env:TEMP\gp.html to verify whether a domain GPO or the local security database controls the “Winning GPO” assignment.
• Step 5: Query Security Event IDs 4717 and 4718. Execute Get-WinEvent filtering on IDs 4717 and 4718 to identify the exact revocation timestamp, target SID, and Subject identity.
• Step 6: Correlate timestamps with system updates and tasks. Check System Event ID 19 from WindowsUpdateClient and query Get-ScheduledTask for processes executing secedit, ntrights, or custom hardening scripts.
• Step 7: Re-apply authorized assignments. Restore missing principals in the winning domain GPO or locally via secpol.msc, followed by configuration verification using secedit.
• Step 8: Perform post-remediation persistence monitoring. Re-audit Event ID 4718 after a host reboot and subsequent maintenance windows to verify that privileges remain stable.

Sources

• Access this computer from the network – security policy setting – Windows 10 | Microsoft Learn
• 4718(S) System security access was removed from an account. – Windows 10 | Microsoft Learn
• 4717(S) System security access was granted to an account. – Windows 10 | Microsoft Learn
• Audit Authentication Policy Change – Windows 10 | Microsoft Learn
• secedit export | Microsoft Learn
• gpresult | Microsoft Learn
• Finding What Removed a User Right from a Windows Server – DEV Community