UEM Logon Tasks - Blocked by a Lock Screen?

[epa80]

We utilize Imprivata as our SSO here. Part of the initial login process includes locking the desktop after logging in. It seems that any/all of our UEM logon tasks we're utilizing do not run due to this lock screen. As we stuck with that? We know there's an alternative by just creating startup scripts, but, we'd prefer the logon task functionality.

Would love to hear there's a setting we can do to get around that lock screen. Thanks.

[Pim_van_de_Vis]

I'm not that familiar with Imprivata, but can't you configure Imprivata to not lock the computer at logon?

[EricNichols]

It may be related to incomplete\missing registry keys that the credential provider should be creating. See how we addressed something similar with a login task Ctrl-Alt-Del "secure attention sequence" screen requires clicking on user tile.

[epa80]

I could ask our Imprivata team that but, it seems to be their design that a VM session starts with a lock screen on top for the user to come tap in. Our thin clients all autologin to View with a generic account, get a floating pool VM, then lock the screen.

[EricNichols]

From the little I just read about Imprivata, I am curious if it changes the default shell? What do this key values have?

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon (Shell)

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon (Shell)

If it is not explorer.exe, this might be preventing the tasks. You might be able to prevent the default lock by changing it back to explorer.exe. Id be interested to hear what you find.

Here is an article that will not solve your issue but is interesting to read none the less. Troubleshooting single sign-on into a remote desktop in View - VMware End-User Computing Blog - VMwa...

[epa80]

Just to elaborate some on the workflow:

We have Dell/Wyse ThinOS Terminals that auto login to a View pool via a generic account. Upon getting a desktop, the session is immediately locked. A user would then come up and either tap their badge or type in their credentials for the SSO to process them. At that point the session unlocks, they're presented with a desktop, and off they go. From a Windows perspective, that generic user is the user logged in, Imprivata just passes along the tapped in creds.

In the registry I only find Shell under the HKLM Winlogon, and it's set to explorer.exe. Hopefully I'm looking at what you mean.

The thing is the lock screen *IS* by design with our SSO/Security team, so, I may be stuck with the option of just having them "not lock". If they want it to lock, my hands are tied. I've recently brought up the suggestion of waiting maybe 10-15 seconds after login to the desktop, THEN locking but, not sure how far I will get with that.

Most tasks I am doing as a Logon task I can switch to Startup scripts, but, not all.

[EricNichols]

It looks like you are using Fast User Switching for Kiosk Workstations but should be using , Fast User Switching for Multiple desktops if you want the logon tasks to work correctly.

Fast User Switching Overview | Imprivata

It looks like these Citric Virtual Desktop users https://wow365.nl/platform/thinkiosk-fast-user-switching-imprivata-citrix-demo/ found a solution that uses ThinKiosk. I bet Stratodesk of Thinstation could be used instead. If you reach out to Imprivata they would guide you.

[epa80]

Yeah, the workflow our design team has gone with is not the preferred Imprivata way. We expected some hiccups because of this, and, well, it looks like this is one. Our VDI are delivered through View, and we have a mix of apps delivered via XenApp or App Volumes. It's kind of a melting pot right now.

If I can't get the team to agree on a lock delay, I may be stuck with my logon tasks. We'll see how far I get. Those other products you mentioned, I might be able to look at them at some point, but, we have a go live in about 2 weeks, so, I won't be able to look into anything new for the time being.