Imprivata: OneSign Could Not Authenticate You

“OneSign could not authenticate you” is a rather generic error that can be the result of any number of different discrepancies. There are specific workflows that can cause it to appear even when everything is configured appropriately on the back-end, and there are several reasons that a user might encounter it aside from these. Unfortunately, Imprivata does not offer more specific error codes that you might identify the root of the problem with any ease. Sifting through logs has a tendency to be as confusing as clarifying, so I thought I’d put together a more concrete guide to troubleshooting this problem.

Is it only happening for one particular user?

By far the most common problem is that a user simply does not exist in the OneSign database. That you bothered to Google this problem leads me to believe you have already checked this, but none of the more advanced troubleshooting matters if this condition is not met. Ensure both that the user exists in OneSign by doing a search on the Users, Computers, and Domains tab and that he or she has an Enabled status. If you have instructed Imprivata to use directory status, you will need to confirm that the account is enabled in AD. Otherwise, ensure the user has not been manually disabled by another administrator.

If the user exists in OneSign and has an Enabled status, the next thing to ask is…

Are you out of licenses?

Open up the OneSign Administrator and look at the Properties tab. Scroll down until you see how many licenses you have available. If you’ve hit your limit, OneSign will begin locking people out of their desktops and you will need to free up licenses or purchase more as soon as possible (probably both).

Is it only happening on a particular device or group of devices?

This is one of those things where OneSign could probably give you more information, but doesn’t. Ensure first that the device is on the domain and has connectivity to the appliance. If the device has, for one reason or another, entered into offline mode and stored cached credentials for a user who has changed his password since they were stored: “OneSign could not authenticate you.”

If you are using devices that are not on the domain, check the Authentication tab of the computer policy for these devices in the OneSign Administrator. Scroll down until you see a radio button for “Authenticate with OneSign” and ensure it is selected. This will allow machines not on the domain (and which can reach the appliance despite that) to authenticate users without ever having to hit a domain controller.

Are you using a zero client?

The first thing to keep in mind when using the Imprivata bootstrapping on a zero client is that you don’t have some of the luxuries you might have on a thin- or fat client. That is, with a Windows back-end, you would be able to have a user authenticate through AD even if they didn’t exist in the OneSign database. They will be granted access to a desktop and simply have a disabled agent (the tray icon will be gray with a red X over it). They could then get any VDI desktop to which they were entitled.

This is not the case with a zero client. It will not bypass to Active Directory if Imprivata cannot authenticate them, so having a virtual desktop entitlement is insufficient to grant them access from these devices. There is not a way around it–you either have to disable the Imprivata bootstrapping for all users on that device, or spend the licenses on any user that will be touching it.

Ensure that the Imprivata is configured to accept the device’s authentication type. Go to the OneSign Administrator and look at the ProveID subtab of the Properties section. You will see a series of checkboxes–if you see any unchecked boxes, check them off and confirm whether this fixes your problem. If not, return them to their unchecked state afterward.

Does this only happen during a password change?

That is, are you only seeing it when users attempt to change passwords? I have another post about Password Reset Troubleshooting that might address more specifically what you came here for.

Does this only happen during proximity card enrollment?

I had this problem specifically on the Wyse Xenith 2, but it could conceivably exist elsewhere. If you only see this message when you are enrolling a card, see this post instead.

I hope one of these was able to answer your question directly, and if not, I hope it added to some brainstorming. In all honesty, there are a ton of different ways to get Imprivata to throw this error, and I do not doubt I have missed some. Feel free to leave a comment if I’ve been unhelpful here so far.

Windows 8: Revealing the Music OSD Without Changing Volume

The Windows 8 music OSD is a nice little feature of the oft-criticized operating system. The fact that it is so often criticized comes from a whole handful of little complaints about UI choices that are not always defensible. Case in point, the only built-in way to reveal the OSD is by using the volume change buttons. While this might make sense on a tablet or smartphone (I love my Nokia Lumia 920), it is less justifiable on the full OS. A member of the /r/windowsphone community recently asked if there were any way to make this music OSD appear without modifying the volume. The short answer is: technically, no. But we can accomplish effectively the same goal with a simple little workaround with thanks to AutoHotkey.

The Win8 Music control OSD

The Win8 Music control OSD

Option 1: Install AutoHotkey and Run the Customizable Script

I am a huge proponent of installing the framework on your machine and tinkering around with it. Lifehacker has my back on this. If you spend even a little bit of time learning how to take advantage of it, you can solve almost any problem you come up with (despite its name, it is not strictly for mapping hotkeys). If you’re at all interested in going down that path, I have provided the script for your use and modification below. The advantage to Option 1 is that you can set the hotkey to reveal the OSD to be whatever you would like.

Get the customizable script here

Option 2: Download a Pre-Made .exe

If, however, you’re not comfortable with or interested in installing AutoHotkey and touching the script yourself, I have compiled a downloadable .exe for you (also linked below), which you can download and use immediately. The drawback here is that you have to use the hotkey that I have chosen myself, which is Ctrl+W.

Get the pre-made .exe here

Now for what I meant when I said it was technically impossible to reveal this music OSD without modifying the volume:

My script does a few simple things. When you press Ctrl+W (or whatever hotkey you set if you chose Option 1 above), it checks the volume that you are currently at. It then sends the volume-up media key to bring up the music OSD, and then it immediately reverts back to the volume you were using prior to the key being sent. In testing this script, I ran it multiple times while listening to a song and was unable to identify any audible change in volume. I don’t know if that will be true for everyone.

Admittedly, this is a hack that shouldn’t be required in the first place, and I understand if it’s not the answer you came here to find. That being said, I was unable to find anything better out there, so please leave a comment if you come up with something better.


How to Suppress Java’s “The Application’s digital signature has not been verified” Prompt

Running a Java application with a verified digital signature is generally a pretty safe operation. Odds are you will indeed want to “always trust content from this publisher,” and once you indicate as much, the prompt disappears. The question is, how do we prevent it from occurring at all?

Technically speaking, there isn’t a way to suppress it. That is, you can’t configure Java to run these verified applications automatically regardless, with the registry, group policy, or otherwise. However, that is not to say we can’t hide the prompt from users anyway–it’s just a matter of addressing the discrepancy that invokes it. Essentially, we have to tell the machine to “always trust content from this publisher” in advance. It doesn’t suppress the prompt so much as it pre-answers it, and it unfortunately means you have to account for every Java application used in your environment, but the endgame is the same.

Step #1

The first thing we need to do is acquire the application publisher’s certificate. If you are currently using a machine that does not prompt you when you run the application in question, skip this step.

If, however, you are using a machine which will prompt you as soon as you run the application, go ahead and make the prompt appear. Ensuring the aforementioned box is ticked, choose Run. The certificate is now stored accordingly.

Step #2

Now open your Java Control Panel (the fastest way is to right-click the tray icon, which appears when any Java application is running). Navigate to the Security tab and click the Certificates… button. Identify the cert that you just stored and click Export to save it to disk. Make sure you save it as a .cer file.

Alternatively, if you skipped step #1 and you do not see the certificate on that page, you can open a command prompt as an administrator and run certmgr. From there, navigate to the Trusted Publishers/Certificates store on the left, right click the respective cert and choose All Tasks > Export. The default values in the Wizard are all fine, just choose where you want to save it.

Step #3

Now it’s just a matter of storing the certificate for future use. You can either import the cert manually on a master image or  individual endpoint, or even by throwing the cert on a network share and storing it dynamically with a logon script or with AppSense. To store the certificate, you can simply right-click the file and choose Install Certificate, or if you want to use the command line, you can install it with the following command:

certutil –addstore –f “TrustedPublisher” /path/to/yourcert.cer

That’s it! Again, remember that you will need to do this for every application for which you want to suppress the prompt. The same methodology can likely be applied to certificates which are not verified, but that’s a security risk you may not want to consider. Let me know if you find a way to actually suppress the prompt as opposed to just working around it, or if I lost you somewhere.

Environment Manager: AppSense Policy Not Applying

Troubleshooting problems with respect to AppSense policy can be difficult. There are a lot of different, equally valid approaches, and your problem might be easily resolved if you could just choose the right one. While getting AppSense to work is rarely a cumbersome task, there are a variety of ways that it can break. Here’s a few questions you need to ask if you find that your Environment Manager configuration is not doing what you think it ought to do.

Do you see at least part of your AppSense policy being applied?

Is the problem isolated to specific triggers?

In my experience, using the Session Disconnected/Session Reconnected triggers is unsuccessful in a Citrix environment–be it XenApp, XenDesktop, or VDI-in-a-Box. Try using the Session Locked/Session Unlocked triggers instead–they will accomplish ostensibly the same thing, but I have found them infinitely more reliable. Incidentally, the reverse has been true for VMware View.

Another very common problem with AppSense policy has to do with timing. Your particular AppSense policy might be perfect in terms of logic, but if the AppSense agent moves faster than your machine can handle, you can run into problems. Where possible, you should avoid the Login trigger. The more actions you add here, the longer your login process will be, and in some cases, the less likely your actions will be to succeed. If your end-user is not going to require certain things instantaneously, consider running the actions after the userinit.exe process stops. This is the Windows system process that builds the desktop according to the user’s profile, and the desktop is completely usable before it completes. Actions run after it stops will still take place early, but they will allow for a quicker login time and will take place in the background while the user begins to work.

Is the problem isolated to specific nodes?

It is important to remember that, as you look at nodes in the Environment Manager GUI, anything not nested runs simultaneously. Let’s say you have an action that sets a particular registry value in one node. In another, you have a group of actions that run dependent upon what that value is. You will want to be sure that any nodes with such a condition run after the value is actually set. Instead of running these nodes alongside the former, nest them beneath it. This will instruct AppSense to run the node that sets the registry value first, and only then move on to the nodes that rely on it.

Is the problem with specific actions?

The most common issue here is user rights. AppSense, by default, will run most actions as the currently-logged-in user. If that user does not have rights to perform the actions in the desktop, the actions will likewise fail when AppSense attempts to trigger them. Your resolutions here are manifold–you can use Application Manager to dynamically update user privileges in the desktop; you can simply add the necessary rights for users in the virtual desktop pool itself; or you can run tell AppSense to run these actions as a specific user who does possess those rights. The latter is not recommended by AppSense for security purposes, but I won’t judge you if you go that route anyway.

Is the problem with specific conditions?

One of the things that makes AppSense policy so dynamic is the use of conditions. However, the Stop if  Fails tag can be disruptive. This tag tells AppSense that all subsequent condition checks and actions should only be run if the Stop If Fails condition is met. Effectively, if you have multiple conditions that can pass in a single session (For instance, if the PC name contains ABC and if the IP address is in a particular range), checking the Stop if Fails box for any one condition tells AppSense that all conditions need to pass if the node is to be completed. Literally, if any condition fails, AppSense stops doing everything else that might otherwise come after.

That aside, in case this was not obvious, be sure to check whether your actions are able to run in the absence of conditions. This will pretty quickly narrow the scope of the problem if they run afterwards.

Does none of your AppSense policy get applied?

This one’s a bit more tricky, and far less common. The AppSense Bigot has yet another great post about this (though it is slightly dated as of this writing), and it addresses most of the flowchart that stems from the above question. However, if he does not answer your question, I have run into one additional problem that has crippled the entire solution. It single-handedly managed to turn a 100% functional AppSense policy into an utterly broken one. If this sounds like your problem, the good news is that the fix is likely very simple.

I was working at a customer site when we found that, after they installed a particular clinical application, their AppSense policy completely ceased functioning in their pool. Not a single action was run at any trigger, regardless. I am to this day embarrassed about the length of time it took to identify the reason for this, because it turned out to be so simple. As it turns out, AppSense policy itself gets stored on the local machine as a .aemp file in C:\ProgramData\AppSense\Environment Manager. This software, for reasons unknown, modified the permissions of the ProgramData folder, and regular users were no longer allowed to read its contents. This, in turn, resulted in AppSense being unable to read the policy itself, which in turn resulted in a completely unusable AppSense policy. We corrected the permissions error, and voila, everything worked again.

Hopefully that wall of text was sufficient to resolve your problem–or at the very least, I hope it put you on the right track. Let me know if none of the above was effective and I’ll see if I can’t offer any additional answers.

Imprivata – Citrix Receiver Stays Open at User Switch

Hypothetically, setting up your policies properly is enough to allow for User A to login to a desktop, get his Citrix virtual desktop, and then lock the machine confident that his session is secure and inaccessible to User B who logs in next. Unfortunately, as of this writing (and version 4.8, hotfix 1), that’s not always the case.

If you find that, unlike the ideal situation above, you notice that Citrix Receiver stays open during the switch and User B is able to see User A’s session after the fact (Followed shortly by a second Receiver session opening over top of the first), there are a few things to consider. First, take a look at your policy.

Policy Settings

  • On the Virtual Desktop tab of your endpoint’s computer policy, ensure you have selected “Automate access to Citrix XenDesktop or XenApp, and that you have chosen to shutdown the client and disconnect the user session.
  • On the Override User Policy tab of the same policy, tick the box for Challenges, set whatever hotkey you’d like, and set the policy to “Log Off User and Terminate Session.” This will ensure unequivocally that the desired behavior on this endpoint is to leave no session open if it is not being actively used. N.B. It will also (at least make an attempt to) close Receiver whenever the machine is locked, either actively by a user or passively due to idle activity.
  • Ensure you have chosen to automate virtual desktop access on the respective tab in your user policy as well.

Nvidia Drivers

If you’ve installed Nvidia drivers on your endpoint in the past, it is possible that you may need to start your image from scratch (or at least from a revision prior to the drivers’ installation). I have found at two different customer sites that the installation of these drivers was enough to go from a world where everything works to a world where Receiver stays open every single time. At this time, I am not certain of what specific change is made that causes Imprivata such trouble, but we do know that simply uninstalling the drivers does not revert the system to a state where Imprivata will work again. I was at a customer site where, thankfully, reverting back to an older endpoint image that preceded the installation of the Nvidia drivers was an option, and it resolved this problem for them. Sure enough, as soon as we installed the drivers again, the problems with Imprivata reappeared and we could find no way of reversing it. I wish I had better news, but this is the first thing to consider when facing this problem.

If this is absolutely not an option for you, there is a quick and [very] dirty workaround. Simply create an Imprivata EXO that kills the Receiver process at desktop lock. It looks something like this:

taskkill /F /im wfica32.exe

and it will absolutely make this work. I know of at least one enterprise using this method and it is effective, and although I am not aware of any stability issues arising therefrom, I can’t say I recommend this.

A second alternative is to take advantage of Receiver’s built-in Shift+F3 disconnect hotkey. You will need a script that sends the hotkey, then accepts the prompt that follows (one which cannot, as far as I am aware, be suppressed or bypassed). As per above, set this script to run at Machine Lock and you will be all set. Note that you may want to turn off system sounds if you are not interested in hearing a *ding* every time a user disconnects his or her session.

No Nvidia?

  • If you are using Win7 on your endpoint, be sure to disable UAC if you haven’t yet.
  • Symantec has been known to interfere with Imprivata’s ability to control processes. If it is not essential on your endpoint, I encourage you to remove it, as this will likely resolve your issue. If that is not an option, ensure that you whitelist both the SSOManHost and ISXAgent processes so that they are able to operate freely.

Hopefully at least one of the above was a viable solution for you. If not, please let me know in the comments (include any possibly relevant information about your environment!) and I’ll see if anything else comes to mind. Good luck! – Extra Citrus Fresh

I decided I would invest a little more into this hobby and get a bit of webhosting from A Small Orange. Basically I wanted more control over this blog than the free version of WordPress was gonna give me, and I’m impulsive. Already had the domain, and it was only $30 for the year, so don’t judge me.

As of this writing, the coupon code “orangelover” will net you 15% of your entire purchase. I also get money if you use that link to sign up, which is nice, but that’s not the point of this post.

I’ll update this if their service turns out to be exceptionally good or bad. No complaints during these first few hours. Huzzah?

Determining the Active Tab in Chrome/Firefox using AutoHotkey

One of the limitations of using AutoHotkey to control Google Chrome comes in the form of determining the active tab. I have seen this brought up in a number of different places online and have seen some clever means of accomplishing this goal, including looping through all the different tabs and determining the names of each before acting on any of them. Though this would admittedly provide more control, it strikes me as heavy-handed and inelegant.

If your only goal is to determine the active tab (so you can, for example, perform actions elsewhere before reactivating the tab), a much simpler solution is to use the PixelSearch function. Assuming you are not using some awful theme wherein the active tab color is completely indistinguishable from the inactive tabs, it’s just a matter of searching along the tab bar for the appropriate color and storing its physical location on the screen for later use. From there, you can open a new tab, or navigate to some other tab using simple keyboard shortcuts (like Ctrl+1 through 9, for instance) and then return to where you were using that information.

For example, I use a web application called SubSonic to stream my music, and I wanted to add keyboard shortcuts to control the Flash-based player open in a pinned tab in Chrome. By simply using #IfWinActive I was able to determine whether or not I was already on the SubSonic tab in Chrome. If I found that I was not, I determined the X and Y coordinates of the tab I was presently on, used Ctrl+1 to activate the SubSonic tab (knowing that I always kept it pinned as the first tab on the left), ran my macros and then navigated back to my last tab with a click. Excluding the various macros for the SubSonic stuff, the script was as simple as:

PixelSearch, Xtab, Ytab, 45,26,1771,26,0xFBFBFC,0,Fast ; Determines the active tab

Xtab += 25 ; The first white pixel will be to the left of where you’ll want to send your click later.

Send ^1 ; Activate my pinned SubSonic tab

Sleep 50 ; Don’t wanna move too fast!

MyMethod() ;  My macro went here…

Click, %Xtab%, %Ytab% ; Return me to the tab I was on in the first place.

It is not the prettiest thing in the world, but until there is some more direct means of interacting with tabs in Chrome, it’ll do the trick.


AppSense PowerShell API for Configuring Environment Manager

I recently discovered the AppSense PowerShell API for creating Environment Manager configurations (There is also one for the Management Center, but I haven’t touched it yet). I don’t know for how long it’s been available, but I only came upon it because a customer pointed out a .pdf whose title, “AppSense Environment Manager Configuration API” referenced its existence. This customer also happened to have 350+ printers, and wanted a node for each one. Every node was to contain ostensibly the same set of conditions and actions, so it was a pretty fortuitous discovery and saved me a ridiculous amount of clicking, copying, and pasting.

The document explains in sufficient detail how to use the API and can be downloaded from (Requires login), but the commands themselves are fairly clean and easy to work with. For our needs, I wrote an AutoHotkey script which in turn generated a .PS1 PowerShell script (which ended up being roughly 3000 lines!). This was able to map out all of their printers while saving me a lifetime of arduous GUI navigation. That being said, it worked just as well as if I done exactly that. Actually, it destroyed the possibility of human error for individual nodes, so it probably worked even better.

The Appsense PowerShell API is only capable of generating new configs (and not modifying existing ones), but this is overcome simply by generating the nodes and subnodes you want and then copying and pasting them into your primary configuration. Here’s a piece of the script I generated (made generic to a point). Note: PasteBin link, opens in a new window.

It’s just a matter of designing an object with its respective parameters and then adding it as a child of a given parent (the parent can be a node, sub-node, action, or condition–your call). The above will add a node called Windows Printing, give it a sub-node called Printer 1, and populate that sub-node with a condition that checks the client’s computer group, an action that maps the appropriate printer, a condition to check a secondary AD group, and then an action to set it as default. Finally, it saves the config for your use.

The AppSense PowerShell API document will go into a fuller explanation of what each string and boolean defines, but hopefully this gives you something of a skeletal representation of a configuration-generating PowerShell script.

Modifying the ThinPrint Refresh Timer in VMware View

If you are using VMware’s ThinPrint solution to map printers, you may already be aware that the tool will check every 30 seconds for new printers by default. Effectively, ThinPrint is supplied with an interval, and every time that interval passes, it looks for any printers that have been mapped or unmapped from the endpoint. If it finds any changes, it forwards them to the virtual session. After that, it begins the countdown anew, and the cycle repeats.

If that standard 30 second interval is too long for your liking (and you just need to have your printers faster than that), or if it is too short (and causing too much of a latency), you can modify the ThinPrint refresh timer with the following registry value:

HKEY_LOCAL_MACHINE\Software\ThinPrint\Client “PropertyRequestTimeout”

This DWORD value will be set to 30 by default. Simply set the number of seconds you would prefer and you’re all set.