none
PowerShell New-CIMSession access denied on local machine with passed credentials RRS feed

  • Question

  • I am using PowerShell on Windows 10 64-bit to connect to WMI on remote systems via "New-CIMSession" I launch my script as a non-administrator; within the script I prompt for credentials and pass that to my New-CIMSession cmdlet:

    $Global:CIMSession = New-CIMSession -Name "tmpSession" -ComputerName "$tmpComputer" -Credential $Global:Credentials

    Subsequently, I can query classes, etc. all day long on a remote computer with no issue. However, if this is run and the computer is the local computer, my CIM Session and subsequent CIM-Instance cmdlets fail with "Access Denied".

    If I launch the script as an administrator it works fine both remote and locally, but I need the script to be able to be launched without requiring elevation, so that one of a small list of domain accounts can be used.

    I figure it works remotely because the context in which it runs, i.e. the CIM Session, accesses the remote via the administrative share, what I don't understand is, why does it not work when using the local computer name? Shouldn't it also connect to the administrative share?

    Thursday, May 21, 2020 6:27 PM

All replies

  • After testing the Cim  Session works locally with any admin credentials.  You likely haven't configure remoting correctly for the local system.


    \_(ツ)_/

    Thursday, May 21, 2020 8:58 PM
  • Thanks, but I considered that. The local system was built using the same MDT package as the remote machine I am testing, all policies are the same.

    I ran the script on two different machines and, just like my original and the same thing happens; if script is not launched with elevated rights it gets "access denied".


    Friday, May 22, 2020 1:16 PM
  • Thanks, but I considered that. The local system was built using the same MDT package as the remote machine I am testing, all policies are the same.

    I ran the script on two different machines and, just like my original and the same thing happens; if script is not launched with elevated rights it gets "access denied".


    Yes - you must always launch admin protected processes in an elevated session when connecting to the local machine.  UAC still applies.  UAC does not apply to remote systems.  I assumed you were doing that.


    \_(ツ)_/

    Friday, May 22, 2020 3:00 PM