I recently came across a bug that impacted apps accessed via Horizon RDSH from a Type 2 kiosk where Fast User Switching was enabled, so the “Type 3” Imprivata agent was installed on the RDSH side as well. If the application allowed disconnects/reconnects (no immediate logoff on disconnect) and the RDSH session was disconnected from a Type 2 kiosk, the reconnect process would hang for exactly 2 minutes, and the user would eventually be presented with the Imprivata GINA from the RDS host. First login to the RDSH session works fine. This appears to affect various versions of both Horizon and Imprivata.
This is a typical setup for Epic with FUS (Fast User Switch) enabled, where the RDSH session is logged in from a generic “autologon” account on the Type 2 kiosk. Whoever badges in or authenticates to the Type 2 kiosk will instantly flip to the new user, with the help of Imprivata’s Epic Connector. Under normal circumstances with this workflow, the session would not disconnect. However, in the event of some sort of network issue that triggers a disconnect, and the user attempts to reconnect to the app, that is where the problem could really come into play.
As of this post, Imprivata is still investigating the root cause and fix of the hang, which is potentially an API issue on the Microsoft side. With no support resolution in sight, and the ability to reproduce in my lab, I started combing through various settings to try and find a workaround. I finally came across one that proved to work – changing the credential provider on the RDSH policy back to Windows.
To set this, go to the Computer Policy assigned to your RDS hosts in the Imprivata Admin Console. Underneath the General tab, scroll down to the Desktop Experience section. Choose the option to replace the Imprivata Credential Provider back with Windows. Because we’re using Windows auth to login to the RDS host, the Imprivata Credential provider is not needed anyway.
After syncing the RDS Imprivata Agent with the server, the issue immediately goes away. Hopefully this helps anyone attempting this workflow, and I will update this post if a fix is released for the default Imprivata credential provider. Feel free to let me know if you see this in your environment, and if this workaround helped!