What is Single Sign-On?
When applied to Terminal Services, Single Sign-On means using the credentials of the currently logged on user (also called default credentials) to log on to a remote computer. If you use the same user name and password logging on to your local computer and connecting to a Terminal Server, enabling Single Sign-On will allow you to do it seamlessly, without having to type in your password again.
Locally logged on credentials are used for connecting to TS Web Access, however, they cannot be shared across TS Web Access and TS or TS Gateway. Thus you will need to enable the Group Policy settings described below in order to use locally logged on credentials for TS or TS Gateway connections.
How to enable Single Sign-On?
Single sign-On can be enabled using domain or local group policy.
What are the limitations when using Single Sign-on?
Why is Single Sign-On controlled by Group Policy?
As a part of the logon process TS Client sends the actual user credentials (user name and password) to the server. If a code running as a regular user were allowed to enable Single Sign-On, any malicious software (virus, Trojan, spyware etc.) running in the user's session would be able to send the user's password to any machine on the network. So, only administrators should be allowed to decide which servers are safe for Single Sign-On.
Thus Single Sign-On can only be enabled on domain-joined client machines.
What if I have Single Sign-On enabled but want to use different credentials this time?
Start TS Client. Click the "Options" button. Select the "Always ask for credentials" checkbox. You will be asked for credentials next time you connect.
How do I enable Single Sign-on for TS Gateway Server?
If you have a non-domain client, then you cannot get single sign-on by using locally logon credentials to authenticate with TSG and TS since administrator cannot deploy single sign-on group policies to the non-domain client machines.
Thus, to provide the best connection experience for non-domain clients through TS Gateway, set the option “Use my TS Gateway credentials with remote server option” in RDP file or in the mstsc client advanced setting menu as per screenshot below. This will ensure that end users are prompted for credentials only once during the connection experience.
No. Unfortunately if a Smart Card is used to log on locally to the machine, these credentials cannot be used for Single Sign-On. Please also note that you cannot save Smart Card credentials in TS connections either.
Nu finns det en guide för hur man konfigurerar SSO mellan en VISTA/Longhorn klient till en VISTA/Longhorn...
Is it possible to provide SSO for Terminal Services in Win2k3 Server and XP/Win2k3 as clients?
Unfortunately it's not possible, because SSO requires using a special Security Support Provider currently available only in Vista.
If I understood the explanation correctly, you use also a username and password to authenticate from Vista to Longhorn. The difference is that the username and password are cached and sent without user intervention.
No way to rely on kerberos authentication and constrained delegation ?
Dans un domaine windows, on est authentifi&#xE9; pour quasiment tous les services via Kerberos sans
I've just foudn out that SSO will be available on XP SP3. Dev. has ported CredSSP back to XP SP3.
Someone from MS Dev. need to confirm that SSO will work with WinXP SP3.
Unfortunately, SSO will not be supported on XP SP3.
I'm sorry for the confusion.
I was just in the Webcast today on Security in Terminal Servers and the presenter had XP SP3 in the list as supported for SSO.
Was that old information?
BTW, it does work in XP SP3 RC1; however, the group policy templates don't provide for a means to make the change.
Make the change on a vista box and export the registry key and it will work on XP. Tried with SP2/RDP 6.1 client, that's a no-go, SP3 *IS* required.
Can anyone else confirm SSO works in XP Sp3?
Can someone post the registry changes required for the SSO to function on an XP machine?
Windows Registry Editor Version 5.00
Replace "<My Server1>", "<My Server2>", etc. with the real server names.
Do not use AllowDefCredentialsWhenNTLMOnly unless it is absolutely necessary. It is to enable SSO when Kerberos or SSL server authentication is not possible, and it is not very secure (you may end up sending your password to a wrong server).
Thanks! Hopefully I can get it to work.
I suppose this could be pushed out using GPO to XPSP3 PCs. Has anyone done it?