Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In WinRM Service section of Group Policy, I have the option of disabling the following authentication mechanisms:

  • Basic
  • CredSSP
  • Kerberos
  • Negotiate

With concerns of security in mind, I would like to disable any authentication methods that could add extra vulnerabilities in the environment. That said, I want to do my best not to break expected functionality of the system, and understand what effect disabling authentication methods will have.

That said, what effects can I expect if I were to disable CredSSP and Negotiate? I'm hoping that Kerberos would be used for everything in an AD environment, and Basic is going to be disabled regardless.

share|improve this question
up vote 2 down vote accepted

Kerberos will be selected by default in an AD domain. But if anything goes wrong, then the client will not be able to fall back to any of the other authentication mechanisms. For instance, if the SPN for the service is not registered, Kerberos cannot be used, and the WinRM connection will fail. You also won't be able to use WinRM in other situations where Kerberos cannot be used, such as a connection to a workgroup computer or a computer in an untrusted domain.


Kerberos is the default method of authentication when the client is in a domain and the remote destination string is not one of the following: localhost,, or [::1].

Negotiate is the default method when the client is in domain, but the remote destination string is one of the following: localhost,, or [::1].

From here:

share|improve this answer
So, assuming that the client and server are both member computers, and that the SPN is in place and correct, Kerberos is the only authentication mechanism that will be attempted? – bshacklett Feb 25 '13 at 16:01
Yes. If you wanted to support "try Kerberos first, fall-back to NTLM if you can't use Kerberos," you would have to specify the Negotiate protocol. – Ryan Ries Feb 25 '13 at 16:14

CredSSP authentication is intended for environments where Kerberos delegation cannot be used. It was originally developed to support Remote Desktop Services single sign-on, however it can also be leveraged by other technologies such as PowerShell remoting. CredSSP provides a non-kerb mechanism to delegate a session's local credentials to a remote resource.

CredSSP delegation must be enabled in the client settings and in the service settings on the remote computer. If you do not have any current code or functionality that relies on this, there would probably be no impact.

Multi-Hop Support in WinRM (Windows)

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.