0

I'm trying to set up a Windows service with the following requirements:

  • Runs as a domain account - this account has access to other shares that the process will touch
  • Has full administrative rights on the machine, past UAC - specifically needs to be able to take ownership of folders

The problem is that the process needs to take ownership of folders at some points, which is done by calling takeown /A /F <file>. This works on the command line, but only when it's explicitly Run as Administrator - being a local admin on the machine does not give full admin rights, and the account still has to go through the UAC prompt, so when running as a service we just get ERROR: The current logged on user does not have administrative privileges.. It seems like the standard way to get around UAC for a service account is to use the Local System account, but that isn't an option because then we can't access the other servers.

Is there any way to set up the service and say "Run as this account, in the context of a full administrator on the machine"? As another potential solution, is there a way to exclude a domain account from UAC on a machine? Any other solution could work as long as it runs as a service, can set folder ownership, and using a domain account. Ideally this is done without opening up big security holes, like fully disabling UAC on the machine.

Josh G
  • 644
  • 7
  • 21
  • 1
    1) Define "has full administrative rights on the machine, past UAC." 2) "Is there any way to set up the service and say 'Run as this account, in the context of a full administrator on the machine'?" As far as I know, running a service using an account that's already a member of the Administrators group already does that. 3) "Is there a way to exclude a domain account from UAC on a machine?" No. (If this were possible, malware would be sure to take advantage of it.) – Bill_Stewart Apr 20 '21 at 13:51
  • 1) I'm basing this off the linked post in the question, which stats `In the context of UAC, a "Local Administrator" does not have the full rights of an "administrator" (as seen by the OS)`, which seems to match up with the behavior I'm seeing - a user in the local administrators group still has to go through UAC, while a full admin account should not have to 2) Relates to #1 - just being in local admin still requires the account to go through UAC, which doesn't seem like it can be bypassed programatically 3) Ok thanks,seems like the only real solution for our issue is to disable UAC fully :/ – Josh G Apr 20 '21 at 14:26
  • 1
    Disabling UAC is definitely not recommended. My answer demonstrates that a service that runs using an account that's a member of the local `Administrators` group runs elevated (as I was expecting). – Bill_Stewart Apr 20 '21 at 16:28

1 Answers1

1

I am not able to reproduce your problem. Here is how I tested.

Part 1: Create sample directory with non-administrator owner

  1. Create directory C:\TestDir
  2. Disable permission inheritance and copy inherited permissions into explicit permissions
  3. Grant NT SERVICE\TrustedInstaller full control access
  4. Set owner of directory to NT SERVICE\TrustedInstaller
  5. Set Administrators and SYSTEM accounts to have read access
  6. Remove access for all other accounts

After complete, verify that, logged on as elevated administrator, I am not able to create a file in that directory.

Part 2: Create a service that takes ownership of the directory

I did this using nssm (https://nssm.cc):

  1. Create a short batch file, C:\scripts\TestService.cmd, containing the takeown command:

    takeown /F C:\TestDir /A

  2. Run nssm install and specify:

    1. Application path: C:\Windows\System32\cmd.exe
    2. Arguments: /C C:\scripts\TestService.cmd
    3. Restart action: Stop service (oneshot mode)
    4. Log on: Specify username and password of an account that's a member of the local Administrators group
    5. stdout redirection: C:\scripts\TestService-stdout.log
    6. stderr redirection: C:\scripts\TestService-stderr.log

I started the service, which executed the C:\scripts\TestService.cmd batch file. (The service stopped immediately after starting, which is expected in this case.) The standard output file C:\scripts\TestService-stdout.log contained the following lines:

C:\Windows\System32>takeown /F C:\TestDir /A

SUCCESS: The file (or folder): "C:\TestDir" now owned by the administrators group.

This experiment demonstrates that a service running using an account that's a member of the local Administrators group runs elevated (i.e., with full administrative privileges).

Bill_Stewart
  • 22,916
  • 4
  • 51
  • 62