PowerShell for Windows Admins

Dec 10 2011   9:54AM GMT

WMI, WSMAN, CIM and Authentication pt II

Richard Siddaway Richard Siddaway Profile: Richard Siddaway


Last time we saw that the WMI cmdlets have an Authentication parameter that uses DCOM authentication. It is possible to ignore this Authentication need if the WSMAN or CIM (PS v3 CTP 2) cmdlets are used.

If you look at the WSMAN cmdlets then the following cmdlets have an Authentication parameter in PS v2


These two cmdlets have an Authentication parameter though it appears as AuthenticationMechanism to the help files.

In PSv3 CTP 2 all of them have an Authentication parameter

For the new CIM cmdlets the following  has an authentication parameter


New-CimSession is analagous to New-PSsession for remoting in that it creates a session to a remote system over WSMAN or DCOM

These authentication parameters are totally different to the WMI Authentication parameter.

From the help file

-Authentication <Authentication>

Specifies the authentication mechanism to be used at the server. Possible values are:

– Basic: Basic is a scheme in which the user name and password are sent in clear text to the server or proxy.
– Default : Use the authentication method implemented by the WS-Management protocol. This is the default.
– Digest: Digest is a challenge-response scheme that uses a server-specified data string for the challenge.
– Kerberos: The client computer and the server mutually authenticate by using Kerberos certificates.
– Negotiate: Negotiate is a challenge-response scheme that negotiates with the server or proxy to determine the  scheme to use for authentication. For example, this parameter value allows negotiation to determine whether the Kerberos protocol or NTLM is used.
– CredSSP: Use Credential Security Service Provider (CredSSP) authentication, which allows the user to delegate  credentials. This option is designed for commands that run on one remote computer but collect data from or run  additional commands on other remote computers.

Caution: CredSSP delegates the user’s credentials from the local computer to a remote computer. This practice increases the security risk of the remote operation. If the remote computer is compromised, when credentials are  passed to it, the credentials can be used to control the network session.

This Authentication follows the network protocols and is used with the Credential parameter to determine Authentication & Authorisation for the resources that are requested.

In a domain setting it is most probable that you will not need to worry about these parameters as your user account should have the required level of access otherwise why are you attempting this action?

In a non-domain situation the WSMAN cmdlets can set the credential & authentication on individual connections (if required) but CIM can only do it at the session level.  Is this a problem?

Probably not as we can set these in a Cim session that can encompass all of the systems we need to access. The time this wouldn’t work is if all of the machines required different credentials – that would get messy but then is that poor administration to get into that position?

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: