Gracefully closing clients with Imprivata tap switches

[Kimberly_Kelly]

We are starting to use Imprivata in our healthcare settings to assist users logging into workstations using their badge to tap into it.  The Imprivata devices that use a Type 2 profile (meaning the workstation is logged into using a multi user network login and the user will log in manually to the apps available on the workstation) is my main question.

Initially, our security team was killing the obclnt32.exe when a new user tapped into the workstation to ensure the new user was not using the previous user's login in the OnBase Client.  What we are finding is documents and batches are locked because the client is not being logged out gracefully from the previous user as a new user accesses the workstation.  We are not finding that ideal.

Has anyone used a similar solution to Imprivata and found a way to more gracefully close out either the obclnt32.exe or obunity.exe upon a new user connecting to the shared device so that document and batch locks are released correctly?

[Ryan_Wakefield]

Kimberly,

I definitely understand what you are asking here as it makes a lot of sense. I think the thing that is getting me and I might need clarification on is when the user logs in, are they getting into their own Windows profile? As well, how do you have the Unity Client setup for login? Is it manual OnBase credentials login, manual Windows/domain credentials login, or automatic Windows/domain credentials login?

I don't see why we can't help you out here. I think just understanding a few more pieces will help us out.

Thanks.

[Kimberly_Kelly]

Ryan - 

I'll have to clarify with our security team that supports the Imprivata solution to  accurately answer your question on whether the user is getting their own Windows profile.  I can only share what my experience was during testing and the workstation was technically logged in as a multi-user type ID.  For example, the login ID on the workstation is "IMPMULTID01".  No matter who taps their badge to use the workstation, it is still logged into as "IMPMULTID01". 

When a different user taps in with their badge, obviously the workstation knows this is someone different than who was on it.  So I don't know if there is some Windows Profiles being used by user or not.

Unity Client is not being used quite yet in our healthcare settings, they are still using the OnBase Thick Client right now.  But we are looking to plan accordingly for when they do.  So in short, anyone using the Imprivata solution right now is only using the OnBase Thick Client.

When users are logging into OnBase (Thick or Unity), they are using manual Windows/domain credentials login.

I'll still ask for clarification about the Windows Profile to our security team.  

- Security team responded and the user does not get their own Windows Profile.

[Ryan_Wakefield]

Alright. So after reading your initial post (before your security team responded), I assumed they were all using the same Windows profile.

So with that being said, I think you are in a little bit of a pickle. I say this because since they are all using the exact same Windows profile, it really becomes difficult to not have to force close the Thick Client. While I know this isn't ideal, there really isn't a clean way to close out of the client without causing locks of some sort.

The best suggestion I can give you is to make it so that you will have to just do your best to educate your end users that they will need to close out of viewing of a document or anything else that you are encountering that the locks are persisting.

Now, this last thought is more so a pure theoretical and that is you could potentially leverage an RPA solution here. For example, user logs in, they do all of their stuff. Now, in order to log out they will have to double-click a "log-off" shortcut that can kick off an RPA bot that will check if the Thick Client is running. If so, then will will maximize it, click file, then click exit which should gracefully release any locks or anything that the user had out there still. The only downside to this is I don't know how many workstations this Imprivata solution is being implemented on, so I am not sure how many potential RPA bots you might have to use, if you even have an RPA solution today.

Again, just some thoughts, but as far as I can tell I don't see any other way to solve this other than to educate your end users to the Nth degree.

[Bill_Herrin]

We are using Imprivata with Unity and automatic Windows/domain credentials login. Type 2 Imprivata did not work in our workflow for the same reasons you are describing. Imprivata Type 1 login is more suited for our situation as the end user is at that workstation for hours at a time, not hoping between computers for short sessions.