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.
XP SP3 is required since CredSSP was ported to XP SP3 (not SP2). You will need to enable credssp on it (see KB article # 951608 for more info).
Can this be used to connect from XP SP3 to XP SP3, or does the server still need to be 2008?
Unfortunately, no - XP SP3 can only be used as the client so no XP SP3 to XP SP3. Server has to be 2008 or Vista.
I am trying to setup SSO with xp SP3.
your previous post says APPEND,i am really unable to get what to APPEND ? please help me.
windows 2008 server
configured the RDP accordingly
Windows XP professional with xp sp3.
Earlier you said
"OK, I've managed to achieve the functionality. Here's what to do:
APPEND, don't replace: credssp.dll
APPEND, don't replace: tspkg
AGAIN, you need to APPEND these values, not replace what's there "
i am not sure what do you mean by append
I got it , we have to add these values to the registry .
and enable credssp on windows xp professional clients
How to modify "Security Packages" with Domain Group Policy?
The article states that it's not possible to USE SSO in combination with smart cards. Is there any known work around for this?!
SSO is working, but TS Remote Apps functionality is severely degraded due to differnet lock out time periods. Often remote app progrmas are idle while attending to other programs and then you come back to remote apps and have to log back in. Any suggestions? Domain lockout is 20mins and can't be changed.
RE SSO with Smart cards: unfortunately you cannot get SSO with smart cards today unless you deploy something like ISA/UAG server.
RE: lockout/timeout - thanks for your feedback. Domain lockout of 20 mins also applies to the TS where your Remote apps are hosted?
Lockout is based on AD Policy. I would have to create a seperate OU and drag the remote apps server into that OU and set No Timeout. This would probably work, but would not fly with our Security team. Any other suggestions or thoughts?
The only thing stopping me from a full roleout of Remote Apps and 2K8 Server are users can't stand having to relog on to the application every 20 minutes of inactivity. SSO works great for the initial launch, but after 20 minutes, SSO benefits are moot and users have to type in creds to unlock the session.
If the Remote Apps could share the same incativity timer as the host machine, it would be a beautiful thing.
Does these setting provide SSO to the TS Web Access portal ? i.e, I launch IE, navigate to my TS web access page, it auto logs on and my apps are presented. If so, it does not seem to work for me, I am using Windows 7 RDP 7.1. When I use mstsc and connect to my farm, SSO does work. Can someone clarify please :-) thanks
For Web SSO, see http://blogs.msdn.com/rds/archive/2009/08/11/introducing-web-single-sign-on-for-remoteapp-and-desktop-connections.aspx
The error message in the Remote Desktop Connection app (mstsc) should be more detailed.
- domain-joined Win 7 machine at work
- connecting to non-domain-joined Win 7 machine at home
- saved credentials would not pass and I would get the following message:
"Your credentials did not work. Your system administrator does not allow the use of saved credentials to log on to the remote computer my.domain.com because its identity is not fully verified. Please enter new credentials."
Enabling the "Allow Delegating Saved Credentials with NTLM-only Server Authentication" of course fixed the problem.
In retrospect, the message now makes sense, but before I thought it was getting the wrong username/password. It seemed to me that the remote machine was rejecting it.
I suggest some changes to make this clearer:
1) Change the title of the error to something like "Saved credentials could not be sent". The way it is now, sounds like they were sent and rejected by the remote machine.
2) Alter the error message to include some hint that this is the result of the Local Computer Policy so that the user knows where to look.
3) When opting to save credentials, a policy check should occur and the user should be informed that the policy is not going to allow it.
4) A help button and page that includes information on connecting from a domain-joined PC to a non-domain-joined PC.
Thanks for considering it. :)