Monthly Archive


WMI, WSMAN, CIM and Authentication pt II

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?

Leave a Reply