Invoke-Command Credential Pop Up

For the life of me, I can’t figure out why one specific Invoke-Command one liner is prompting me for credentials on a server I have admin rights to.

For example:

Invoke-command -Session $connect10 -ScriptBlock { Add-PSSnapin VMware.VimAutomation.Core }

doesn’t prompt me to enter credentials for the server defined in the $connect10 variable.

But if I run:

Invoke-command -Session $connect10 -ScriptBlock { Connect-VIServer vCenter01 -Force -Verbose }

I get a pop-up every time asking for credentials to the $connect10 session variable. I’ve tried multiple coworkers running the one liner, and they get the same popup. I really don’t want to hard code/limit who can run this unattended by specifiying a -Credential, -User, or -Password parameter in :frowning:

Update: FWIW, it also does it if I manually Enter-PSSession to that $connect10 machine and run the Connect-VIServer cmdlet…

It’s hard to tell without seeing the exact error / popup message you’re getting, but it looks like you’re probably running into the “second hop” scenario of Remoting. You’re connecting to some computer, and then from there, connecting to vCenter01. By default, PowerShell Remoting authenticates in such a way that you can’t make that second hop.

There are a few ways around that, but they all involve loosening security somewhat. The easiest solution is to configure CredSSP authentication on the client and server, but be aware that this presents a security risk. Instead of just authenticating to the remote computer, you’ll actually be sending your password hash, which will be stored there. If the remote computer is compromised, the attacker will be able to steal and use your credentials. You can find information about CredSSP just about anywhere by searching for “PowerShell Remoting” “Second Hop”. There’s a section on it in the “Secrets of PowerShell Remoting” free eBook on this site:

A more secure solution for enabling the second hop is to use Kerberos Constrained Delegation, but this requires an AD environment (with at least one Windows Server 2012 or later domain controller) and some changes to domain accounts. See for more information on this topic. (I don’t think there’s a section on this in the free remoting eBook yet. I’ll check later and add it if it’s not already there.)