Kiosk Mode for Windows + SSO for RDP (part 2)

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.

Typical RDP Logon ScreenHowever, 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.

RDP-TCP Properties

Logon Settings

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.


20 thoughts on “Kiosk Mode for Windows + SSO for RDP (part 2)

    • Hi,
      Thanks for reaching out. We have found some ‘glitches’ that needed to be worked out, but overall this system has worked out well for us.
      We can discuss in more detail if you’d like. I’ll email you my contact info.

      • Email would be great! Tried finding your email around the web, but LinkedIn was the only place with that option and I can’t send InMail. I’m ccarcit [at] I am working on a proof of concept using ThinKiosk as the interface for our kiosk, with RD to virtual instances of Windows 7 set up as concurrent multi-user environments.

      • Hi Andy,

        We found that disabling the Root Certificate Update on the thin clients stopped the behavior you noted in that TechNet post. Seems that that function caused issues, and disabling fixed it. I think this is due to self-signed certs on the RDS servers (that are installed by default), and not having a third-party certificate. I am getting ready to install a third-party wildcard on my RDS servers and will re-test. One warning, though, before you do this: if you disable the Root Certificate Update, it will cause problems with websites. For example, we were receiving certificate errors in IE when accessing GMail, Office365 and many other common sites because the Root Certificates were not updated. This was fixed by re-enabling the service. Now, we weren’t doing a lot of checking on these updates, because we weren’t using these thin clients for browsing, but there came a time where that was an appropriate use of the thin clients.

        Let me know if you have any other questions. See below for instructions on disabling Root Certificates Update. (See paragraph “Turn Off Automatic Root Certificates Update”

        Hope this helps!

  1. Thanks JP!
    I’ve just tested but still getting the same issue..
    Were your thins domain-joined? Our ones are just workgroup, autologon as a standard User and using HP connection manager to autolaunch the RDP connection.
    It does sound like a similar setup, thinclient auto logs in and sits at “Enter your credentials”.
    If that is indeed how you have things setup, do you get the “couldn’t connect in the amount of time allotted” error if they’re at that screen for more than 20 minutes?

    • I apologize, I think I misread your post about the timeout issue. We were having a problem where users who put in their credentials would be stuck waiting for RDP to finish connecting, and then it would disconnect. That was related to the Root Certificate Update setting. This has been quite a journey to get this working smoothly, and we’ve had to give up some of our original “must-have’s” in order to keep the user experience smooth.

      To answer your first question, the Thin Clients are not domain-joined. I’m using the same AutoLogin that you are probably using. The problem is most likely the HP Connection Manager. They don’t use the same RDP client that Windows has, and they don’t support NLA from the research/testing that I did. They have their own special RDP client they use (possibly derived from a Linux variant), and it did not support NLA, especially with the persistent connection.

      They did come up out with an updated version, and I tested it, but wasn’t able to get it to work. That was several months ago, though, so they may have enhanced it some.

      I originally did a GPO edit that replaced the Windows shell with an RDP connection that was persistent (I love that feature of Connection Manager), but that became obnoxious after a while due to a timeout where if the initial login screen sits for more than ~15-20 minutes with no activity (user walks away from their desk; over night, etc.), the user has to click “Cancel” and then login.

      We’ve now moved to having a single RDP icon on the desktop that the users click to open the RDS farm. It’s not what I originally wanted, because I really like the connection manager from HP, but I could not get the application to do what I wanted.

  2. That 15-20 minute timeout is exactly what we are experiencing.
    I’m pretty sure HP Connection Manager just launches the Microsoft RDP client but I could be wrong. It definitely does support NLA as that’s how we have it setup.
    I’ve got a call open with HP now, but i’m pretty sure it’s a Microsoft issue (hence my post to TechNet).

    • Let me know what they find because if I can use the HP Connection Manager that would be most helpful.

      What version of the HP Connection Manager are you using?

      I’m sure you’ve done this already, but watch the RDP logs on the terminal server and you’ll notice there is nothing indicating a dropped session or anything. However, a new session is created when the RDP window opens. It’s really strange. I’ll follow your technet posts as well.

      Which thin client models did you use? We have the T610s at our office – about 50 total at this time.


  3. We’re using T610s also, latest HP Connection Manager;
    I’m really starting to think this is “by design” from Microsoft.

    Apart from thin clients setup like this, I can’t think of any other situation where one would kind of half-establish an RDP connection and then not authenticate in the next ~20 minutes.

  4. i have the same problem Andy and my thin clients are joined to a domain
    it takes exactly 15 minutes to get the error. did not found any solution yet.
    i dont use HP connection manager so it’s not the problem.

  5. There is another small problem concerning using the User Graphic interface shell when you are dealing with a WES thinclient. When you prompt the user with a terminal server logon screen, you cannot lock the workstation. This is because of the automatic login in the registry.When they press CTRL ALT DEL, they lock the workstation with a non existing password that belongs to the default user.

    I want to provide that option, so I’m gonna look into that. Or did anyone already found a nice solution for that?

    • What we did was remove the ability for people to hit Windows + L. I’ll try to find the registry change we made and post it here. If you look around in your favorite search engine for disabling Windows hotkeys in the registry, that should do the trick.

      I was hoping to remap it to lock the remote session, but gave up after a short while because it was slightly more complicated.


      • [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System] “DisableLockWorkstation”=dword:00000001

        That will disable the thinclient WES locking.

        You can use CTRL + ALT + END to lock the RDS / RDP workstation. This is as intended by Microsoft. However, I am use you could change this behaviour by using tools like AutoIT or AutoHotKey to alter this. But users seem to be fine with using CTRL + ALT + END to lock the station.

    • Awesome news! At least know we know the reason! Thanks for posting, this has been the most active thread on my blog to date, and I’m happy to see that so many people are finding information that’s useful to them.


      • Yep just as I suspected all along, it’s by deign :p
        Good to have it officially confirmed though!

      • Wonder if there’s any threat to disable or change that setting, by the amount of traffic coming to this specific thread over the past few months, I’d say this is a setup many people attempt to deploy.

  6. I bypass the problem using thinwin solution. It opens a promp after we disconnect asking if we want to connect again or shutdown the client. Works great for us.

    • Thanks for the additional info! That is a viable option for some applications. In our environment, however, we didn’t want staff to have to open an RDP session, but wanted to have the credentials prompt open at all times.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s