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:

image

ii. Under HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders
Edit the REG_SZ value named SecurityProviders and add “ , credssp.dll” to the end (without quotation marks):

image 

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:

image

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:

image

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”:

image

 

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.