98

I am trying to run a process as another account. I have the command:

runas "/user:WIN-CLR8YU96CL5\network service" "abwsx1.exe"

but then this asks for the password. However there is no password set for the network service.

Is what I am trying to do possible?

Micha Wiedenmann
  • 19,979
  • 21
  • 92
  • 137
Exitos
  • 29,230
  • 38
  • 123
  • 178

5 Answers5

154

Use PsExec.exe from SysInternals, running from an elevated command prompt.

e.g. this will open a new command prompt running as NETWORK SERVICE:

psexec -i -u "nt authority\network service" cmd.exe

this will run it as LOCAL SYSTEM:

psexec -i -s cmd.exe

You can verify these by running whoami from the cmd prompt.

See also:

Rory
  • 40,559
  • 52
  • 175
  • 261
  • @stej - Not for me. Try running it from an elevated command prompt, i.e. run your command prompt as Administrator. – Rory Jan 15 '15 at 16:09
  • No idea, psexec version is 2.11. I also tried it on winserver 2012 running as Azure cloud service from elevated console, but it still asks for password. – stej Jan 16 '15 at 07:59
  • Asks for password for me too. – Anderson Fortaleza Mar 30 '15 at 18:20
  • Works fine on Windows 7 and Windows Server 2008 R2. EDIT: PSExec 1.98 EDIT 2: Also 2.11 – Aaron Mason Jun 03 '15 at 05:30
  • 1
    This appears not to work on 64-bit machines. A workaround is to use [devxexec](http://serverfault.com/a/317978/64996) instead, which does work. – mellamokb Aug 11 '15 at 14:32
  • Works fine for me on 64-bit machines. – Rory Aug 11 '15 at 15:59
  • 3
    @Rory: I think I figured it out. For Network Service (at least in an Azure Role), it appears you have to specify the full exact path to cmd.exe. For some reason it doesn't have a default PATH variable or something... – mellamokb Aug 12 '15 at 05:44
  • 1
    On Windows10, this works only if run from elevated command prompt. Otherwise, 'Couldn't install PSEXESVC service:Access is denied'. – kyuss Aug 15 '19 at 05:35
17

In Task Scheduler, create a task to run the application under the NETWORK SERVICE user. You can then run the task from the command line using

schtasks /run /TN "taskname"

Where taskname is the name of your task.

mhenry1384
  • 7,538
  • 5
  • 55
  • 74
6

You can only impersonate as service account from a Windows service typically, like this post mentions:

The trick is to run your code as Local System and from there you can impersonate the service accounts by using the appropriate username with no password. One way to run your code as the Local System account is to create a command line shell by using the technique shown below (taken from this orginal post), and execute your assembly from there. Calling System.Diagnostics.Debugger.Break() in your code allows you to debug.

To create a command-line shell that runs under the local system account, open a new command line window and enter:

c:\sc create testsvc binpath= "cmd /K start" type= own type= interact

followed by:

c:\sc start testsvc

A new command window should have opened up. In that window run your application.exe - you'll see that you're now running as the built-in System user account. After you've finished testing, you can delete the test service you created by entering:

c:\sc delete testsvc

If you try to do that in your own user context, then such attempts should fail.

Michael
  • 8,362
  • 6
  • 61
  • 88
Lex Li
  • 60,503
  • 9
  • 116
  • 147
5

I have tested

PsExec -i -s cmd.exe

and

PsExec -i -u "nt authority\network service" cmd.exe

on PsExec64-v2.2, for win10-home-x64-10.0.14393 and win10-pro-x64-10.0.15063 to use normal console it's failed, use elevated console it works fine

Micha Wiedenmann
  • 19,979
  • 21
  • 92
  • 137
ybdt
  • 51
  • 1
  • 4
1

I know this is an old thread but it is the top result for this problem and I wanted to be able to run a command using PowerShell without having to install any additional tools on our Windows Server. I came up with the following PowerShell script that creates a scheduled task, runs it, and then deletes it. It is also written to allow you to run the command under different user accounts.

function InstallDotNetCoreGlobalTool($PackageId, $Action = "install", $User = "NT AUTHORITY\NETWORK SERVICE", $Password = "")
{
    $TaskName = "AzureDotNetCoreGlobalToolConfiguration"
    $Command = "dotnet.exe"
    $Arguments = "tool $Action -g " + $PackageId
    $TaskAction = New-ScheduledTaskAction -Execute $Command -Argument $Arguments

    Write-Host "Setting up scheduled task to run" $Command $Arguments

    Register-ScheduledTask -TaskName $TaskName -User $User -Action $TaskAction
    Start-ScheduledTask -TaskName $TaskName

    Write-Host ""
    Write-Host "Waiting on scheduled task to complete."

    while ((Get-ScheduledTask -TaskName $TaskName).State  -ne 'Ready') 
    {
      # keep waiting
    }

    Write-Host ""

    If((Get-ScheduledTask $TaskName | Get-ScheduledTaskInfo).LastTaskResult -eq 0)
    {
        Write-Host $PackageId $Action "completed successfully"
    }
    else
    {
        If ($Action -eq "install")
        {
            Write-Host $PackageId "failed to $Action. Ensure the proper dependencies have been installed or that it isn't already installed."
        }
        Else {
            Write-Host $PackageId "failed to $Action. It may not currently be installed."
        }        
    }

    Unregister-ScheduledTask -TaskName $TaskName -Confirm:$false
}

InstallDotNetCoreGlobalTool "Amazon.Lambda.Tools" "uninstall"
kmcbrearty
  • 71
  • 1
  • 6