2

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.

2 Answers 2

2

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.

Edit:

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, 127.0.0.1, or [::1].

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

From here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa384295%28v=vs.85%29.aspx

2
  • 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, 2013 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, 2013 at 16:14
0

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)
http://msdn.microsoft.com/en-us/library/windows/desktop/ee309365%28v=vs.85%29.aspx

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .