PhillyPosh User Group Meeting Presentation Follow-up: PowerShell Second-Hop Problem with CimSessions

This blog article is a follow-up to my presentation for the Philadelphia PowerShell User Group which was on September 5th. A video of that presentation is available on the PhillyPosh YouTube Channel:

I received a question towards the end of the meeting wanting to know if the Cim Cmdlets and Sessions experience the same sort of second hop authentication issue as using Invoke-Command where your credentials can’t be re-used by a remote machine for authentication to access resources on a third machine that your command is attempting to use.

I’ve confirmed that the Cim Cmdlets do indeed have this issue so it isn’t specifically an issue with the Invoke-Command cmdlet or PowerShell remoting , but possibly the way the Operating System is secured by default. To demonstrate this issue, I’ll start out by running PowerShell as a domain admin and then create a CimSession to a machine named web01:


I’m now going to backup the system event log to a local drive on the web01 server that I established the CimSession to which works without issue:


When I attempt to backup the same event log to a network location, I receive an access denied error:


CredSSP has been enabled on the client that this command is being run from and on the web01 server. For more information on enabling CredSSP see the help for Enable-WSManCredSSP.

I’ll now create a CimSession to the same server, except I’ll specify CredSSP as the Authentication type (Instead of the default of Kerberos):


Running the backup to the local file system on web01 works without issue just as it previously did:


This time though, the backup of this event log to a network location completes successfully because using CredSSP allows web01 to use our credentials to authenticate to dc01:


There was also one issue I ran into during the presentation that I said I would come back to later but didn’t get a chance to so I’ll cover that issue in this blog article as well:

I started off by showing the number of records that were in one of the event logs by using the Get-CimInstance cmdlet:


I demonstrated using the Invoke-CimMethod cmdlet along with the WhatIf parameter to clear that event log:


I then ran the same command without the WhatIf parameter which generated an error:


As you can clearly see in the error message shown in the previous results, “clear” is not the correct method name to clear the event log (that’s what happens when you try to type everything in during your presentation).

To determine what the method names are, I’ll first start out by just running the Get-CimClass cmdlet against that particular WMI class to see what it returns. I can see there’s a property named “CimClassMethods” which appears to be a collection of items:


To see what’s in that collection of items, I’ll use the Select-Object cmdlet with the Expand-Property parameter:


I can see in the previous results that “ClearEventLog” is the correct name for the method I’m looking for. Using that method to clear the event log works without issue:


Now the system event log only contains one record which is a record that says the event log was cleared:



Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: