WS2008: Frontside Authentication and SSO

WS2008: Frontside Authentication and SSO

  • Comments 4
  • Likes

Welcome to Day Twenty-One.  We're three weeks into our series and there are only six days left.  Today's topics for discussion are Frontside Authentication and Single Sign-On (SSO) in the Terminal Services space.  So, let's get started ...

Frontside Authentication is a new connection process in the Remote Desktop Connection 6.x client where credentials are entered before the connection is made to a Windows Server 2008 Terminal Server.  After you enter your credentials and initiate the connection to the Terminal Server, our credentials are automatically passed to the server for authentication.  With this new behavior, you now enter your credentials in the RDC client as opposed to the Log on to Windows prompt that is presented by WINLOGON.EXE on the Terminal Server.

So what's the big deal, right?  You still have to provide valid credentials to log on, so why did we make this change?  The intent of Frontside Authentication in Terminal Services is to enhance usability and increase security by reducing the potential attack surface exposed to unauthorized users.  A new Security Support Provider (SSP) in Windows Server 2008 provides a more secure method for transferring credentials over the network prior to establishing a new Windows session.  In previous versions of Windows Server, numerous session-specific components, such as CSRSS.EXE, USERINIT.EXE and WINLOGON.EXE  we active during the authentication process.  This created the possibility of a pre-authentication attack surface for key operating system components.

The Frontside Authentication mechanism uses the new SSP in Windows Vista and Windows Server 2008, CredSSP, to initiate a secure channel between the client and server as the first stage in a Remote Desktop connection.  The secure channel creation process forwards the credentials to the server for authentication.  The actual remote session is only created if the secure channel is established.  The establishment of the remote session itself means that the user was authenticated, thereby reducing the attack surface presented to an unauthorized user.

The functionality of Frontside Authentication is only available when using the RDC 6.x client.  The user experience is dependent upon the client and server operating systems as outlined in the table below:

Client OS with RDP 6.x Target Terminal Server OS Prompt for Credentials
Windows Vista / Windows Server 2008 Windows Server 2008 / Windows Vista Always at TS Client Side
Windows XP, Windows Server 2003 Windows Server 2008 / Windows Vista Always at TS Server Side
Windows Vista, Windows XP, Windows Server 2003, Windows Server 2008 Windows XP, Windows Server 2003, Windows 2000 Always at TS Server Side

The key to remember is that the "authenticate before connecting" behavior is only valid when both the client and server are using the new CredSSP in Windows Vista and Windows Server 2008.

Let's turn our attention now to Single Sign-On (SSO).  SSO is an authentication method that allows a user with a domain account to log on once, using a password or a smart card, and then gain access to remote servers without being prompted for credentials again.  Terminal Services in Windows Server 2008 supports SSO for domain-joined servers to provide a better user experience by eliminating the need for users to enter credentials each time they initiate a remote session.  To implement SSO functionality in Terminal Services, the following requirements must be met:

  • You can only use SSO for remote connections from computers running Windows Vista or Windows Server 2008
  • Ensure that the user accounts have the rights to log on to both the Terminal Server and the Windows Vista client
  • Both the client machine and Terminal Server must be joined to a domain

To configure the recommended settings for your TS, follow the steps below:

Configure Authentication on the Terminal Server

  1. Open the Terminal Services Configuration MMC Console
  2. In the details pane under the Connections section, right-click RDP-Tcp and then select Properties
  3. In the Properties dialog box, on the General tab, verify that the Security Layer value is either Negotiate or SSL (TLS 1.0) and click OK.

Configure Windows Vista / Windows Server 2008 client to allow default credentials to be used for logging on to the Terminal Server

  1. On the client computer run gpedit.msc
  2. Expand Computer Configuration\Administrative Templates\System and then select Credentials Delegation
  3. Double-click Allow Delegating Default Credentials
  4. Select the radio button for Enabled
  5. Click on the Show ... button to bring up the Show Contents dialog box
  6. Click on Add.  In the Add Item dialog box, type in the prefix termsrv/ followed by the name of the Terminal Server - as shown in the example below, then click OK.  Repeat this step to add your Terminal Servers.  Once you have added the servers, click OK  in the Show Contents dialog, then OK to close out of the policy.

Now when you connect to one of the Terminal Servers that you added in Step 6 above, you should not be prompted for credentials if your user account has permissions to log on to a Remote session.

And that will bring us to the end of Day Twenty-One.  Tomorrow we'll be taking a look at TS RemoteApps.  Until next time ...

  - CC Hameed

Share this post :
Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • PingBack from http://www.ditii.com/2008/02/21/windows-server-2008-frontside-authentication-and-sso/

  • a little confused about the 3rd line in the connection table (client: Windows Vista, Windows XP, Windows Server 2003, Windows Server 2008 : target :  Windows XP, Windows Server 2003, Windows 2000 prompt: Always at TS Server Side )

    RDP 6.x on XP to Windows 2003 Server always causes a Frontside cred prompt, whereas that table implies a server side?    also, if you get the creds wrong, it populates the username as servername\user, not domain\user; so to correct it you have to edit the username field.

    (hmm that was hard to explain, oh well).  

  • Question:  What happens if you fat finger the IP address?

    Do your credentials get handed over to the WRONG server to be authenticated?  Only to be rejected as "you're not an authorized user"?

    And doesn't this add the potential, for someone to be LISTENING for these types of connections, and to record user credentials... to later attack the credentials and use them against another machine?  

    ie. I mean to connect to 192.168.1.10, instead I type 193.168.1.10 .... doesn't then, my user and pass get sent to an invalid machine/server?  And can't that machine be recording access attempts and capture user/pass info?

  • When you say "You can only use SSO for remote connections from computers running Windows Vista or Windows Server 2008" what does it mean?

    Is SSO from WIndows 2008 to Windows 2003 works? and also the other way?

    Please let me know.