Windows Unprivileged - Administrator Services
Some software vendors, rather many actually, insist that their applications be run with administrator (superuser) rights, usually for one of the three reasons:
- We have always done it this way.
- We tested it with administrator rights, it works.
- We don’t know what the software does, hence it needs all the rights available.
(I ran into one vendor who had a fourth explanation: “LocalSystem is the default account for services. No reason to change it.” That same vendor also provides the perhaps buggiest software I have ever seen.)
Usually, the application also doesn’t support service accounts and hence must be run with a user account.
This means that the vendor wants us to provide a hopelessly overprivileged account with a password known to a number of people, namely all those who have reason to install or modify the application.
How can we deal with this situation?
Note that absolutely none of this is authoritative or directly based on relevant documentation. It’s mostly what I found and figured out and guessed and (in some cases) made up. Some of it may be wrong or dangerous or lead to disaster or confusion. I am not taking responsibility here for anything, not even spelling. Read and digest at your own peril!
One answer is to use the service SID to run the service with administrator rights but without using an account with administrator rights.
First, we have to grant the user account the right to log on as a service:
PS C:\GeneralTestService> & 'C:\Program Files\ABTokenTools\AccountRights.exe' legrand SeServiceLogonRight
0
SeServiceLogonRight
1
PS C:\GeneralTestService>(This can also be done using secpol.msc. The services GUI services.msc does it automatically as well.)
Then we have to create the service and equip it (but not the user account) with administrator rights.
This is done in three steps:
- Create the service (sc.exe create).
- Configure the service SID (sc.exe sidtype).
- Add the service SID to the Administrators group (Add-LocalGroupMember).
PS C:\GeneralTestService> dir .\AdminService.exe
Directory: C:\GeneralTestService
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 7/20/2024 6:57 PM 14848 AdminService.exe
PS C:\GeneralTestService> sc.exe create AdminService binpath=C:\GeneralTestService\AdminService.exe obj=.\legrand password=Password1
[SC] CreateService SUCCESS
PS C:\GeneralTestService> sc.exe qsidtype AdminService
[SC] QueryServiceConfig2 SUCCESS
SERVICE_NAME: AdminService
SERVICE_SID_TYPE: NONE
PS C:\GeneralTestService> sc.exe sidtype AdminService unrestricted
[SC] ChangeServiceConfig2 SUCCESS
PS C:\GeneralTestService> Add-LocalGroupMember Administrators "NT Service\AdminService"
PS C:\GeneralTestService>(At this point you can also try if the service that allegedly “required” administrator rights can run with a restricted SID, i.e. with read-only access to everything. See Windows Services.)
Running the AdminService, which is of course just an instance of GeneralTestService (see Windows Services) and running a PowerShell script that runs whoami /groups it is revealed that the service’s (but not the account’s) group memberships indeed include Administrators.
Test script [C:\GeneralTestService\GeneralTestService.ps1] found and it gives us this output and error:
GROUP INFORMATION
-----------------
Group Name Type SID Attributes
============================================================= ================ =============================================================== ===============================================================
Everyone Well-known group S-1-1-0 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\Local account and member of Administrators group Well-known group S-1-5-114 Mandatory group, Enabled by default, Enabled group
BUILTIN\Users Alias S-1-5-32-545 Mandatory group, Enabled by default, Enabled group
BUILTIN\Administrators Alias S-1-5-32-544 Mandatory group, Enabled by default, Enabled group, Group owner
NT AUTHORITY\SERVICE Well-known group S-1-5-6 Mandatory group, Enabled by default, Enabled group
CONSOLE LOGON Well-known group S-1-2-1 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\Authenticated Users Well-known group S-1-5-11 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\This Organization Well-known group S-1-5-15 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\Local account Well-known group S-1-5-113 Mandatory group, Enabled by default, Enabled group
NT SERVICE\AdminService Well-known group S-1-5-80-3514164294-2015598182-4216282798-1618600364-2060870650 Enabled by default, Enabled group, Group owner
LOCAL Well-known group S-1-2-0 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\NTLM Authentication Well-known group S-1-5-64-10 Mandatory group, Enabled by default, Enabled group
Mandatory Label\High Mandatory Level Label S-1-16-12288 You can see both the service SID NT SERVICE\AdminService and the Administrators group in the groups list.
But the account legrand itself is not a member of the Administrators group:
PS C:\GeneralTestService> Get-LocalGroupMember Administrators
ObjectClass Name PrincipalSource
----------- ---- ---------------
User CHAMPIGNAC\Administrator Local
User CHAMPIGNAC\SudoAdmin Local
Group NT SERVICE\AdminService Unknown
PS C:\GeneralTestService>This is not ideal, but it does avoid having another administrator account around.
Next: Network Configuration