Strengthening Local Admin Security in Windows 11 with Administrator Protection

This blog will focus on a new Windows 11 insider build feature, Administrator Protection, announced in the latest Windows Insider Canary build (27718).

This feature is designed to eliminate always-on admin rights. Instead, it uses a hidden elevation mechanism to provide just-in-time privileges when needed, keeping admin rights in the shadows until required. “I am the Shadow Admin, always present but never seen.”

Introduction

Having local admin privileges on a Windows device means having unrestricted control over its configuration, making it a powerful but risky position. Compromised local admin rights are one of the primary entry points for attackers to gain control of a system. For years, User Account Control (UAC) and split tokens have been used to mitigate this risk, ensuring that elevated tasks run under a restricted administrative context. While effective, these mechanisms aren’t foolproof and can be manipulated or bypassed.

Windows 11 introduces Administrator Protection to tackle these challenges, a significant enhancement to local admin security. (They even told us how to enable it, that’s nice :))

This feature moves away from traditional split tokens and instead leverages a System Managed Admin Account (internally referenced as ShadowAdmin in the related DLL files). This account is dynamically created and linked to the primary admin account, ensuring that elevated operations run in a separate context. This new model minimizes the exposure of admin rights and offers a robust, isolated environment for privileged operations.

Before Administrator Protection

Before Administrator Protection was introduced, things worked quite differently for administrators. When an admin user logged in, Windows created two access tokens: one with full administrative rights and another with standard, limited rights (split token). To reduce risk, your account would only use the powerful admin token when absolutely necessary.

But this approach had a catch. By default, the system uses the limited token for everyday tasks like browsing the web or opening files. However, as soon as you want to install a program or make system changes, you will see the familiar UAC (User Account Control) prompt. This is Windows asking if you really want to use your hidden admin powers, the elevated token. Once you clicked “Yes,” the program you launched would have access to all your admin privileges, exposing that powerful token until the application was closed.

While this protected users from accidentally running malicious software, the admin token was still vulnerable to more sophisticated attacks. Malware could wait until a privileged action was triggered and sneak in to hijack the elevated token while it was active.

How Administrator Protection Will Change the Game

With Administrator Protection enabled Windows completely reworked how these tokens are managed. Instead of keeping the elevated admin token directly linked to your account, it moves it into a hidden, system-managed admin profile. Think of it as locking away your admin key in a secure vault that only Windows itself can access.

Now, when you attempt an elevated action, Windows doesn’t just flip a switch to activate your admin token. Instead, it switches to an isolated managed system admin account that holds the token safely. Your original account remains in its standard user state and is isolated from any admin rights. The elevated admin token is only temporarily “borrowed” for that specific task, and as soon as it’s done, it’s locked back up and the shadow account vanishes.

This new method means that even if malware lurks in your system, it can’t capture or misuse the elevated admin token. Unlike before, where the token could be hijacked mid-task, the hidden nature of the system-managed profile prevents direct access. The admin token only exists temporarily, eliminating the opportunity for malicious code to grab it.

So, while the old method used two tokens directly tied to the user account, one for normal tasks and one for admin rights. Administrator Protection separates them completely. This keeps the powerful elevated token out of sight and out of reach, making it much harder for attacks to exploit admin privileges.

Understanding the Administrator Protection Mechanism

As mentioned in the previous paragraph, Administrator Protection aims to reduce the attack surface by dynamically creating and linking a System Managed Admin Account to the local admin whenever an elevation is required. This method effectively eliminates the need for split tokens and ensures that elevated tasks are handled securely in an isolated environment. Unlike Endpoint Privilege Management (EPM), which uses a virtual account for elevation, the System Managed Admin Account is a persistent, real user account stored in the SAM database.

How to Enable Administrator Protection

You can enable Administrator Protection using either Group Policy or Intune:

1. Enabling Administrator Protection with Group Policy:
   • Open Group Policy Editor (gpedit.msc).
   • Navigate to: Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options.
   • Configure User Account Control: Configure type of Admin Approval Mode to “Admin approval mode with Administrator protection”.
   • Restart the device.

1. Enabling Administrator Protection with Intune:
   • Log into the Intune Portal.
   • Create a Settings Catalog Policy and set:
     • User Account Control Type of Admin Approval Mode: “Admin Approval Mode with Administrator Protection”.
     • User Account Control Behavior Of The Elevation Prompt: “Prompt for consent on the secure desktop”.
   • Assign the policy and restart the device.

Please Note: After changing the User Account Control behavior of the elevation prompt for administrator protection, you will need to reboot your device.

What Happens in the Background?

Once Administrator Protection is enabled, the system dynamically creates the System Managed Admin Account for each existing local admin account (Except the account managed by Windows LAPS. This account is protected and can’t be tampered with) on the device using the ShadowAdminAccount::CreateShadowAdminAccount function (samsrv.dll).

Please note: Samsrv.dll is a very important DLL file. Check out my Windows LAPS blog for more information

After enabling the Administrator protection feature, the system creates a new account named ADMIN_<randomized>. (your local admin account name) for each local admin account.

So, for example, as shown below, I had three local admins on the device: admin, admin, and test admin. An additional “shadow account,” aka System Managed Admin Account, was created for each of them.

With the account name being randomized, two specific attributes are configured in the SAM database:

1. ShadowAccountForwardLinkSid: Created under the main admin account’s registry path, linking it to the new System Managed Admin Account

