Run as Administrator - Registry Setting?

Question

PowerShell (and other programs) offer the ability to 'Run as administrator'. Is there a registry where we could alter a setting to make this the default? Thus remove the need to right click and 'Run as Administrator'?

Solution 1

The reader who initially asked the question researched this solution using PowerShell. As you can see it adds a folder called 'runas' under the \Directory\shell.

new-Item Registry::HKEY_CLASSES_ROOT\Directory\shell\runas -Force

new-ItemProperty Registry::HKEY_CLASSES_ROOT\Directory\shell\runas -Name "(default)" -Value "Open Command Prompt as Admin" -Type string -Force

new-ItemProperty Registry::HKEY_CLASSES_ROOT\Directory\shell\runas -Name "Icon"  -Value "C:\\Windows\\System32\\imageres.dll,-78" -Type string -Force

new-Item Registry::HKEY_CLASSES_ROOT\Directory\shell\runas\command -Force

new-ItemProperty Registry::HKEY_CLASSES_ROOT\Directory\shell\runas\command -Name "(default)" -Value 'cmd.exe /k pushd %L' -type string -Force

Solution 2

I don't know about a registry setting, but you can do the following:

1. Right click on PowerShell
2. Select the Shortcut tab
3. Click on the Advanced button
4. Select Run as Administrator

This will tell the shortcut to always run as an administrator. This can be done for most shortcuts. A big benefit of this is the ability to create two shortcuts, one in administrator mode, and another in non-administrator mode.

Comments

[Guy Thomas]

I was aware of this method, and use it daily, but I request to do this via a registry setting.

[Ken White]

The question was how to run PowerShell as an admin, not "make everything run as admin". -1 for not answering the question asked. I'd give you another -1 for bad advice in general if I could - removing all security as an answer to a specific limited issue is the wrong solution.

[Ansgar Wiechers]

@KenWhite There is no difference between "PowerShell running as admin" and "everything else running as admin too". Once you have a shell running with admin privileges, the whole system is wide open. Get used to the fact. The entire UAC mumbo jumbo is just a big load of bullshit getting in the way of people who prefer to achieve acutal security by practicing LUA. Please get a clue.

[Ken White]

I disagree. There's a difference between running a single app (even PS) as an admin and disabling security for the entire OS. It's like being asked "I'm going on vacation. How can I let my friend get into my house to feed my dog?" and you answering "Just take out all the windows and remove the doors, and they won't have any trouble" instead of suggesting offering them a spare key. (And personal attacks like "Please get a clue" are inappropriate, and will get you suspended or banned if they become a habit. Please watch your manners (and language) and behave like an adult. Thanks.)

[Ansgar Wiechers]

You can disagree all day long for all I care. That doesn't change a thing about the fact, though. A shell is not just "a single application". A shell is an interface to the operating system that lets you do everything your permissions allow. And for an admin shell that is literally everything. Thus running an admin shell does mean disabling security for the entire OS.

[Nacht]

You misunderstand, Ansgar. The idea here is not restricting what is possible to do, but giving warnings when you are doing certain adminy things. It's a different kind of security than keeping intruders out - it's about keeping yourself in check.

[Ansgar Wiechers]

@Nacht That is the most ludicrous definition of computer security I have ever heard. Not to mention that with PowerShell running with admin privileges all of the time it just won't work even that way anymore.

[Andrew Savinykh]

From that point on, anything running in the user's context can run arbitrary code with admin privileges Can you explain how? I thought you needed a conscious decision to run a program via shell for that, if you are not running a program via shell while the shell is running, it's still should be secure, no?

[Ansgar Wiechers]

@zespri The question was essentially how to auto-elevate PowerShell processes every time they're launched. If PowerShell processes are auto-elevated, what would stop you from putting & "C:\path\to\malicious.exe" into a PowerShell script to get it auto-elevated?

[Andrew Savinykh]

I'm assuming that when you say "you" you mean "you as user". To that the answer is obviously "nothing". But all the same nothing is preventing you from running "C:\path\to\malicious.exe" without powershell and saying yes to the elevate prompt. In both cases the decision is yours. What am I missing?

[Ansgar Wiechers]

@zespri You're missing the part where the script is automatically elevated without an elevation prompt, meaning that any process running in the user's context (including currently unprivileged malware) can spawn processes without confirmation by creating and running PowerShell scripts. That is what UAC is supposed to prevent. BTW, you don't even need malicious.exe (that was just an example), since PowerShell can use the entire .NET and Win32 API.

[Andrew Savinykh]

But still, it's not anything running in the user's context that can run arbitrary code with admin privileges, it's limited to just whatever you choose to start in powershell. And thus you still are taking a conscious decision to a) run powershell always elevated and b) start your malware in this elevated session. I'm guessing what I don't understand is the jump from the obvious fact that everything that will run via elevated powershell will have access to the whole system to the conclusion, that UAC stop being effective for everything else not started via the elevated powershell session

[Ansgar Wiechers]

@zespri a) is the premise. b) is the automatic consequence of that premise. After a) was established anything running in the user's context can run arbitrary code with admin privileges, because PowerShell was designed to allow running arbitrary code, and the user made it to automatically run with administrative privileges. So there is no effective difference to UAC being disabled entirely.

[Brian Deragon]

To Ansgars point, for future people viewing this thread, powershell is incredibly powerful, and could be launched from any .NET application or console, and now the user would never know, and it'd be launched silently, with permission to do ANYTHING. With UAC in place, at least the user would know something was trying to launch powershell with elevated privileges and be able to stop it.