11

A user has a PowerShell script that does some things that require administrative access on Windows Server 2012 with UAC enabled.

When they run the script as a Local Administrator, it fails with access denied. But if they elevate their permissions and run the script as an administrator, it works. So far, so good.

Now, they have a custom Windows Service that runs the PowerShell script. The Windows Service is configured to run under the same Local Administrator account (i.e., not Local System/Network Service/etc.). The script fails with access denied, as if the account isn't an administrator. On older versions of Windows, the script works fine.

How does UAC apply in the world of Windows Services? I assumed that a Windows Service that was run under a custom local administrator account would always be "elevated", but in this case it seems that isn't true.

Paul Stovell
  • 303
  • 1
  • 2
  • 8

5 Answers5

4

When they run the script as a Local Administrator, it fails with access denied.

Then this means that being a "Local Administrator" is not sufficient to run the script. This proves that "Local Administrator" does not cover the full set of rights on the machine. In the context of UAC, a "Local Administrator" does not have the full rights of an "administrator" (as seen by the OS), but, when it asks to do something which requires administrative rights, the UAC intercepts the call and instead of just unceremoniously rejecting the request with an error code, it prompts the user. If the user says "yes, go on", then the process is granted elevated rights. From the point of view of the process, everything works as if it had been a "true administrator" all along.

Services do not run in a session, but "as a service". This means that there is no user to prompt. Therefore, UAC, as configured by default, cannot grant "true administrator" rights on demand.

Apparently, you can configure UAC to never prompt, and instead grant the rights (which basically nullifies the security benefits, if any, of UAC); see for instance this blog post). A better solution would be to run the service as an account which is already a true administrator, not the cheap imitation going under the pompous name of "Local Administrator".

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • ... I can't repro. On my Windows 10v1803 box, a service configured to run with a local account (with admin rights) is launched elevated. – Harry Johnston Jul 15 '18 at 01:19
  • 2
    Incidentally, the phrase "local administrator" just means "an account with administrator rights on the local machine", as distinct from a "domain administrator". It isn't some sort of hybrid not-quite-really-admin as you suggest. – Harry Johnston Jul 15 '18 at 01:23
  • With regard to the second paragraph in this answer: There should be no need for UAC when running a service using an account that's a member of the local `Administrators` group. In this case the service would be already running elevated. – Bill_Stewart Apr 20 '21 at 16:21
  • The referred to blog post proposes a bad idea: [Using a global state to manage a local problem](https://devblogs.microsoft.com/oldnewthing/20081211-00/?p=19873) ("Oh, our app doesn't work? Disable UAC"). This is not recommended. In addition, this answer confuses "true administrator" vs "local administrator". There really isn't a difference between those two things. If you are a member of the `Administrators` group on a computer, you are an administrator on that computer. (Elevated vs. not elevated is a separate issue.) – Bill_Stewart Apr 21 '21 at 19:58
1

UAC should not affect system services. Apart from this question, I can find no evidence that it ever does, and I have tested on Windows 7, Windows 10v1607 and Windows 10v1803 without being able to reproduce the problem.

I conclude that either there is something unusual about your particular machine which is causing this to happen, or that your problem is being caused by something else, e.g., the service SID type is set to restricted, or you are running into an ACL that grants access only to INTERACTIVE.

Any future readers who are experiencing this problem are welcome to email me if they would like assistance troubleshooting the issue. My email address is in my profile.

Harry Johnston
  • 1,667
  • 10
  • 14
  • 1
    Hm, maybe powershell drops the privs, what command did you actually used to test it? – eckes Jul 16 '18 at 22:14
  • 1
    @eckes, the service was created as `sc create test1 binPath= c:\windows\system32\notepad.exe` - of course that won't actually allow the service to successfully start, but `notepad.exe` is launched and runs until the SCM times it out. That gives me plenty of time to open it with Process Explorer and examine the security token. – Harry Johnston Jul 17 '18 at 01:42
  • @HarryJohnston My testing seems to confirm this as well - see https://stackoverflow.com/questions/67110691 for how I tested using [nssm](https://nssm.cc) and a one-line batch file. I tested on Windows 10 1909. – Bill_Stewart Apr 20 '21 at 16:25
1

UAC should not affect system services.

Definitively aggree with that, thanks a lot to Harry for this clear answer : I was in doubt for a long time until now :-).

