The requirement sounds simple: a normal user should run applications installed by an administrator but should not change system configuration without administrator credentials.
Windows can provide that boundary, but it does not make a client PC behave exactly like Windows Server. UAC, local groups, Group Policy and application control solve different parts of the problem. A one-shot script that disables Settings, command shells, installers and registry tools all at once is difficult to test and dangerous to run remotely as SYSTEM.
Build the policy in layers and define exactly what the user must still be able to do.
Start with account separation
Maintain at least:
- one named administrative account used only for administration;
- one standard account for daily work;
- a tested recovery path protected and audited by the organization.
Remove the daily account from the local Administrators group. Do not merely turn UAC to its highest prompt level while leaving the user as an administrator; that user still possesses administrative group membership and can approve elevation under the applicable policy.
Use the built-in Local Users and Groups console or PowerShell:
Get-LocalGroupMember -Group Administrators
Remove-LocalGroupMember -Group Administrators -Member '<USER>'
Add-LocalGroupMember -Group Users -Member '<USER>'
Verify the exact account before changing it and keep an independent administrator session available during the pilot.
Why the user must sign out
Windows creates an access token at logon. The token contains the user’s identity, group memberships and privileges, and processes launched in that session receive a copy. Microsoft’s access-control model documents this behavior.
Removing a user from Administrators changes the account database, but existing processes keep their current tokens. gpupdate /force does not rebuild them. The user must sign out and sign in again; a restart also creates a new session.
Confirm after sign-in:
whoami /groups
whoami /priv
Do not kill random user processes as a substitute for logoff. A complete sign-out closes the session and creates the clean security boundary the change requires.
What UAC does—and does not do
For a standard user, an operation that requires elevation can present a credential prompt for an administrator. This protects administrative operations such as writing protected system locations or changing machine-wide configuration.
UAC does not force administrator credentials for every setting. Users can still change many per-user choices: wallpaper, accessibility preferences, application settings, browser profile data and files they own. If the organization wants those settings fixed, configure the specific policy rather than expecting UAC to decide.
Keep UAC enabled and use the secure desktop for elevation prompts. Never configure AlwaysInstallElevated; it can allow Windows Installer packages to gain elevated privileges and defeats the intended boundary.
Will administrator-installed applications still run?
Usually, yes. A program installed for all users under C:\Program Files or C:\Program Files (x86) is readable and executable by standard users while remaining protected from modification.
It can still fail when it:
- writes configuration beside its executable;
- writes to protected registry locations at normal startup;
- always requests elevation in its manifest;
- stores required data in one administrator’s profile;
- depends on a service that was not installed correctly;
- launches scripts or child executables blocked by application control.
Do not grant the user write permission to the whole application folder as a quick fix. Use Process Monitor, application logs and vendor documentation to identify the exact data path, then grant the narrowest required permission or update the application.
Define a capability matrix
Write the desired outcome before selecting policies.
| Activity | Typical standard-user result | Optional organization policy |
|---|---|---|
| Run approved installed software | Allowed | AppLocker allow rules |
| Install machine-wide software | Admin credentials required | Block MSI/script execution except managed deployment |
| Change system services or drivers | Denied/elevation required | Device-installation restrictions |
| Change per-user app settings | Allowed | App-specific policy if needed |
| Change network adapter system settings | Usually elevation required | Network policy and firewall enforcement |
| Open Settings or Control Panel | Partially allowed | Hide selected pages rather than blanket block |
| Run PowerShell or Command Prompt | Allowed by default | Restrict only after deployment tooling is assessed |
| Write to own profile | Allowed | Folder redirection, quotas or data protection |
| Browse websites | Allowed | DNS/web filtering and acceptable-use policy |
Blocking the Settings application does not secure an otherwise administrative account. Conversely, making the user standard already blocks many machine-wide changes without breaking harmless personal settings.
Use policy, not a pile of registry writes
On a standalone Pro or Enterprise device, Local Group Policy can define a consistent baseline. In a fleet, use domain Group Policy or supported MDM so policy ownership, refresh and rollback are visible.
Apply controls in small groups:
- account membership and UAC;
- Windows Update and security settings;
- Settings-page visibility;
- removable storage and device installation;
- application control;
- browser and web policy;
- auditing.
Export the baseline before editing and keep a reversal procedure. A script that sets dozens of registry values without recording their previous state cannot restore the machine reliably.
Application control with AppLocker
AppLocker can permit approved executable, installer, script, packaged-app and DLL rules. Microsoft’s current AppLocker requirements state that supported Windows 10 version 2004 and newer systems with the applicable update, and Windows 11, can enforce policies without the old edition restriction.
Start in audit mode:
- inventory the applications and child processes users need;
- create default allow rules for protected Windows and Program Files paths;
- add publisher or hash rules for approved exceptions;
- collect audit events through normal work cycles;
- correct gaps;
- enforce on a pilot group;
- retain an administrator recovery procedure.
Path rules are safe only when standard users cannot write to the allowed path. Allowing everything under a user-writable directory lets the user introduce new code.
Remote administration and “Access is denied”
In the incident, a large lockdown script was pasted into Windows Admin Center. Machine-wide registry writes failed, and a later script attempted to create a scheduled task running as SYSTEM to bypass the remote token restriction. The remote console then returned Access is denied on each line.
That is not a reason to escalate around the security boundary. Windows applies UAC restrictions to local administrator accounts used over network logons. Microsoft documents that remote local administrators can receive filtered tokens and warns that disabling this behavior increases credential-theft risk. See UAC remote restrictions.
Do not use an automatically created SYSTEM task merely to force a hardening script through WAC. It gives an unreviewed script maximum authority and can lock out the very recovery account needed to undo it.
Use one of these controlled approaches:
- apply local policy interactively during a pilot;
- deploy signed scripts through an approved endpoint-management system;
- use domain GPO or MDM with scoped groups and rollback;
- use a constrained PowerShell endpoint or Just Enough Administration design;
- schedule a reviewed package through an existing trusted deployment channel.
If LocalAccountTokenFilterPolicy is considered for a workgroup tool, limit firewall access, use unique local administrator passwords and document the increased remote-administration exposure.
Do not fight a GPO by editing its registry results
If Set-NetConnectionProfile says Network List Manager Policy prevents a change, the correct action is to inspect the effective policy and update it at the authoritative source. Deleting likely registry values or editing the current network profile only creates a temporary conflict. Policy refresh can restore the setting after reboot.
Use:
gpresult /h C:\Windows\Temp\policy-report.html
Review the report locally, identify whether policy is local, domain or MDM managed, and obtain authorization from its owner. A restriction that survives registry edits is evidence that management is functioning, not that Windows needs a more forceful bypass.
Deployment sequence
Use a reversible rollout:
- document required apps and user tasks;
- create and test the administrative recovery account;
- make the user standard and sign out;
- test normal applications;
- apply one policy group in audit mode;
- collect events and user feedback;
- enforce on a pilot;
- restart and test again;
- expand gradually;
- verify the rollback on a spare device.
Windows 10 standard support ended on October 14, 2025, so new deployments should use a supported Windows release or an applicable ESU plan during migration. A locked-down but unpatched operating system is not a secure endpoint.
The right result is not “the user cannot click anything.” It is a predictable standard-user environment in which approved applications work, administrative changes require a controlled identity, and every additional restriction has an owner, audit evidence and rollback path.