July 29, 2013 11 Comments
Last time we looked at Kiosk Mode for WES 7. This can also be used for Windows 7 Professional installs, and I plan to test with XP in the future. That could help provide low-cost kiosks for almost any scenario (libraries, church public use PCs, etc).
Today, however, I wanted to go through my struggles with SSO with RDS. My initial thought was that I didn’t want any prompt on the user screen, I wanted the ‘typical’ Windows Server 2008 R2 login screen as shown below.
However, with NLA or any RDP security enabled on the RDS Session Host or the RDS Connection Broker, you have to authenticate first before you get to this logon prompt. With my original testing, I didn’t want to have a user log in on the thin client, but log in using the terminal server logon prompt. This proved to be impossible due to DNS load balancing. Because of how DNS load balance works, allowing the user to have this logon prompt forced users to have to log in twice if their session was already located on TS2 and their thin client directed them to TS1 when the RDP connection was first opened. So when Joe moved to a different thin client, which was already opened at TS1 at the screen above, but Joe had logged into TS2 earlier, the Connection Broker did it’s job by forcing Joe to log into TS2, but TS2 made Joe log in again. Long story short, Joe doesn’t like that
Unfortunately (for my purely personal preference), in order to prevent the double login prompt for our users, I had to change the connection settings to force the users to log in before connecting to the terminal server (shown below). This isn’t really a big deal, other than requiring some minor tweaks that I had made preventing the terminal server from accepting local credentials and preventing the RDP connection from caching those credentials.
The next step was to configure my terminal servers and Connection Broker to accept my local credentials (otherwise users would be prompted twice). The Connection Broker in this step is vital because it’s handling the brokering of your connection to resume your existing session if you have one (hence Connection Broker). Since you’re authenticating before you get to the server, you get redirected to the appropriate server and (if configured correctly) don’t have to type in your credentials again. See my settings below (ignore the missing certificate – that will be fixed before final deployment). For my testing purposes, I have also configured my saved RDP file to “Connect and don’t warn” to servers where it doesn’t recognize the certificate. This will be changed later after I deploy my certificates so I know when something is wrong. Here are my settings from the RD Session Host Configuration screen.
For your situation, you may require more stringent security, so adjust those as appropriate. For my mixed environment, I’ve gone with the lowest common denominator until I can remove some of my older equipment and software. Another important piece of this, assuming you want your users restricted to a single session, is the setting below:
If you’re using a farm for your RDS servers, then you must have this configured on all relevant servers. It’s much easier to use a GPO to configure these settings and then apply that GPO to the OU in which the RDS servers reside. That makes life much easier as you grow your RDS Server environment.
It’s also important to configure your RDP connection that you’re launching on start-up properly. I’ll be posting the text from my RDP file which you can copy into your environment (after personalizing it, of course). In case you didn’t already know, you can open any RDP connection in Notepad to edit the file.