Tested today in Windows 2012R2 context and #Requires -RunAsAdministrator tagged PowerShell script :

  • When running from normal interactive session : got the following error :
.\script.ps1 : The script 'script.ps1' cannot be run because it contains a "#requires" statement
for running as Administrator. The current Windows PowerShell session is not running as Administrator. Start Windows
PowerShell by  using the Run as Administrator option, and then try running the script again.
  • When running from administrator mode interactive session (Run as administrator and then confirm in UAC) : all is OK.
  • When running from a custom Windows Service that only do PowerShell -NonInteractive -File d:\pathto\script.ps1: all is OK.

For technical details, the Windows Service is written in Go language (using golang.org/x/sys/windows/svc) : no specific manifest. It is installed through WiX (https://wixtoolset.org) with default ServiceInstall options (ownProcess + type auto) and configured to LogOn with a local administrator user account.

So, perhaps the original problem is related to the permissions set for the user account the Windows Service is login as ?

Fabien KOCIK
  • 11
  • 2
-1

If there was a shortcut to obtaining administrative access then it would be a vulnerability. A windows service requires administrative access to setup. Once upon a time under windows all process ran with administrative rights, and no one should use these old systems. A "fully patched" NT4 system can be owned remotely. So even remote unauthenticated users have administrative rights on old windows systems!

rook
  • 46,916
  • 10
  • 92
  • 181
  • I am also looking for a way to run a service as elevated user. I dont want to use the unrestricted local sytem. It would be a security feature not a bug if it was supported. – eckes Apr 19 '16 at 22:06
  • @eckes, I can't reproduce your problem. Did you ever resolve it? – Harry Johnston Jul 15 '18 at 01:19
  • Note that the video you link to shows an attack against an NT 4 system carried about five years after NT 4 went out of support. It doesn't really have anything to do with "everybody being an administrator" and the system wasn't really fully patched in any meaningful sense. – Harry Johnston Jul 15 '18 at 01:29
  • @HarryJohnston you can’t reproduce it? You mean if you start a service as a local administrator it has a unrestricted admin token? On what Windows? did you turn off UAC. No I have never resolved it. – eckes Jul 15 '18 at 19:47
  • @eckes, yes, the service process had an unrestricted token in all my tests. I've tried this on domain-joined Windows 7, 10v1607 and 10v1805 machines (with both domain and local accounts) and on a non-domain joined 10v1805 machine. Default UAC settings in all cases. (I also have access to most other in-support versions of Windows if there's a specific one you'd like me to try. Or if you'd like to do some more in-depth troubleshooting, my email address is in my profile.) – Harry Johnston Jul 15 '18 at 22:43
  • @eckes, mind you, the only possible cause I can think of is that your service's SID type has somehow gotten set to "restricted". – Harry Johnston Jul 15 '18 at 22:48
  • I entered username and password manually in the service manager, maybe you can programmatically set up a different SID – eckes Jul 15 '18 at 22:50
  • @eckes, no I did the same thing in my testing. – Harry Johnston Jul 16 '18 at 00:31
-1

When you belong to a group of local administrators on windows server or windows 7 0r 8 by default you are not given full admin token,for instance even as administrator on the machine when you run cmd.exe and click run as administrator you have to pass UAC ( secure desktop) when you say yes to the UAC prompt you are given full admin token for the process.Even explorer.exe on windows does not run with full admin rights,if you don't believe open administrative command prompt and in task manager kill explorer.exe and use this command psexec -h explorer.exe in the admin shell(cmd.exe) then when you click cmd in this new explorer.exe it will automatically run with admin rights without involving UAC,Leaving this example the above question can be solved simply by running the service under Local System Account,since this account does not belong to any security subsystem and UAC will never prompt you but do make your service non interactive and runs on Service-0x0-3e7$ windows station,it is that winstation which owns any service that loads under Local System and is non-interactive, so you are somehow safe from user tampering

Mudasir
  • 29
  • 2