Items requiring elevation for an app to run as non-admin user

Question

I have a problem with an application that will run only for admin, not for regular user.

It is a Chrome plugin for a client's DVR (security camera monitoring) system on a Windows 10 computer. I install the required (Chrome) plugin as a local admin. Logged in as Admin, I can connect to the DVR in the browser and see the video stream. But for a a non-administrator user, not only can I not get the browser to show any video output, but immediately upon Windows logon, Windows 10 the blue spinning circle appears alongside the mouse pointer, and this persists as long as the user it logged on, even when using other programs.

The operative program is here: C:\Program Files (x86)\LocalServiceComponents\LocalServiceControl.exe. The plugin installation adds an entry into Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run in the registry by default to auto-run that app for any user. I isolated that factor by temporarily removing that registry entry so I can run the program manually. I can run that app manually as admin, and that enables me to see the video stream in the browser. (I cannot see video without it running). But when logged onto the computer as a non-admin, as soon as I start this program, we are back to spinning blue circle and no way to get the video stream to come up in the browser.

My question is this: what possible areas may require Users to have elevated access in order for this to work for the Users group in order for this to run non-adminitratively. Most often, granting read/write access to the program's folder or any related ProgramData folder seems to allow an app to run, but not in this case. I have tried these things:

1. If I enable UAC and then open the plugin manually as the non-admin user, I get a popup, and if I then enter the admin credentials, I can open the browser and see the video stream. But even if I were willing to leave UAC enabled and grant the user the admin credentials--which I absolutely am not because it is entirely inappropriate--this program is not something a user would load manually; it is intended to be auto-run per the registry entry.
2. I tried giving Users read/write access to the C:\Program Files (x86)\LocalServiceComponents folder, subfolders, and all files inside.
3. I even created a scheduled task to run the app at logon of any user using the System user, then again as a local admin with password saved, and either one does start the application, and there is no explicit failure in the browser as there is when the plugin is not running, but the video stream never starts. That is true even when I am logged on as the admin user named in the scheduled task.

I also checked but could find no ProgramData folder that may require hard-coded enhanced security but could find nothing.

Are there other places, apart from perhaps combing through the dozens of potentially-related registry entries to look at security of each (something I suspect to be a complex lost cause), that I can check to determine if there is some file system or other security elevation I can impose to allow the end user to run this.

The bottom line? The business owner hears from the video system installer that I (the IT contractor) must not know what I am doing, since I cannot figure out how to get this to work, even though the video installer has never before tried installing the video client plugin on a computer that is on a domain or otherwise requires logon as a non-admin user.

Answer 1

If anyone is still looking for this answer, as that's how I stumbled upon this thread, here is what worked for me.

You need to create a Custom Application Compatibility fix, or, shim. It's a sdb file that you install to the client (it shows up in Apps & features/Programs and Features) and it let's the LocalServiceComponent run as admin without UAC.

I have it attached if you want to try it. I know, who wants to risk installing a file from the internet, but it does work as intended as long as you installed the LocalServiceComponent to the default directory (C:\Program Files (x86)\LocalServiceComponents). Plus you can review the file in Application Compatibility Toolkit "Compatibility Administrator" program, found in Windows ADK.

HikVision.sdb.txt

Download and you can delete the '.txt' part if you want, don't have to.

Then run in elevated cmd:

sdbinst <path\to\>HikVision.sdb

Don't want to trust the attached file, you can make your own:

1. Download Windows ADK
2. Install feature 'Application Compatibility Tool'
3. Open Compatibility Administrator (32-bit)
4. Right Click 'New Database'
5. Create New > Application Fix
6. Create your own names [not important], select program (C:\Program Files (x86)\LocalServiceComponents\LocalServiceControl.exe) with 'Browse' button > Next
7. Check 'RunAsInvoker' > Next
8. Check 'ForceAdminAccess' > Next
9. Nothing checked > Finish
10. Save As
11. Create your names [kind of important, 'Database Name' is what shows up in Apps & features/Programs and Features] > Save
12. Run command (the one above)

   sdbinst <path\to\my_custom_file>.sdb

Answer 2

Download and install Process Monitor.

https://learn.microsoft.com/en-us/sysinternals/downloads/procmon

Log in as the non-admin user, but launch procmon.exe with "run as administrator". Set a capture filter for "Process is LocalServiceControl.exe". Also select "Drop filtered events". Under Options/History Depth, set it to 1 million entries.

Click the magnifying glass icon to start the capture. Then launch the program as the non-admin account. When you reach the point in time where "the video should have started by now", click the magnifying glass to stop the capture.

In the Result column, look for Access Denied. If it's a simple file permissions problem, it should show up here. You can also use the Tools/File Summary option and see if the program writes to a log file somewhere.

If you don't find any denied entries, then you may have to compare a trace of a working vs non-working run. When any process loads, you'll see it loading dll's, reading registry keys, files, as part of it's initialization. At some point the one that worked will start making different calls. This is kind of tricky here because you are looking for the proverbial "needle in a haystack".

