AutoElevate can automatically remove local administrator privileges from interactive Windows users. This helps partners enforce least privilege, reduce the risk associated with permanently elevated accounts, and require users to request elevation only when administrative access is needed.

The setting can be applied globally, by company, by location, or to individual computers. It is disabled by default and must be configured in the AutoElevate Admin Portal. 

Important: Before enabling this feature, configure the Excluded Admin Users list for any local administrator accounts that must remain protected.

 

What Remove Admin Privileges Does

When Remove Admin Privileges is enabled and the AutoElevate agent is operating in Live or Policy mode, AutoElevate removes the currently signed-in user from the computer’s local Administrators group. 

The user must sign out and sign back in before the change is fully applied. A newly encountered user may need to complete this sign-out and sign-in process after their first session following activation of the setting. 

Local Accounts and Individual Domain Users

The feature can remove administrative privileges when an individual user account is explicitly included in the computer’s local Administrators group. For example, if a user account is directly listed as a local administrator, AutoElevate can remove that individual account from the group.

Domain Group Membership

AutoElevate does not modify domain groups or remove users from domain groups.

For example:

• A user who receives administrative rights through Domain Admins is not removed from that domain group.
• If a domain group is included in the computer’s local Administrators group, members may continue to have administrative privileges.
• Domain and Entra ID group membership must be managed separately.

Requirements

The following conditions must be met before AutoElevate removes local administrator privileges:

• The AutoElevate Windows agent is installed and checking in.
• The agent is operating in Live or Policy mode.
• The signed-in user is directly configured as a local administrator.
• The user does not match an entry in Excluded Admin Users.
• Remove Admin Privileges is enabled for the applicable settings level.

Wildcard exclusions require Windows Agent v2.11 or later. Earlier agent versions treat entries as exact account names even if wildcard guidance appears in the Admin Portal.

Before You Begin

Identify every local administrator account that must retain administrative privileges before enabling this setting.

Examples may include:

• Local recovery accounts
• Windows LAPS-managed accounts
• Dedicated support accounts
• Service accounts requiring local administrative access
• Emergency administrative accounts

Add these accounts to Excluded Admin Users before enabling automatic privilege removal.

Warning: An incorrect or nonmatching exclusion could allow AutoElevate to remove privileges from an account you intended to protect. Test exclusions before applying the setting broadly.

 

Configuring Excluded Admin Users

Add an Excluded Account

1. Sign in to the AutoElevate Admin Portal.
2. Open Settings.
3. Select Global.
4. Open Agent Security.
5. Locate Excluded Admin Users (for Remove Admin Privileges feature).
6. Select the Edit pencil icon.
7. Select Add Item.
8. Enter the Windows account name that must retain local administrator privileges.
9. Select Save.

You can also create a company, location, or computer-level setting that overrides the global configuration. More-specific settings take precedence over broader settings.

What Account Name AutoElevate Matches

AutoElevate matches exclusions against the user’s Windows SAM account name. This is the short Windows account name associated with the interactive session.

AutoElevate does not match against the:

• Email address
• User Principal Name, or UPN
• Display name
• Profile folder name
• Domain name
• Domain-qualified username

Do not enter exclusions using formats such as:

DOMAIN\Administrator
AzureAD\username
username@domain.com

Entries containing a backslash or forward slash cannot match because the domain is not included in the value evaluated by AutoElevate.

Using Wildcards in Excluded Admin Users

Beginning with Windows Agent v2.11, the Excluded Admin Users list supports wildcard patterns. Wildcards allow administrators to match several accounts with one exclusion instead of entering each account individually.

This is useful when local administrator accounts follow a consistent naming convention.

Supported Wildcard Syntax

Wildcard matching is case-insensitive. Leading and trailing spaces are removed before the comparison.

Negation patterns such as [!abc] and [^abc] are not supported.

How Patterns Are Evaluated

A pattern must match the entire Windows account name.

For example:

• admin-* matches account names beginning with admin-.
• admin-* does not match super-admin-jane.
• *admin* matches an account name containing admin anywhere in the name.

Multiple exclusions can be configured. An account is excluded when it matches any entry in the list.

Wildcard Examples

Microsoft Entra ID Accounts

On a Microsoft Entra joined device, AutoElevate still matches the short Windows account name associated with the session. It does not match the user’s email address or UPN. Windows may derive or shorten this account name from the user’s UPN. Confirm the actual Windows account name before creating an exclusion.

The existing profile-folder naming behavior is separate from wildcard evaluation. Wildcard patterns are not matched against the profile folder name.

Enabling Remove Admin Privileges

Enable the Setting Globally

1. Sign in to the AutoElevate Admin Portal.
2. Open Settings.
3. Select Global.
4. Open Agent Security.
5. Locate Remove Admin Privileges.
6. Select the Edit pencil icon.
7. Enable the setting.
8. Save the change.

The setting is applied when the Windows agent next checks in and evaluates an eligible signed-in user.

Enable the Setting for a Company or Location

Create a level setting when the configuration should apply only to a particular company or location.

1. Open Settings.
2. Select the + icon above the settings grid.
3. Select the appropriate company or location.
4. Configure Remove Admin Privileges.
5. Review the corresponding Excluded Admin Users setting.
6. Save the configuration.

