First and foremost, I should note that this post will deal specifically with RFIDeas-brand proximity card readers. If you are seeing this problem with any other variety, hopefully I can provide some insight, but I won’t provide a fix. Additionally, this article assumes that you entitle Imprivata users to enroll a single badge at a time, and that you provide them the ability to overwrite their badge enrollment. With all that being said, let’s dig in.
You tap your brand new badge on machine A, and enroll your username and password at the prompt. You can tap out and tap in on this device ad infinitum, and the badge works fine every time. You then attempt to roam to Machine B, but when you tap your badge, it asks you to enroll it again. You do so, and can tap out and back in safely once more. However, when you go back to Machine A, you are asked yet again to enroll the same badge you just enrolled twice.
If you were to enroll the badge on Machine A and open your OneSign Administrator Console to your user’s page, you would find a Badge ID currently enrolled to your account. If you then enrolled that same badge on Machine B and checked again, you’d find a totally different ID, and it would probably look like a different format. The problem is not that Imprivata is getting confused about what Badge ID is stored on the card, but rather that the readers themselves are reporting different IDs to the appliance. The order of the bits being sent to the appliance is inconsistent between devices, and this discrepancy results in Imprivata thinking the same badge is actually two (or three, or four) different badges. There is a configuration written to the memory of the proximity card reader itself that determines in what order the bits are read, and therefore, reported.
I have seen customers order a single box of readers with as many as three different configurations pre-programmed within. Users would get asked to re-enroll the same badge every time they touched one of these devices. What’s more, every re-enrollment would break recognition of the badge on the other devices. It’s not that any one of these configurations is right or wrong, it’s just that a consistent configuration does not exist across the board. The fix, therefore, is to write a consistent configuration to each reader. Of course, your immediate question becomes: How do I do that without touching every single reader individually?
1. Download RFIDeas’ cmdpcprox utility from here. This will allow you to program readers from the command line. Run the installer, which will extract some portable files to a folder.
2. Connect one of your badge readers to a device with the cmdpcprox.exe utility and open a command prompt to the directory in which it resides. Run the following command:
This command will output the active configuration of the connected reader, and save it to a file named config.hwg.
3. Copy all the contents of the cmdpcprox directory (including the .hwg file from Step 2) to a network share accessible to all users.
4. Create an Imprivata extension object that runs at desktop lock, as well as at session reconnect. You may want to add a pause of a couple of seconds for the latter trigger if you see errors when you test this. The EXO should be “written to a file with an extension of .vbs” and then executed, and it should look something like what you see below. Note that you will need to modify this to suit your environment:
Set objShell = CreateObject(“WScript.Shell”)
userProfilePath = objShell.ExpandEnvironmentStrings(“%UserProfile%”)
hwg = userProfilePath & “\config.hwg”
Set objShell = nothing
Set FSO = CreateObject(“Scripting.FileSystemObject”)
FSO.CopyFile “\\network\path\to\config.hwg“, hwg
file = “\\network\path\to\CmdpcProx.exe”
args = “-readconfig=” & hwg
CreateObject(“WScript.Shell”).Run file & ” ” & Trim(args), 0, True
Set FSO = nothing
5. Lastly, enable the EXO in the computer policy of any Windows-based endpoints or in your virtual desktops if you are using zero clients. You can use the same EXO for both in the case of a mixed environment.
So, what does this do, and more importantly, why does this work?
The script copies the config.hwg file you exported from one of your readers (in Step 2) to the local computer or virtual desktop, and then instructs the network-hosted utility to write that configuration to the device connected locally. In the case of a Windows-based endpoint, this will take place as the local OneSign agent locks the desktop. A zero client has no full agent of course, but it does pass the USB reader into your virtual desktop, and the configuration can be programmed while it is connected there. The configuration file is deleted after this is accomplished, and that reader will be reliable for everyone using it in the future — not just the user who triggered the script. More importantly, it will enforce a consistent configuration on every single reader, meaning the same badge will be reported as having the same ID regardless of the device that reads it.
Using the VBscript above allows all of this to happen silently with no impact to the end user. You can certainly use simple batch script if you’re not concerned with users seeing a brief command window flash from time to time.
Lastly, just for the record, the cmdpcprox utility does not seem capable of reconciling a network path to the config.hwg file. I add this in case you were wondering why we copy it locally before running the command.