Home/ Questions/Q 8523897
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-11T07:32:25+00:00

We are attempting to use CredSSP authentication for multi-hop PowerShell remoting , and one

  • 0

We are attempting to use CredSSP authentication for multi-hop PowerShell remoting, and one of our clients is running into a snag that prevents them from creating PSSessions using CredSSP when specifying the FQDN of the target server. Both server and client are joined to the same domain, and there’s nothing fancy going on with disjoint namespaces.

In the course of debugging, we’ve opened up all of the related security options we can think of; in specific:

  • We’ve enabled the GP settings to Allow Delegating Fresh Credentials (standard and ‘With NTLM only’) with the wildcard SPN wsman/*
  • We’ve enabled the WSMan Trusted Hosts setting with *.domain.com
  • We’ve (of course) enabled WSMan for CredSSP on the server and the client
  • We’ve set the LocalAccountTokenFilterPolicy on the server

With all those settings opened up, here’s what we get when trying different authentication methods for PSSessions:

  • Using Kerberos for delegation with explicit domain credentials works fine.
  • Using Negotiate for delegation with explicit domain credentials works fine.
  • Using CredSSP for delegation:
    • Using domain credentials, connecting to the FQDN of the server, fails with the error There are currently no logon servers available to service the logon request
    • Using domain credentials, connecting to just the hostname of the server, fails with the same error
    • Using credentials for a local account on the server (thus forcing NTLM for server identity verification, I believe), connecting to the FQDN of the server, works fine
    • Using domain credentials, connecting to the IP address of the server (thus forcing NTLM for server identity verification), works fine

So, in short, CredSSP works as long as we’re using NTLM for server authentication and fails when we use Kerberos, but Kerberos definitely works fine if we’re using Kerberos for delegation as well. How is that possible, and what can we do to make it so that CredSSP+Kerberos works?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    We figured out the issue with the help of some engineers from Microsoft: the domain controller at the customer site is Server 2003, which does not support CredSSP (Server 2008 or greater is required).

    That is, CredSSP with NTLM works because NTLM doesn’t involve the domain controller–it’s just between the client (Windows 7 x64) and the server (Server 2008 R2 x64). When you use CredSSP with Kerberos, you’re now involving the domain controller (KDC), which doesn’t know how to handle a CredSSP connection, so it fails.

    So, until the customer can upgrade their domain controller, they’re going to use a local user account to remote with our deployment tool, thus cutting the domain out of the picture.

    • 0