Everyday work should not require an administrator account

UAC is enabled on the workstation. The daily user account still belongs to the local Administrators group because a business application occasionally installs updates. Support approves elevation through remote assistance, and domain administrator credentials are entered for difficult cases. An assessment records User Account Control as enabled; the operational separation between everyday work and administration barely exists.

For Active Directory, the risk comes from connecting these habits: an ordinary workstation becomes a place where powerful credentials and permissions are used. UAC can support deliberate approvals. The substantial improvement starts with removing unnecessary administrator rights and providing an administration path that avoids privileged credentials in everyday sessions.

This component covers managed, supported Windows clients and member servers using classic UAC. Domain controllers need a separately validated administration path. Windows 11 devices with Administrator protection enabled require their own assessment: its model uses a separate administrative profile and must not be equated with classic UAC.

Target state: standard users and privileges scoped to the task

The everyday account has no direct or nested local administrator membership. Email, browsing, collaboration and business applications work without routine elevation. A managed process delivers installations and system-wide updates.

Administration uses separate, individually attributable accounts with defined device and task scopes. A client administration account does not thereby receive server or domain privileges. Highly privileged AD identities are used only on approved, protected administration systems. A different username on the same untrustworthy workstation is insufficient.

Acceptance also requires a usable support process: who approves an exception, how it is implemented, how long it lasts and what evidence remains. Ordinary users' interactive elevation requests are automatically denied only after that process works.

A filtered administrator token is still an administrative identity

With classic UAC, a member of the local Administrators group normally starts with a filtered token. Elevation uses the administrative token. The account retains its administrative entitlement; its consent dialog is not a robust security boundary against malicious code within that administrative user environment.

A genuine standard user account does not hold that local administrative entitlement. This is the critical distinction. Malicious code can still access files available to the user or misuse application permissions. Least privilege limits authority; it does not remove vulnerabilities or every possible elevation path.

An elevated process also needs careful handling. Programs it starts can inherit its privileges; UAC does not approve every subsequent action individually. A permanently elevated shell is therefore unsuitable for general everyday work.

Four policies for a verifiable UAC baseline

Link a dedicated computer GPO to a pilot OU first. The path is Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options. The exact English names below identify the settings across localized consoles. These values define a deliberate project baseline, not a complete Windows security baseline.

Keep UAC enabled as the prerequisite

Set “User Account Control: Run all administrators in Admin Approval Mode” to Enabled. Its corresponding value is EnableLUA = 1. The other UAC controls depend on this setting. Changing it requires a restart; successful Group Policy processing alone does not prove effectiveness.

Check the built-in Administrator account separately. Its own Admin Approval Mode setting governs that account's behavior. Do not use it for everyday work. If a documented emergency process needs it, explicitly test its UAC behavior, access and recovery procedure.

Require deliberate administrator consent

Set “User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode” to Prompt for consent on the secure desktop. The expected value is ConsentPromptBehaviorAdmin = 2.

The authorized administrator confirms a requested elevation in the protected dialog. This is neither MFA nor independent approval by another person. The decision must match the program launched and the intended task. Frequent, unclear prompts are a reason to improve the workflow.

Use the secure desktop

Set “User Account Control: Switch to the secure desktop when prompting for elevation” to Enabled; expect PromptOnSecureDesktop = 1. The genuine elevation dialog is displayed separately from the ordinary user desktop.

This protects the dialog against certain interference from ordinary user processes. It does not certify the requested application's trustworthiness or the integrity of an already compromised device. Test existing UIAccess exceptions and the actual remote support tool for their interaction with the secure desktop.

Do not ask standard users for administrator passwords

Set “User Account Control: Behavior of the elevation prompt for standard users” to Automatically deny elevation requests; expect ConsentPromptBehaviorUser = 0. The ordinary interactive UAC path returns a denial instead of requesting administrator credentials.

This setting does not provide replacement privileges. If support currently depends on entering a password into that prompt, the workflow will fail. Software deployment, narrowly governed endpoint privilege management or a suitable IT maintenance path must work beforehand. The policy does not prevent every administrative task performed by managed services or other authorized mechanisms.

Prepare software delivery and support before removing rights

Inventory the privileged operations people actually need: installation, updates, driver changes, VPN repair, specialist application functions and emergency assistance. Distinguish applications requiring elevation during installation from those requesting it on every launch. Giving everyone persistent write access to program directories is not an appropriate repair.

