XP Clients, CredSSP, SSO, Connection Broker and other animals
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.
Comments
Anonymous
January 01, 2003
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).Anonymous
January 01, 2003
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: technet.microsoft.com/.../cc742808.aspxAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
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?Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
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?Anonymous
January 01, 2003
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?