Team,
I read few articles & came to know that kerberos fallback does not supported by Powershell remoting. Then what does it mean by " Negotiate = true"?
Below ouput is the partial output of " winrm g winrm/config".
Auth
Basic = true
Digest = true
Kerberos = true
Negotiate = true
Certificate = true
CredSSP = false
DefaultPorts
Hello,
This link might be helpful to give more information about each particular property: http://msdn.microsoft.com/en-us/library/aa384372(v=vs.85).aspx
From Microsoft definition they say the following:
Allows the client to use Negotiate authentication. Negotiate authentication is a scheme in which the client sends a request to the server to authenticate. The server determines whether to use the Kerberos protocol or NTLM. The Kerberos protocol is selected to authenticate a domain account, and NTLM is selected for local computer accounts. The user name must be specified in domain\user_name format for a domain user. The user name must be specified in server_name\user_name format for a local user on a server computer. The default is True.
That definition suggests that kerberos is supported, also if it wasn’t then -credential shouldn’t work when authenticating against another domain.
Unless i haven’t understood something properly here - hopefully someone else can correct me.
Do you have the articles where they suggest it isn’t?
I think you’re probably referring to this page: Authentication for Remote Connections. The default (assuming the client is in a domain, and is not connecting to itself via 127.0.0.1 or ::1 addresses) is to use Kerberos authentication, and not to fall back to NTLM. That’s just the default, though; you can specify anything you like with the -Authentication parameter of various cmdlets, such as Invoke-Command and New-PSSession.
Note that you may have to take some other steps as well, to get non-Kerberos authentication working. Specifically, you’d have to set up an HTTPS listener on the remote host, or modify the client’s TrustedHosts list.
Here is the link.
http://blogs.technet.com/b/jonjor/archive/2009/01/09/winrm-windows-remote-management-troubleshooting.aspx
Hmm. That statement specifically mentions “WinRM with SCVMM”. I’m not sure if SCVMM has some other limitations that are separate from what you can normally do with WinRM / PSRemoting.