Search code examples
powershellwindows-authenticationkerberospowershell-4.0invoke-command

Invoke-Command behavior clarification


I'm running into some trouble with the Invoke-Command cmdlet. I am logged into my local machine with my domain identity, which has admin rights on $server. If I manually enter my credentials, then use Invoke-Command, I get the error:

Cannot open Service Control Manager on computer ''. This operation might require other privileges.

# Works
Get-Service -ComputerName $server-ErrorAction Ignore

# Doesn't work
$cred = Get-Credential
Invoke-Command -ComputerName localhost -ScriptBlock {param($serverIPAddress) Get-Service -ComputerName $server -ErrorAction Ignore} -Credential $cred -ArgumentList $server

Is there something special about the built-in credentials that makes this work?


Solution

  • This is the classic kerberos double-hop.

    The special thing that's happening is that the local computer has your credentials. It can talk to a remote computer and prove it has the credentials, without ever sending them.

    However if the remote computer needs to access something on a third computer (second hop), it cannot prove it has the credentials (because it doesn't), so it cannot authenticate.

    This is Kerberos working as designed.

    Using Invoke-Command to localhost is still doing a remoting connection, so it still counts as a hop. The Get-Service call is a second hop.


    Consider:

    Invoke-Command -ComputerName $server -ScriptBlock { Get-Service -ErrorAction Ignore } -Credential $cred
    

    That will work (as long as powershell remoting is enabled on the remote machine).

    Otherwise, you need to enable kerberos delegation, or CredSSP, or (best if possible) rework whatever you're doing to not require a double hop.

    Be wary of CredSSP (and delegation in general).