Thoughts from the EPS Windows Server Performance Team
Useful Microsoft Blogs
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:
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:
To configure the recommended settings for your TS, follow the steps below:
Configure Authentication on the Terminal Server
Configure Windows Vista / Windows Server 2008 client to allow default credentials to be used for logging on to the Terminal Server
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
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 220.127.116.11 .... 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.