You may also need to trace all programs if the "error" is occurring in a different process.

You should also be asking the system installer "how do I turn on debug tracing to find out what error YOUR software is encountering".

Good luck.

Update: also look at the registry key summary and see if the program tries to read any values named "debug" in it's application registry settings. You might also find debug setting if the app has a config file somewhere.

Did you search the internet for that software name and see if other users had the same problem?

Answer 3

So I ran Process Monitor as admin, and while I do not understand all of it, of the 1671 events generated when opening LocalServiceControl.exe, there are 82 where Operation = CreateFile. I cannot see what files are being created; however, I do see the paths. Aside from C:\Program Files (x86)\LocalServiceComponents, which is easily allowed by granting Users full access to that folder, here are some of the Paths:

C:\Windows\Prefetch\LOCALSERVICECONTROL.EXE-BBF52986.pf
C:\Windows
C:\Windows\SysWOW64\kernel32.dll
I do not understand why there are both folders (with no file name) and files under Path, and maybe this is all irrelevant, but if it actually writes to those locations, I cannot imagine how I am going to get past this for a non-administrative user.

I have attached the log file. It is actually a .csv file, but I saved it as .txt to try to get it uploaded here.
51312-logfile.txt

Answer 4

Well, as much as I cannot yet fully recommend the answer I worked out, and it may be only an interim answer until I can solve the underlying problem, I have found a gadget online called RunAsTool from sordum.org.

While logged on as a computer admin, I opened the tool, and it asked me for admin credentials. Once open, I was able to drag my C:\Program Files (x86)\LocalServiceComponents\LocalServiceControl.exe into it. Then I told it to create a shortcut. This created a shortcut to the RunAsTool exe with an argument specifying the LocalServiceControl program.

But now I can use that shortcut as any user to run that one program and it does indeed solve my problem. So, near as I can tell, the tool caches the admin credentials somewhere and passes them to the specified application, allowing all cascading calls to run as administrator.

In my case, though, the goal is to ensure that the user can get the video stream to start within Chrome, so I do not want the user to ever have to double-click the RunAsTool/LocalServiceControl shortcut. On the other hand, the original configuration of LocalServiceControl.exe as installed was for it to be embedded in the Run node in the HKLM anyway. So I put my shortcut into C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup, that is, where it will auto-start for any user, functionally replacing the stock registry entry.

And now everything works correctly.

Disclaimer: as slick as this seems, I generally do not like using third-party gadgets, since they tend to be one-off things that get outdated or pop up later to complication things. In addition, my first consideration is always risk-avoidance, and it is difficult to know for certain whether any such gadget has any ulterior motive or nefarious embedded content. So I have insufficient knowledge of this gadget at this point to recommend for or against its use; I can only state what it did for me in this particular situation. On the other hand, sordum.org has been around a long time and seems to offer many very useful gadgets. Besides that, I like this bit of the "who we are" part on their site, "When I was in Turkey (July 2009) I have noticed that youtube was banned there, then I have written a little vbs script to change the DNS settings , It was the first version of Dns Jumper [one of their other gadgets], People loved it (except Turkish government) "

Ha, ha, ha! Anyone writing a tool to stymie government censorship attempts can't be all bad, for sure. And YouTube needs no help with censorship; they can do that on their own without any help from the Turkish government.

Answer 5

Sorry...our posts just crossed. Here are responses to a couple of your points.

1. Vendor contact: I do indeed infer that this is Hikvision based on the propensity of Hikvision-related returns when I search for the app name, although I am mystified as to why there is no direct download on their site for this plugin, only their full client software packages. One of my first thoughts before I posted here was to see if perhaps they had a newer version that was properly written to work with Windows security, but I could find nothing. I would have called them, but this all came up in such a way that it was Christmas Eve that I was desperately trying to get this project behind me. What would have been a 10-minute admin install had the software been properly written has now taken perhaps six hours with me working remotely on my client's computer at his home across an SSL VPN with 5 MB DSL at my end and his. Given the date & time, I knew no tech support would be available, so I came here first. Besides that, I have bumped my head into things like this two or three times in the last 25 years managing corporate information systems, and I have always wondered if there were some generalized way around the problem, a way to force an application to run as administrator without prompting the end user for credentials or inappropriately embedding the credential in a .bat or .cmd file. Contacting the vendor will be a Monday morning thing if I have no solution before then.
   2. Path not found entries: keep in mind that I had to run my Process Monitor while logged on as a computer administrator, that is to say, when the plugin loads correctly, not while in a failing or error condition as is the case when run under the end user account. In fact, all six of the "PATH NOT FOUND" entries in the ProcessMonitor log file are paths that do not exist even when I run the app successfully under the administrator logon. While that may indicate other sloppy work on the developers' part, a problem that occurs only for a limited-access end user must hang on items that are successful when run as administrator (i.e. presumably successful in Process Monitor) but which I must infer (since I cannot actually run ProcessMonitor as an end user) would not be successful when run as an end user, not items that also failed for admin.