Invoke-Command Kerberos error

I am getting the following error using Invoke-Command on a remote host. Test-WSMan works fine to the same host and Enable-PSRemoting has been run on the remote host.

“winrm cannot process the request. The following error with error code 0x8009030e occured while using kerberos authentication”

I did not find much in google and I am by no means a Kerberos expert. Trusted hosts is set for all hosts and I can run basic powershell commands against the remote host such as “Get-WinEvent” and “Get-WmiObject” without issue.

Thanks in advance.

You should be running in a domain environment. Can you post the full line expression used.
Kerberos auth issues can come because of many reason. The one I am familiar is when the time is not in sync with client and server.

Here is the line of code:

Invoke-Command -ComputerName ‘hostname’ -ScriptBlock {$PSVersionTable.PsVersion}

I failed to point out that Test-WSMan returns valid results against the host. You mention a domain environment which is what I had expected, however, the systems are not in a domain, they are on a small Peer to peer network. I have limited access to the systems to troubleshoot. I will check the time settings as I too have seen that in the past.

Thanks for the help.

Does this small network actually have a Kerberos authentication server?

You may need to use the -Authentication parameter of Invoke-Command to specify an Authentication Mechanism other than Kerberos.

I am waiting back to hear the details on domain or not. They claim NOT, but everything I am reading points to Kerberos needing an authentication source/server. I am awaiting more details from the users, will post what I find.

FYI, the script has been working without issue in NON domain P2P and Domain environments until this issue popped up.

Kerberos requires an authentication server in order to function, however you do not necessarily have to use Kerberos as your authentication mechanism. If you have an account on the remote computer, you could simply authenticate to it directly.

The right answer for your network will depend very much on how that network is configured. It’s possible to configure systems on a network to use an authentication server on another network, in which case you might be told that this network has no Kerberos server (technically correct, because authentication requests are being forwarded to a Kerberos server on a different network). If this is the case, then there are a number of configuration mistakes that could cause problems with the path to the remote Kerberos server (routing/firewall/IP addressing/VPN tunneling/etc).

On the other hand, if this is a stand-alone P2P network that does not use authentication services provided by another network and does not have its own authentication server, then you will either have to establish an authentication server to support Kerberos or use a different authentication mechanism.

Thanks Grokkit.

I am still waiting to hear back from the users. They are right coast, I am left coast. I will post any updates I have when I have them. The part that puzzles me is the same script is working in many other locations on both P2P and Domain networks without issue.

I got a bit more detail on this issue. After working with the users that claimed “peer to peer”, it turns out they are running the script from a Domain Controller against non domain systems. They are using an account that has the same username and PW on all systems. To preface the script, it is a large script that performs a computer system security audit. I only use Remote PS when nothing else will work, almost all other remote calls are Get-WmiObject or Get-WinEvent which work without issue in this scenario.

I was able to replicate this scenario in my lab and the solution was to add -Credential Negotiate to Invoke-Command

Thanks for all your input.

Sorry, I got it wrong, meant to say the solution was to add -Authentication Negotiate, NOT -Credential.