Imagine the following scenario: DC01 is a Domain Controller for test.net with the Remote Desktop Services Connection Broker service role installed. RDS01 and RDS02 are W2K8R2 member servers in test.net and have the Remote Desktop Services Session Host service role installed, configured as members in a Connection Broker farm (using DC01 as the broker). CLIENT is an XP SP3 member client which we want to use as a Remote Desktop Client to connect to the farm.
There are a few things to be aware of when it comes to CLIENT in this setup…
XP SP3 contains Remote Desktop Client 6.1 and has the capacity to support Network Location Awareness (NLA) and CredSSP, but these are not enabled by default and a couple of registry tweaks are needed, as per KB951608: i. Under HKLM\SYSTEM\CurrentControlSet\Control\Lsa Edit the REG_MULTI_SZ value named Security Packages and add tspkg to the list: ii. Under HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders Edit the REG_SZ value named SecurityProviders and add “, credssp.dll” to the end (without quotation marks):
No NLA + server enforces NLA = no connection No CredSSP + server redirects incoming logon to another farm member = authentication prompt
So if using 3rd party Remote Desktop Clients to connect to your Session Hosts, be aware that they may not support these features.
There is a hotfix that is post-SP3 for XP clients which should be applied when used for connecting to Session Hosts: KB953760 - When you enable SSO for a terminal server from a Windows XP SP3-based client computer, you are still prompted for user credentials when you log on to the terminal server
NOTE: The Remote Desktop Client itself is exactly the same set of binaries whether installed on Windows XP, Vista or 7 – RDC leverages authentication features in the client OS and this is where the differences may come in, assuming the same .rdp file options and server-side settings. enablecredsspsupport:i:1 should not be needed in a .rdp file as it should be checked in the client supported feature list.
Single Sign On (SSO) is the use of credential delegation to automatically authenticate on behalf of the user. Default credentials are those used to authenticate to Windows. Saved credentials are those that have been recorded in the credentials store for that user connecting to the specified SPN.
Remote Desktop Connection uses the credentials delegation settings of the OS on the client, by default there is no delegation, which means: No saved credentials = “You will be asked for credentials when you connect” Saved credentials = “Saved credentials will be used to connect to this computer”
With CredSSP enabled, the client prompts for credentials before the connection takes place:
Otherwise (enablecredsspsupport:i:0), the client connects to the server and lets the server handle the authentication – this is how Terminal Services logons traditionally took place:
If we enable the use of default credential delegation then the message changes to “Your Windows logon credentials will be used to connect” and SSO is enabled, no authentication challenge is seen. NOTE: If prompt for credentials on client:i:1 is set in the .rdp file, then the authentication challenge will appear even if default credential delegation is enabled. With SSO enabled, to use alternative credentials we click on Options and check the box “Always ask for credentials”:
Credentials delegation is controlled via group policy (also covered in KB951608): Computer Configuration > Administrative Templates > System > Credentials Delegation - Allow Delegating Default Credentials - Allow Delegating Default Credentials with NTLM-only Server Authentication
For each policy setting you need to specify the SPNs for which we allow delegation – to allow delegation to any Remote Desktop Session Host, use TERMSRV/* as the SPN.
These correspond to the following registry values: Path: HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation Name: ConcatenateDefaults_AllowDefault Type: REG_DWORD Data: 1 Name: AllowDefaultCredentials Type: REG_DWORD Data: 1 Path: HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation\AllowDefaultCredentials Name: 1 Type: REG_SZ Data: TERMSRV/* Path: HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation Name: AllowDefCredentialsWhenNTLMOnly Type: REG_DWORD Data: 1 Name: ConcatenateDefaults_AllowDefNTLMOnly Type: REG_DWORD Data: 1 Path: HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation\AllowDefCredentialsWhenNTLMOnly Name: 1 Type: REG_SZ Data: TERMSRV/*
NOTE: Be careful if editing the registry manually – note the distinction between keys, values and value types Also be aware of long paths getting clipped, depending on how the page renders – the last path above, for example, ends with AllowDefCredentialsWhenNTLMOnly (copy/pasting the line works okay)
NTLM credentials are used for connections to IP addresses, and a connection broker uses IP addresses for redirecting logons by default – so if RDS01 and RDS02 are in a farm then both group policy settings will need enabling.
If you find that there is a ~30 second delay in connecting to a Remote Desktop Session Host, under which time the Remote Desktop Client displays “Securing remote connection…” then this is likely due to a timeout checking the server certificate chain (typical if an “auto generated” certificate is used by the server).
To get around this, you can disable the check on the client by enabling a group policy setting: Computer Configuration > Administrative Templates > System > Internet Communication Management > Internet Communication settings - Turn off Automatic Root Certificates Update
This corresponds to the following registry value: Path: HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot Name: DisableRootAutoUpdate Type: REG_DWORD Data: 1
This highlights some of the common issues encountered relating to CredSSP, SSO and multiple authentication challenges – I have glossed over the warnings that the client throws triggered by name & certificate validation here, but their root cause is often best discovered by reading the text in the message presented and optionally doing a search on it.
Here's another uncommon reason why «Securing remote connection…» phase hangs for two minutes. In my recent case it happened because the Remote Desktop Connection machine didn't have Kerberos (TCP/88) access to Active Directory Domain Controller for the domain of the target machine (i.e. Remote Desktop Session Host).
Hi, so how do you enable SSO exactly? Do you need to enable SSO as a separate setting or does it work after you enable Credential Delegation + CredSSP?
There's nothing else to do - the Remote Desktop Client automatically leverages the CredSSP component if it's enabled.
So in Windows7 you would only need to enable "Allow Delegating Default Credentials with NTML only Server Authentication" and "Allow Delegating Default Credentials" in GPO and it should work?
I enabled these settings with TERMSRV/* however the result I get is credentials being asked on server.
In RDC I see "Your Windows logon credentials will be used to connect" before connecting, but credentials are not delegated as I get empty username and password fields on the server.
I am logged in with domain user.
Servers are 2008R2 with Remote Desktop Connection Broker and NLB, do I need to change any additional settings?
Once the delegation is enabled for the specified SPNs, it should be good to go.
I would recommend starting with a more basic configuration - take a node out of the Connection Broker farm and try connecting to it by its unique name instead of the NLB name.
If that works, you know you need to check out the configuration of the DNS, SPNs, certificates and so on.
Sometimes taking a network trace from the client & RD Session Host you can see what authentication requests & Kerberos ticket requests are travelling around, and that can be a clue where to start.
I have tried to connect to another computer remotely which is not in Remote Connection Broker and SSO worked fine, but I have little knowledge where to go from here and how to track the problem source, I have no experience in network tracing, would you suggest some article for starters?
Network and session load balancing introduce issues of their own, typically around names, SPNs and certificates, so things to check:
- how different names used by the client to access the farm behave
(NetBIOS, IP address, FQDN, specific session host, etc.)
- registered TERMSRV/xxx SPNs on the computer objects in Active Directory for the machines involved
> Common Name (CN) matches the name used to access the server or farm as appropriate
> Certificate Authority (CA) must be trusted by the client
> Certificate Revocation List (CRL) must be reachable if defined
The tools of choice for checking out Kerberos ticket requests would be either Network Monitor (NetMon) or Wireshark.
Either tool is too much to go into in detail in a blog, but using a display filter after capturing data on the client and all session hosts you should be able to see the requests & responses from the KDC.
(Kerberos traffic is only UDP or TCP port 88, and the packet details should be able to show you the SPN for which a ticket is being requested.)
I'm not aware of any quick-start guides for using NetMon or Wireshark, I'm not sure there is a better way of getting to know each one other than simply using it and reading the online help.
Kerberos itself is not my area of expertise, so if there is a GPO affecting Kerberos ticket behaviour, for example, I wouldn't know where to check for that - but it sometimes helps to move computer objects into an OU with all GPOs blocked for testing.
Finally I was able to figure this out. All I had to do was change the Security Layer value to Negotiate in Remote Desktop Session Host Configuration -> Connection -> Properties as described here: