Understanding elevation of non-administrative (!) users

Question

1. Introduction

Probably everybody knows that administrator accounts have a split token (provided UAC has not been disabled). That means that if you log in as a member of the Administrators group, you at first barely have more privileges than a non-administrative user. As soon as you want to do something which requires administrative privileges, the famous UAC windows appears, asking you to allow that action. If you do so, your elevated token (with all privileges assigned) is used to start the new process.

Less widely known is the fact that there are other groups than Administrators whose members have such split tokens. One of these is Backup Operators. Users which are members of that group also have split tokens, one without special privileges and an elevated one with all privileges of a Backup Operator.

2. Problem

I would be grateful if somebody could help me understand the following behavior of Windows 7, 10, Server 2008R2 and Server 2019 (version 1909) (didn't test others) when it comes to elevation of non-administrative users, especially members of the Backup Operators group.

I have a machine with the following local user accounts (no Active Directory / no domains):

peter (is member of Administrators)
Backup (is member of Backup Operators, but NOT member of Administrators)

My goal is to log onto that machine as user peter and then -from time to time- become the user Backup in its elevated version in a cmd32 shell.

This is the crucial point: Becoming the user Backup with privileges stripped (i.e. non-elevated) is trivial, but I have found no way to become that user with full privileges.

3. The part which works as expected

So first I have tested if the user Backup behaves as expected in a not-so-tricky situation. I have logged onto the console of the machine in question directly as user Backup and opened a normal cmd32 shell. As expected, I was not yet elevated there:

C:\Users\Backup>whoami
dax\backup

C:\Users\Backup>whoami /priv

PRIVILEGES INFORMATION
----------------------

Privilege Name                Description                    State
============================= ============================== ========
SeShutdownPrivilege           Shut down the system           Disabled
SeChangeNotifyPrivilege       Bypass traverse checking       Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled

C:\Users\Backup>

Then I tried to open an elevated cmd32 shell, using Nirsoft's nircmd utility, and typed in the shell:

C:\Users\Backup>"c:\Program Files\nircmd-x64\nircmd.exe" elevate c:\windows\system32\cmd.exe

C:\Users\Backup>

Again as expected, this brought up the following UAC dialog:

Please note that there is an entry for the user Backup in this dialog. I selected that entry and typed the password, which made Windows open a new cmd32 shell. In that new shell, I again checked who I was and what privileges I had:

C:\Windows\system32>whoami
dax\backup

C:\Windows\system32>whoami /priv

PRIVILEGES INFORMATION
----------------------

Privilege Name                Description                    State
============================= ============================== ========
SeBackupPrivilege             Back up files and directories  Disabled
SeRestorePrivilege            Restore files and directories  Disabled
SeShutdownPrivilege           Shut down the system           Disabled
SeChangeNotifyPrivilege       Bypass traverse checking       Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled

C:\Windows\system32>

Voilà - the miracle had happened. I now obviously had two more privileges than in the first cmd32 shell, that is SeBackupPrivilege and SeRestorePrivilege. Obviously, I had become the elevated version of the user Backup in that new cmd32 shell, with all privileges of a Backup Operator assigned.

Please note that this elevation happened for a member of the Backup operators group, not for an administrative user. I'd like to stress again that the user Backup is not a member of the Administrators group.

So far, so good - that one worked as expected.

4. The tricky part which does not work as expected

Now I wanted to extend the technique shown above. I logged all users out from the machine in question, logged on as user peter and opened a normal (non-elevated) cmd32 shell. A short check showed that I indeed was peter in that shell. From there, I opened a new cmd32 shell, thereby becoming the user Backup:

C:\Users\peter>whoami
dax\peter

C:\Users\peter>runas /user:Backup c:\windows\system32\cmd.exe
Enter the password for Backup:
Attempting to start c:\windows\system32\cmd.exe as user "DAX\Backup" ...

C:\Users\peter>

This indeed made Windows open a new cmd32 shell. A short check revealed that I indeed was Backup there, but that I had not yet been elevated (as expected):

C:\Windows\system32>whoami
dax\backup

C:\Windows\system32>whoami /priv

PRIVILEGES INFORMATION
----------------------

Privilege Name                Description                    State
============================= ============================== ========
SeShutdownPrivilege           Shut down the system           Disabled
SeChangeNotifyPrivilege       Bypass traverse checking       Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled

C:\Windows\system32>

So far, so good. Now that I was Backup in that new shell, I should have been able to open one more cmd32 shell where I would have been the elevated version of Backup, using the same command as shown in section 3. So I issued:

C:\Users\Backup>"c:\Program Files\nircmd-x64\nircmd.exe" elevate c:\windows\system32\cmd.exe

C:\Users\Backup>

But now, the following UAC prompt appeared:

Please note that the account Backup was missing from the account list in that prompt. This is where the hassle began.

First, I don't understand why the Backup account was missing in that UAC prompt at all. I could imagine it was because Backup is not a member of Administrators, but why did it work then in the situation described in section 3.?

Secondly, and the actual culprit, I obviously couldn't become the elevated version of Backup in that situation. If I selected one of the entries in that UAC prompt and entered the respective password, a new cmd32 shell appeared where I had become the elevated version of the account I had selected, so it worked somehow, but it was not what I wanted. I really wanted to become the elevated version of the Backup account there, and not the elevated version of some other account.

So I have two questions:

a) Why is the account Backup missing in the UAC prompt described in section 4, while it is showing up as expected in the UAC prompt described in section 3?

b) What steps do I have to take to make it work as intended, i.e. to open a cmd32 shell as the elevated version of the Backup user, i.e. to open a cmd32 shell where I am the user Backup and which has been assigned all privileges of the Backup Operators group, provided the user Backup is only a member of Backup Operators, but not of Administrators?

5. What I have already tried

a) I have set LocalAccountTokenFilterPolicy (see here) to 1. This didn't change anything (as expected, because it changes the behavior only for remote connections).

b) Just for testing, I have added the Backup user to the Administrators group. This made the behavior change: The UAC prompt described in section 4 now contained an entry for Backup; selecting it and typing the password made Windows open an additional cmd32 shell where I was Backup with all administrative privileges assigned.

This was (somehow) expected as well, but it was intended just for testing and is not the solution, because I want the new elevated shell to have all privileges of Backup Operators, not all privileges of Administrators.

c) In the first step described in section 4, I have opened an elevated version of the cmd32 shell (with all privileges of the Administrators group) instead of a normal one. This either did not change anything.

d) Disabling UAC at all is no option, so I didn't test it.

Now I am out of ideas.