Finding What Removed a User Right from a Windows Server

This post first appeared on the ET Ducky blog. I build ET Ducky, an RMM that reads ETW on Windows and eBPF on Linux.

When users and services can't connect to a Windows server over the network while the server itself looks healthy, check the "Access this computer from the network" user right. Microsoft's documentation says many network protocols require it, including SMB-based protocols, NetBIOS, CIFS, and COM+. Users can't connect to a member server through the network once the user right is removed for them. This post covers how to read the current list, check whether Group Policy sets it, find the account and time of the change in the Security log, and restore the user right.

A recent r/sysadmin thread describes Windows Server 2022 servers that lost Authenticated Users from "Access this computer from the network" after the October 2026 cumulative update (KB5126655), and one server that lost every entry, Administrators included. The poster had checked Group Policy and ruled it out.

Read the current list

Export the user rights from an elevated PowerShell window on the affected server and on a server that kept its list.

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

SeNetworkLogonRight is the constant name for "Access this computer from the network". The SeNetworkLogonRight line lists every account and group that holds the user right. Built-in groups appear as SIDs with a leading asterisk, such as *S-1-5-11 for Authenticated Users and *S-1-5-32-544 for Administrators. Compare the line from both servers. Microsoft lists the default on a member server as Everyone, Administrators, Users, and Backup Operators.

Check whether Group Policy sets the user right

A user right set in a GPO overwrites the local setting at the next Group Policy refresh. Open secpol.msc and go to "Local Policies" > "User Rights Assignment". A greyed out "Access this computer from the network" setting means a GPO controls it. Find which GPO with a computer report.

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

Open gp.html in a browser and find "Access this computer from the network" under "User Rights Assignment". The GPO that set it is listed in the "Winning GPO" column. When a GPO sets the user right, correct the list in that GPO. When no GPO sets it, the change was written to the local policy on the server.

Find who changed it

Windows records a change to a logon right in the Security log as event 4717, "System security access was granted to an account", or event 4718, "System security access was removed from an account". Both belong to the "Audit Authentication Policy Change" subcategory. Search for both.

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

Each event has the account that made the change under "Subject", the account or group that gained or lost the user right under "Account Modified", and the user right under "Access Granted" or "Access Removed". Look for events where the access right is SeNetworkLogonRight.

Microsoft's documentation for both events says SYSTEM usually triggers them. When the Subject is SYSTEM, a process running as SYSTEM made the change, such as the Group Policy client, a scheduled task, a hardening script that runs secedit, or a management agent. When the Subject is a user or service account, that account made the change. Match the Logon ID in the event to a 4624 logon event to get the logon type and source address of the session that made the change.

Get-WinEvent throws an error when no events match. With no 4717 or 4718 events, either nothing changed the user right in the time the Security log covers or the subcategory isn't audited. Check the audit setting. 

auditpol /get /subcategory:"Authentication Policy Change" 

When the setting is "No Auditing", turn on success auditing for the subcategory.

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

When a GPO configures advanced audit policy for the server, set the subcategory in that GPO instead. Restore the user right as described below and search for the events again after the next change.

Match the change to an update or a task

Compare the time of the 4718 events with the time the update installed. The System log records event 19 from WindowsUpdateClient for each update that installs.

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

When the 4718 events fall within minutes of the update install and the Subject is SYSTEM, the update is the likely source. Report it to Microsoft with the 4718 events and both secedit exports. When the 4718 events fall at another time, list the scheduled tasks whose command runs secedit or ntrights or mentions SeNetworkLogonRight.

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

When a task runs a PowerShell script, open the script file named in its arguments and search it for SeNetworkLogonRight.

Run the 4718 search again after a reboot and after a few hours. Accounts that disappear again after you restore them mean a process still running on the server removes them.

Restore the user right

When no GPO sets the user right, open secpol.msc, go to "Local Policies" > "User Rights Assignment", open "Access this computer from the network", and add back the groups listed on the server that kept its list. Run the secedit export and the Select-String check again to confirm the SeNetworkLogonRight line matches that server. When a GPO sets the user right, correct the list in the GPO and run gpupdate /force on the server.

Where ET Ducky shows it

I build ET Ducky. Its Windows agent reads process creation events from the kernel through ETW. The process that started secedit, PowerShell, or another tool at the time of a 4718 event shows up in the same event stream with its parent. You can open a Live Session shell from the browser without the need for a VPN and run the secedit export on each server.

You'd start a Multi-Agent Session across a server that lost the user right and one that kept it. It compares the kernel events from both to find the outlier. The raw events stay on the hosts.