How can we trigger the PowerShell file with both another user and admin privileges

Question

I want to launch the file c:\dfs-build.ps1 with the specific user and admin privileges for that I'm trying to use the below command but it's not working.

When I'm opening the powershell manually and running the below commands then it's working and able to run the commands in the c:\dfs-build.ps1 file with both svc and admin rights, but when I automate everything to trigger as soon as the server comes up then it's not working.

To suppress the yes or no pop-up while opening the PowerShell as Admin I have disabled the ConsentPromptBehaviorAdmin in Registry but still no luck. Can anyone help me that what am i doing wrong.

$cred = New-Object System.Management.Automation.PsCredential("domain\user", (ConvertTo-SecureString "pwds" -AsPlainText -Force))
$args1 = "c:\dfs-build.ps1"
Start-Process powershell.exe -Credential $cred -ArgumentList "Start-Process powershell.exe -Argumentlist '-file $args1' -verb RunAs"

Answer 1

• Your code is indeed correct in principle (though additional quoting would be needed if your script file path contained spaces).

• There are only two basic ways to avoid an (invariably interactive-only) UAC confirmation prompt:

  • Disable UAC altogether, which is strongly discouraged.

    • A comparatively less insecure - but still ill-advised - alternative is to set the ConsentPromptBehaviorAdmin registry value at HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System to 0x0: This still requires requesting elevation, but - assuming that the calling user is an administrator - automatically grants it.

  • Launch your process from a process that itself has been elevated (is running with administrative privileges), of necessity with the same user identity.

    • An indirect way to do this is via a scheduled task configured to run with elevation and allowed to be invoked on demand, but this too requires running in the context of an administrative user - see the bottom section of this answer.

Without either, your inner Start-Process call, with -Verb RunAs, will trigger a UAC confirmation prompt.

---

General tips for starting an elevated process as a different user:

You indeed need to nest Start-Process calls - the outer one to start a process with as a different user (-Credential) and the inner one to start on as that different user with elevation (with admin privileges, -Verb RunAs) - because you cannot do both in a single call.

There are pitfalls:

• If the target user identified by the credentials isn't permitted to access the caller's working directory, an error occurs (with administrator credentials, this is unlikely to occur, however).

  • The workaround is to use Start-Process's -WorkingDirectory parameter to specify a directory that the target user is allowed to access; e.g., C:\ is a safe bet.

  • However, (even with direct -Verb RunAs use) the elevated powershell.exe process will not preserve its caller's working directory and defaults to C:\Windows\System32 instead - see this answer for background information.

• Quoting gets tricky with such nested calls; a here-string (@"<newline>...><newline>"@ or @'<newline>...><newline>'@) helps a bit, because it obviates the need for escaping escaping embedded quote chars.

• The nesting of powershell.exe calls means that the outer process - whose sole purpose is to asynchronously launch the elevated process - is transitory and short-lived, which can be visually disruptive (a window pops up and closes shortly after).

  • Using -WindowStyle Hidden in the outer Start-Process call avoids this.

Therefore:

$cred = [pscredential]::new("domain\user", (ConvertTo-SecureString "pwds" -AsPlainText -Force))
$scriptFilePath = "c:\dfs-build.ps1"

Start-Process -Credential $cred -WindowStyle Hidden powershell.exe @"
  Start-Process -Verb RunAs powershell.exe '-File \"$scriptFilePath\"'
@"

Note the need to \-escape " chars. that are to be preserved as part of the command seen by powershell.exe's (implied) -Command argument after initially parsing its command line - see this answer for background information.