1. ShadowAccountBackLinkSid: Created in the System Managed Admin Account registry path, linking it back to the main admin account.

Once created and “linked”, the ShadowAdminAccount::AddAccountToLocalAdministratorsGroup function adds the the additional System Managed Admin Account to the Local Administrators group.

This integration ensures that the System Managed Admin Account account has the necessary permissions to perform privileged operations, bypassing the need for UAC split tokens.

Summary of the System Managed Admin Account Creation Flow:

1. Randomized Naming:
   • The function ShadowAdminAccount::CreateRandomShadowAdminAccountName generates a random name corresponding to the primary admin account (e.g., ADMIN_testadmin for testadmin).
   • This ensures that each System Managed Admin Account is unique and linked to its parent admin.
2. Linking Accounts in the SAM Database:
   • During creation, a Forward Link SID is stored in the primary admin’s SAM entry, mapping it to the System Managed Admin Account.
   • Simultaneously, a Back Link SID is created in the System Managed Admin Account’s SAM entry to bind it back to the primary admin.
3. Adding to the Local Administrators Group:
   • After creation, ShadowAdminAccount::AddAccountToLocalAdministratorsGroup is called, adding the System Managed Admin Account to the Local Administrators group.
   • This ensures that the System Managed Admin Account has full administrative privileges, allowing it to execute elevated tasks without relying on split tokens.

With the System Managed Account created, can we start using it?

Elevating a Process with Administrator Protection Enabled

After enabling the administrator protection and rebooting the device, let me show you what happens when I am logged in with a local administrator account and try to run the command prompt as administrator.

You will be asked for your credentials or consent depending on the setting you configured in the user account control behavior.

Did you spot the Windows Security at the top? After entering the password and clicking on allow changes, the cmd will be opened within the System Managed Admin Account context. Shall we take a small peak at that one? But before we do, I need to explain how Appinfo.dll is involved.

Appinfo Background Information

Before diving in even deeper, let’s start with some information about Appinfo and why this file/service is pretty important in the whole elevation process

Primary Role: UAC and Elevation Requests

appinfo.dll is integral to the Windows Application Information Service (also called the “AppInfo” service), which is directly involved in UAC handling.

It governs the interaction between the User Interface Privilege Isolation (UIPI) system, token manipulation, and whether an application is run as a standard user or with elevated rights. Whenever a user or application initiates an action that requires administrative privileges, appinfo.dll evaluates the request and determines the next steps.

Launch of Consent.exe

One of its most visible roles is launching the consent.exe process, which displays the familiar UAC dialog box asking for user approval to elevate an application. I

t also decides whether to prompt for user consent, or bypass the prompt based on group policies and local settings. Shall we take a look at the elevation process now?

The Elevation Process

Initiating Elevation & Registry Check:

• When a local administrator initiates an action needing elevated permissions, Appinfo.dll checks the registry for the TypeOfAdminApprovalMode key (HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System).

• If Admin Approval Mode with Administrator Protection is enabled, Appinfo.dll knows that the elevation request should be handled by a System Managed Admin Account account, not the legacy admin approval mode.

Launching Consent.exe:

• Once the registry validation is complete, Consent.exe is launched by Appinfo.dll to handle the elevation prompt.
• The role of Consent.exe is pivotal here. It reads the linked Forward Link SID from the SAM database in the primary admin’s account path and verifies it against the Back Link SID in the System Managed Admin Account’s path

Checking the System Managed Admin Account Link:

• Consent.exe calls the function CreateShadowAdminLink to map the main admin’s token to the System Managed Admin Account’s SID.

• This establishes a secure link between the main admin and the System Managed Admin Account, ensuring that elevation operations are handled under the isolated System Managed Admin Account profile.

Switching to the System Managed Admin Account Context:

• Appinfo.dll dynamically switches the current session to the System Managed Admin Account context.

• The UAC prompt uses Admin Approval Mode with specific visual indicators like the Windows Security title and a distinct color scheme, signaling that the process runs in an isolated context.

Launching the Task Securely:

• The process is then launched under the System Managed Admin Account, ensuring no interaction with the primary admin’s context.

Security Validation via SAM Database:

• Throughout the elevation process, the system references the Forward Link SID and Back Link SID entries to ensure the request’s legitimacy.
• This validation prevents rogue processes from impersonating the System Managed Admin Account,, providing additional security by strictly isolating privileges.

Playing around with the System Managed Admin Account

Of course, I was curious if I could break into the account (as in changing the account attributes to log into Windows interactively). The first thing I did was change the System Managed Admin Account password (as I was able to change it ?).

From then on, I thought my job was done, and I could log in to the device with that account, but somehow, that failed.

As shown above, access is denied when logging in. Well, let’s add my account to the allow log-on locally (which shouldn’t be necessary as I am a local admin, but still)

From there on, I got the same error message when trying to log in to Windows, and also, runas was failing with the same error message.

So it feels like a secure solution (I need some more time to poke at it.. as I noticed that it was trying to read a certain registry key, but even changing the permissions on that one didn’t fix it)

Conclusion

The introduction of Administrator Protection and the System Managed Admin Account concept marks a fundamental shift in managing local admin rights. Microsoft mitigates many traditional UAC vulnerabilities by decoupling elevated tasks from the main user context, making the local admin a safer role. Administrator Protection sets a new standard as the security landscape evolves, transforming local admin privileges from a constant risk into a well-guarded asset.