通过

Remote Desktop Services & WebSSO

  • 项目

With Windows Server 2008 R2 we introduced “Web Single Sign-On” (WebSSO) to eliminate some of the authentication prompts when users open up RemoteApps.

 

There is a very detailed introduction here, but there are some points worth highlighting as we see them often missed:

Form Based Authentication (FBA) and the standard RDWeb logon page must be used, not Windows Authentication

WebSSO only works for RemoteApps, not virtual desktops or connections through the Remote Desktop tab in RD Web Access **

WebSSO requires Remote Desktop Client 7.0, this is supported on XP SP3, Vista SP2 and Windows 7 (the last having it built-in)

The client must be domain-joined*

 

Going through the typical user steps to launch a RemoteApp through RD Web Access…

1. Using the web browser to connect to https://rdwebaccess/RDWeb/

First possible gotcha – the use of SSL means we need a certificate whose publisher is trusted, if you have an internal CA then you may need to lift its public certificate and drop it into the Trusted Root Certification Authorities container of the Local Computer’s certificate store.
This will satisfy the certificate chain validation and prevent warnings related to the certificate’s authenticity.
Note that the name on the certificate must match the hostname entered in the path – beware when testing with localhost or NetBIOS names of servers, if you certificate has the FQDN as its name.

 

2. Assuming any possible issue from (1) has been addressed, we now get the Form Based Authentication page from the RD Web Access web application running under IIS

There should be no issue here, the user authenticates with their domain credentials which allows the web application to talk to the RemoteApp source (a Connection Broker or one or more Session Hosts) in order to present the list of RemoteApps that the user is permitted to see.

 

3. Now the user clicks a RemoteApp icon, which is a call to a javascript function to initiate the connection with a faked .RDP file (HTML-escaped, so not very readable)

First possible issue: the signature of the .RDP file is not implicitly trusted, so a warning is presented…

untrusted-rdp-publisher

Resolution: From the properties of the certificate used to sign the RemoteApp, lift the SHA1 thumbprint (without any spaces) and add it to the comma.-separated list of trusted .rdp publishers in the policy setting:
Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Client > “Specify SHA1 thumbprints of certificates representing trusted .rdp publishers”

 

Once the signing certificate is trusted, or the user clicks Connect, the client then gets sent to the Connection Broker, which might throw an authentication prompt:

default-credentials-delegation-needed

Even though I’ve masked out the domain name, you can see the challenge is coming from my Connection Broker (padams-rdcb), where the previous warning about the RemoteApp signature was coming from the signer of the .rdp file – in this case the Session Host itself (padams-rdsh2).

Resolution: Another policy setting, this time to add TERMSRV/connection_broker_fqdn (or TERMSRV/* to specify all servers) to the list of endpoints we are going to allow the delegation of default credentials for:
Computer Configuration > Policies > Administrative Templates > System > Credentials Delegation > “Allow Delegating Default Credentials”

In my case I would add TERMSRV/padams-rdsh2.mydomain.com to the list in this policy setting in order to suppress this prompt.

TIP: Always check the “These credentials will be used to connect to” field in order to figure out who is triggering this prompt, so you know what to add to a relevant delegation policy

 

Remember that certificate checks and SPNs are very specific – if you specify an FQDN then you cannot use a NetBIOS name, and vice versa – the resolution of what that name points to is something else entirely, and why we rely on certificate thumbprints to avoid man-in-the-middle exploits.

 

* I have experienced problems with using WebSSO connecting to an RDS farm under the control of a Connection Broker when using a non domain-joined client, the CB prompting for authentication (and accepting it on first go, so it is not an authentication failure that is occurring), however I am informed that it ought to work, so I have striked through the “client must be domain joined” requirement as listed above.

** There is now a hotfix for Windows 7 to address this:
KB2524668 - The single sign-on feature does not work in Windows 7 or in Windows Server 2008 R2 when you try to start a full remote desktop connection through RD Web Access

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    July 16, 2011
    I have been trying for 3 weeks now to get single sign on via RDWEB but no luck. I went through the instructions exactly and I still recieve a warning and a second logon when I click on remote app in RDWEB??? Any further suggestions? Can we be more specific re which certificates to be used where and in which certificate store? All of the certificates I am using is from a trusted public source (digicert).

  • Anonymous
    January 24, 2013
    I'd also like to point out that when you copy the SHA1 thumbprint from a certificate into the GPO, there's a hidden character in front of the thumbprint which Notepad and the GPO editor doesn't show. When you copy it into a command prompt, the hidden character shows up as a question mark. You have to remove this character in order to make the GPO working.