More-specific settings override broader settings.

Override the Setting for Individual Computers

1. Open Computers.
2. Select the applicable computers.
3. Open the Actions menu.
4. Locate the Remove Admin Privileges options.
5. Choose the required setting.
6. Apply the change.

Use computer-level overrides only for documented exceptions. Too many individual overrides can make the effective configuration difficult to review.

What Users Should Expect

After AutoElevate removes an account from the local Administrators group, the user must sign out and sign back in before the change is fully reflected in the Windows session.

The user can continue working as a standard user and request elevation through AutoElevate when an application or administrative task requires additional privileges.

Advanced Use Cases

Windows LAPS Accounts

Organizations using a consistent Windows LAPS account prefix can protect those accounts with a wildcard.

For example:

WLapsAdmin*

Use the most specific pattern supported by your naming convention.

Dedicated Administrative Accounts

If administrative accounts follow a suffix convention such as firstname.admin, the following pattern can exclude them:

*.admin

Confirm that every matching account is intended to retain administrative privileges before using a broad pattern.

Company-Specific Exceptions

Configure exclusions at the most appropriate settings level. A company-specific exclusion should generally be configured at the company level instead of being added globally for every managed environment.

Phased Deployment

Before enabling the feature throughout an organization:

1. Confirm all required exclusions.
2. Validate the actual Windows account names.
3. Apply the setting to a limited group of computers.
4. Confirm that intended accounts retain access.
5. Confirm that standard users lose local administrator privileges.
6. Expand deployment after successful testing.

Best Practices

Use the Most Specific Pattern Possible

Prefer narrowly scoped patterns such as WLapsAdmin* over broad patterns such as *admin*. Broad patterns may exclude accounts that were not intended to retain administrative privileges.

Do Not Include a Domain

Enter only the short Windows account name or a pattern matching that name. Do not use DOMAIN\username, AzureAD\username, an email address, or a UPN.

Validate Exclusions Before Deployment

Test each exclusion on a limited group of endpoints before enabling automatic removal globally.

Review Exclusions Regularly

Periodically review the Excluded Admin Users list and remove entries that are no longer required.

Document Exceptions

Record why each exact account or wildcard pattern is excluded. This makes future security reviews and administrative handoffs easier.

Maintain Recovery Access

Confirm that the organization has an approved recovery method before removing administrative privileges broadly. Do not rely on an untested wildcard exclusion as the only protection for an emergency account.

Security and Agent Behavior

Least-Privilege Enforcement

Removing permanent local administrator membership reduces the number of accounts with continuous elevated access. Users can request temporary elevation through AutoElevate when required.

Settings Hierarchy

The effective configuration may be inherited from global, company, location, or computer-level settings. More-specific settings take precedence over broader settings. Review the complete settings hierarchy when behavior differs between computers.

Agent Version

Wildcard matching is performed by the Windows agent and requires Windows Agent v2.11 or later. Partners using earlier agent versions may see wildcard-related portal guidance while endpoints continue to evaluate exclusions as exact account names.

Removing Versus Restoring Rights

AutoElevate can remove an individual user from the local Administrators group, but this feature does not restore previously removed administrator rights. If rights must be restored, use an approved Windows, device-management, or identity-management process.

Troubleshooting

An Excluded Account Lost Administrator Privileges

Confirm the following:

• The endpoint is running a supported agent version.
• The exclusion contains only the short Windows account name.
• The entry does not include a domain, backslash, forward slash, UPN, or email address.
• The pattern matches the entire account name.
• The correct global, company, location, or computer settings are applied.
• The account receives administrative access directly rather than through an unmanaged group configuration.

A Wildcard Pattern Does Not Work

Wildcard support requires Windows Agent v2.11 or later.

If the agent version is supported:

1. Confirm the pattern matches the entire account name.
2. Add * before and after the search text when a contains match is intended.
3. Check for unsupported negation syntax.
4. Check for an incomplete bracket expression.
5. Confirm the account’s actual Windows SAM account name.

Malformed bracket patterns can fail silently. For example, user[1 is not a valid range or set and will not match the intended accounts.

A Domain-Qualified Exclusion Does Not Work

This is expected.

AutoElevate does not compare the domain as part of the exclusion. Replace entries such as:

DOMAIN\Administrator

Administrator

An Entra ID User Is Not Excluded

Do not use the user’s email address, UPN, or AzureAD\username. Determine the short Windows account name associated with the user’s active session and configure the exclusion against that value.

A User Still Has Administrator Privileges

Check whether the user receives administrative rights through a domain or Entra ID group. The feature removes individual accounts from the local Administrators group. It does not modify domain groups, Entra ID groups, or their memberships. 

The Change Has Not Taken Effect

Confirm that:

• The agent has checked in since the setting changed.
• The agent is operating in Live or Policy mode.
• The user was directly included in the local Administrators group.
• The user has signed out and signed back in.
• No more-specific setting overrides the intended configuration.

Related Articles

• Settings Overview
• UAC Levels and Windows User Account Control Settings
• User Roles and Management from the Admin Portal
• AutoElevate Features and Troubleshooting