Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
I think this might be better suited for Serverfault –  Lucas Kauffman Feb 28 '13 at 12:22
This may be helpful: security.stackexchange.com/q/14236/396 –  makerofthings7 Mar 2 '13 at 18:49
add comment

2 Answers

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".

share|improve this answer
add comment

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!

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.