I have operated in production environments with AD accounts in full-time admin mode as well as non-privileged mode (2 accounts). In a domain setting UAC can make the later tolerable by prompting you for credentials when attempting to run an application requiring greater privileges. In the XP days this was accomplished by using “Run As”. The temptation is to just turn off UAC and run as a full-time admin but I’m trying to be good and resist this temptation, especially with Windows 7 and the new security levels UAC provides.
You can find the UAC settings able to be modified via group or local policy in Computer Configuration\Security Settings\Local Policies\Security Options:
By default, Microsoft PowerShell runs in non-privileged mode, with UAC enabled, as does the command prompt. This means that if you want to run elevated commands or applications then you would need to open another session in administrative mode (right-click—>run as administrator). In UNIX this issue is addressed with the sudo command that provides temporary elevation to “super user” status to execute an otherwise restricted process. One could then define elevated accounts via the sudoers group where you can define which accounts can be used for sudo, the goal here is to not needlessly give out the root password.
We can emulate this behavior in Windows with PowerShell with the help of UAC. If you’re only looking to executed elevated processes in PowerShell without entering alternate credentials then you can ignore the UAC piece. The first step is to create a profile in PowerShell, if you haven’t already. Enter $profile in PowerShell to show the path to the profile. The MSDN link at the bottom of this entry will give more information on the various locations profiles can exist. Test-path $profile will show you if that profile exists and if it’s operational. If the test comes back false then you will need to create the profile first by executing:
new-item -path $profile -itemtype file –force
Now run the test-path command again and it should return true. To create a sudo-like command in PowerShell we’ll need to add some code to the profile. Enter notepad $profile to open the profile for editing. Paste in the following code and save. If you don’t want to use the moniker “sudo” when running an elevated command, change the alias in the last line to something of your liking.
function elevate-process
{
$file, [string]$arguments = $args;
$psi = new-object System.Diagnostics.ProcessStartInfo $file;
$psi.Arguments = $arguments;
$psi.Verb = "runas";
$psi.WorkingDirectory = get-location;
[System.Diagnostics.Process]::Start($psi);
}set-alias sudo elevate-process;
Execution Policies
By default PowerShell restricts the running of scripts for security. When you open PowerShell again now you will get an error about the profile script not being able to execute. This is because the execution policy is set to restricted as you can verify by running get-executionpolicy. Ideally your scripts would be signed by a trusted publisher so that you could individually unblock and run them. Get-help about-signing will tell you more about PowerShell script signing and execution policies. To make this script run quickly (by bypassing signing) you need to change the execution policy to RemoteSigned. Open PowerShell in admin mode and run set-executionpolicy remotesigned. Confirm the change, close PowerShell, and open it again in regular user mode.
You should no longer see any errors. Test the new functionality by running the application of your choice in elevated mode: sudo cmd. The following information will be generated in PowerShell, UAC, if you have it enabled, will ask for consent or prompt for credentials, then the command prompt will open in admin mode. Beautiful.
Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName
------- ------ ----- ----- ----- ------ -- -----------
0 1 1340 80 3 0.02 3148 cmd
References:
0 Comments