Prefer approved packages delivered by the existing deployment platform. For justified individual tasks, managed elevation can authorize specific programs under defined conditions. Rules should consider verifiable program properties and protected locations. Broad approval for arbitrary installers, scripts or command interpreters would largely undo the reduction in privileges. Child processes and application updates also belong in the rule review.

Give the helpdesk a documented workflow with ownership, device scope and traceable approval. It must work outside the corporate network where operations require that capability. Sensitive AD administration still needs a protected administration workstation; a domain administrator identity is no substitute for missing client support permissions.

Roll out in small waves and verify without changing configuration

Back up existing GPO settings and document local administrator groups, including nested memberships. Select representative pilot devices with business software, mobile users and remote support. Do not include member servers or domain controllers in the same initial wave without separate validation.

Once replacement workflows are available, remove the targeted rights, process Group Policy and perform required restarts. Verify membership additions and removals in fresh sign-in sessions as well; existing tokens are not reliable evidence of the new state.

Read the four values locally without modifying configuration:

$policyPath = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System'
Get-ItemProperty -LiteralPath $policyPath -ErrorAction Stop |
    Select-Object EnableLUA, ConsentPromptBehaviorAdmin,
        ConsentPromptBehaviorUser, PromptOnSecureDesktop

The expected values, in order, are 1, 2, 0, 1. Do not treat missing values as a pass. Registry evidence also does not identify the originating GPO or, by itself, prove effective runtime behavior after a required restart.

IT should therefore inspect computer results through Group Policy Results in GPMC. Running whoami /groups in each test session shows its groups and token attributes. The Administrators SID S-1-5-32-544 marked “Deny only” in a classic administrator session indicates a filtered token; it does not mean the account has been removed from the group. These results contain internal identity information and belong in protected project evidence.

Benefits

  • Fewer permanently available privileges: A browser or business application problem initially encounters standard user permissions.
  • Clearer responsibility: Device scope, authorized identity and approved task can be specified separately.
  • Less improvised password entry: A functioning IT process reduces situations where privileged credentials are used on ordinary user desktops.
  • Better verification: Group membership, policy effect and working support procedures each have concrete acceptance criteria.

Disadvantages and limits

  • Preparation takes effort: Legacy software, update mechanisms and support procedures may need changes. Denials without an alternative cause disruption and pressure to bypass controls.
  • Operations cost more: Separate identities, protected workstations and potentially elevation software require maintenance and clear ownership.
  • Attacks remain possible: UAC does not fix exploitable operating system flaws or replace application control, patching and detection.
  • There is no complete approval ledger: Enabled UAC does not establish a comprehensive history of privileged actions. Configure suitable management logs, group change monitoring and, where appropriate, process monitoring separately.

Remote access and exceptions can undermine the design

Interactive UAC prompts and administrative network logons behave differently. Successful local denial does not prove that SMB or other management access is secured. Assess the account type, destination permissions and protocol separately.

Do not solve support failures through a blanket exemption from local account token filtering. In particular, LocalAccountTokenFilterPolicy = 1 is not a general operating baseline. Network access needs appropriate permissions and restrictions; UAC is not a universal interactive approval gate for those connections.

Other common failures include an unnoticed second group membership, competing MDM and GPO settings, or an emergency account blocked by other logon policies. Assign every exception an owner, narrow scope, expiry date and a verifiable replacement plan.

Define acceptance and rollback precisely

Acceptance covers four cases: everyday work without elevation, expected denial of a harmless elevation request by the standard user, successful managed installation and working IT maintenance with the intended account. Visually verify the secure desktop for authorized administrators. A test can stop at the prompt; no production configuration change is required.

If essential support or business operations fail, stop the next wave. Rollback explicitly restores the recorded previous values for affected devices and then verifies the session and behavior again. Unlinking the GPO or selecting Not Configured does not guarantee restoration. Globally disabling UAC or returning permanent administrator rights to every user is not an acceptable routine rollback.

Project checklist

  • [ ] Direct and inherited local administrator rights are inventoried and corrected.
  • [ ] Everyday work, client, server and AD administration are appropriately separated.
  • [ ] Software deployment, remote support and emergency access pass the pilot.
  • [ ] The four UAC values and their winning management source are verified.
  • [ ] Required restarts and fresh sign-in sessions are accounted for.
  • [ ] Inventory distinguishes classic UAC from Administrator protection.
  • [ ] Denial, approved installation and privileged maintenance have evidence.
  • [ ] Exceptions, monitoring, acceptance ownership and rollback are documented.