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
Test-WSMan
Get-WSManInstance
Set-WSManInstance
Invoke-WSManAction
Connect-WSMan
These two cmdlets have an Authentication parameter though it appears as AuthenticationMechanism to the help files.
New-WSManInstance
Remove-WSManInstance
In PSv3 CTP 2 all of them have an Authentication parameter
For the new CIM cmdlets the following has an authentication parameter
New-CimSession
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?