Recently got involved in designing and building a new awesome blistering fast Omnissa Horizon environment for a hospital.
This new environment is based on the latest Horizon ESB, DEM, AppVolumes, Windows 11 etc. And as many hospitals do, they use Imprivata OneSign.
We ran into a bug. When logging in to the desktop (either Imprivata Client or Horizon client directly) we got confronted by the Imprivata GINA screen. Once again entering credentials and the desktop continues. Reconnecting on the other hand works single sign on. Not very DEX Friendly.
Numerous log traces, event viewing etc. (not going to bother you with that) there are 2 main issues resulting in this issue.
#1 the main issue: Imprivata tries to hook into MS Defender SmartScreen.
Disabling Defender Smartscreen solves the issue but since the customer decided to move to MS Defender. well not an option then, right?
Also, an important side note: although many alternate AV solutions (if used) disable Defender but not Defender SmartScreen! You can detect this by the running SmartScreen process in the session.
Another way to fix the issue is to prevent Imprivata from hooking into SmartScreen.exe. You can do this by adding a registry key to the Imprivata Agent
The complete path:
HKLM\Software\SSOProvider\ISXAgent\HookInit
Create a new String Value named: SmartScreen.exe
Another sidenote here: injecting this key after boot and restarting the SSOmanhost service does not solve the issue. Embed this within your golden image! Perhaps a GPO preference is early enough, I did not test this.
#2 The Imprivata policy assignments and Horizon Instant Clones.
Imprivata has been working fine with non-persistent desktops for years.
Normally you create an alternate computer policy for your VDI Desktops with the correct settings and make sure these are assigned automatically to your VDI’s by, I suspect, filtering on the computer name. Think VD* or a variant on this.
The VDI’s boots up, Imprivata service starts, correct policy applies and good to go.
But the story with Horizon Instant Clones is a bit different...
What makes Instant Clones zo amazingly fast is that they don’t regularly boot but get forked of a template machine. There is no regular boot process.
The effect is that the VDI reports itself and thereby the correct policy is assigned after the user logs in if the computer name is not known and thereby assigned the correct policy yet.
The solution to this effect is relatively simple to mitigate:
A template machine always boots up starting with “it” following a number. You will also find a computer in active directory in the OU where the matching the pool configuration.
The solution is to make sure this template gets the same policy as the Virtual desktops, if you don't the Default Computer Policy applies and since you think security is super duper important this one is quite strict.
For example, let’s say VDI_Default_Policy is the correct computer policy for my Instant Clones, make 2 policy’s 1 for the naming convention matching the VDI’s and one for the Instant Clones Templates.
To be entirely complete you could also add the machine used to build the Golden Image.
That’s it! Happy SSO!
Any questions or remarks? let me know!
Ps. To fix the agent sign within the session when using TrueSSO check a previous blog: