Process Monitor from Microsoft Sysinternals Suite

As referenced in When Vendors Refuse to Yield, here are the dirty details of how I got a poorly written Clarion application to work correctly with non-administrative accounts on a terminal server.

To start off, it is possible that you might encounter an application that relies on elevated permissions of privileged user accounts in order to function correctly.  As a basic security principle, we know that least privilege is the way to go.

For several months I fought with a vendor who told me I couldn’t make their software run in a terminal server environment.  I did prove them wrong.  After the point of sale software was configured on the terminal server (Windows Server 2008) I was able to successfully run credit card transactions and access information from the database as an administrative user.  However, as a standard user, I could hardly click a button without error messages screaming at me.

After some research I decided to follow a hunch, as they call it in Star Trek.  I downloaded Process Monitor from Microsoft Sysinternals Suite with the intention of finding the root cause of several access denied messages.

This wonderful tools allows you to observe everything your CPU is doing.  I set the filter to only display events from only one specified process.  This allowed me to narrow down the results and see something useful.  I further drilled down and told ProcMon to only show me events that had a result of not success.  I turned on the capture and initiated the event that caused the access denied message and then stopped the event capture.

After sifting through hundreds of entries and checking file and folder permissions, I finally found the culprit.  The application created a folder I was not aware of in the C directory and within it there was a .tsp file (Clarion TopSpeed database file).  Once I located the file, I added the needed non-administrative user permissions to the file so that non-admin users could successfully run the application in the terminal sessions.  And it worked!  I had previously spent several days trying to pinpoint the cause of my permission issue and I might never have found it were it not for Process Monitor.