WinRM Error with Get-CimInstance

Hi,

I’m going through the CBT Ultimate training videos and have gotten to the WMI and CIM videos. I’m trying to run

[blockquote]Get-CimInstance -ClassName win32_OperatingSystem -ComputerName DC1[/blockquote] but I keep getting the same error

The error seems to say that it’s trying to use Keberos authentication but I haven’t set it up to do that and there’s no -authentication flag on the cmdlet. WinRM is running on all machines. I even went to my DC and ran the same command on all network computers and it works fine for all except the 1 I’m having problems with (Pegasus). I’ve made sure all remote features are enabled in the firewall as well. Not sure where to go from here.

Kerberos is the default auth protocol - that’s Active Directory’s native protocol. It’s the only protocol that will work without any additional setup, but it requires that (a) both machines be in the same domain, or in trusting domains, and (b) that you access the remote computer by using its canonical name from AD, rather than an IP or alias. Kerberos is the only protocol that gets used when you’re not specifying an authentication protocol.

Hi Don,

Oh okay, I didn’t know that it was using Kerberos by default. Alright, that’s fine but what I don’t understand is that why does the cmdlet work fine when I’m running it from any of the VMs in my domain. For example, I have DC1, SP1, SQL1 and PEGASUS (host computer). The first 3 can run the command without issue within each other, but it won’t work from Pegasus to any of those VMs or any of the VMs to Pegasus.

However, if I do this, it works fine:

$Session = New-CimSession -ComputerName DC1,SP1,SQL1 -Authentication Default -credential $cred
Get-CimInstance -CimSession $Session -ClassName Win32_OperatingSystem

I guess, I’m a little confused as too why only this machine needs a CimSession to work. They’re all on the same domain and given that it works for the others, I’m pretty sure I’m using the correct canonical name. I also disabled the firewall completely on Pegasus to see if it was that, but no change, same error.

Previously, you were using implicit credentials, now you’re using explicit credentials.

The command you’re running is the same as (changed authentication from default to kerberos):

$Session = New-CimSession -ComputerName DC1,SP1,SQL1 -Authentication Kerberos -credential $cred
Get-CimInstance -CimSession $Session -ClassName Win32_OperatingSystem

I imagine if you run (authentication as kerberos but no credentials provided, i.e., implicit credentials)…

$Session = New-CimSession -ComputerName DC1,SP1,SQL1 -Authentication Kerberos
Get-CimInstance -CimSession $Session -ClassName Win32_OperatingSystem

It will fail.

Who are you logged in as on Pegasus? We can see it’s administrator, but is it the domain administrator or the local administrator? On the domain controller obviously there is only one administrator account and that’s the domain administrator, so that’s not an issue.

Ohhhh, yea I’m definitely logged in under the local administrator. Whereas, everywhere else I’d logged in under domain\administrator, which is what I used in $cred.

Okay, that makes sense now. Thanks a lot for clearing that up!

So obviously that answers your question about why you can’t connect to other machines FROM Pegasus.

You still have the issue of not being able to connect TO Pegasus from other machines though. Have you checked that Pegasus has an SPN?

Right, damn I thought I could move on for a second there :stuck_out_tongue:

I have’t worked with SPNs yet so I’m not sure but I don’t think so.

I was wondering. I’ve been following the video tutorials using my local admin account this whole time. For example, if I did Enable-PSSession, it would have been using the local admin account, etc. Is it possible that those features I’ve enabled aren’t applied to the domain account on pegasus? Basically were those changes (enable-pssesion, winrm service running, filrewall exceptions), not applied to the domain account on Pegasus and therefore other machines wouldn’t be able to access it?

Just a thought.

Enabling Remoting must be done by someone in the local Administrators group; it doesn’t “enable it just for specific accounts.” It’s on or off. Beyond that, you can decide “who can use Remoting” as a separate step; by default, it’s members of the local Administrators and Remote Administration Users groups. So enabling remoting isn’t applied to an account, per se.

So no, that’s not it.

As a quick aside - have you read “Secrets of PowerShell Remoting?” I ask because it kinda goes into the whys and wherefores - yes, the how-to, but also the “why it has to be that way” stuff. Including cross-domain, domain-to-workgroup, etc.