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

Thank you for all your help!

I certainly had a refresher on ProcMon in this process. I will continue to use the third-party RunAsTool for now and look for a better answer by checking the failure auditing processes you recommended, then contact the vendor if that does not reveal the cause.

Software is just sometimes so badly written that it may write to System32 or other places where I absolutely will not open for non-admin users. I find it hard to believe that any developer in his right mind would not think to test it all for a non-admin user once he finishes developing within a presumably admin-enabled environment. That is way to obvious to be missed by any substantial developer, yet I have seen it a number of times over the last 25+ years in this business.

Answer 2

Hello, everyone.
It's been a while, but I'll write here in case someone comes across this post.
The process C:\Program Files (x86)\LocalServiceComponents\LocalServiceControl.exe is the Hikvision program for working with cameras in the browser. https://www.hikvision.com/en/support/tools/hitools/cl31f95c645ddb0235/
I tried several ways to solve the privilege escalation issues. To begin with, I investigated whether the elevation of privileges was written in the project manifest before compilation. This can be checked with the Sigcheck utility from Sysinternals. The following command returns the manifest.

sigcheck64.exe -m "c:\Program Files (x86)\LocalServiceComponents\LocalServiceControl.exe"

In my case, there was the standard "requestedExecutionLevel level='asInvoker'". This means that the program should run with the rights of the user who launched it.

After that, I used Sysinternals Process Monitor. In the filters I used: Process Name is LocalServiceControl.exe and Result is ACCESS DENIED. I ran the LocalServiceControl.exe process and answered "No" to the request for elevation of privileges. I got two "ACCESS DENIED" errors when the process was executing RegOpenKey in the keys:

\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\PnpLockdownFiles
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinSock2\Parameters

I gave read permissions to users for the first registry branch. One error disappeared. However, the "Users" group already had read access to the second branch. Then I looked at the "Desired Access:All Access" entry in the RegOpenKey call. I searched the Internet and found the answer that requesting "All Access" rights will always trigger a request for elevation of privileges and it is recommended to use the READ_KEY request. This means that I can't influence the privilege request in any way.

I tried to create a service from the LocalServiceControl.exe program using "sc create". I created a separate user with administrator privileges on whose behalf this service was launched. When running as a service, the "ACCESS DENIED" error did not appear. But, apparently, the program does not return the startup code. Because of this, the service control manager does not know that the service has started and stops it by timeout.

That's where I stopped trying. We decided to stop using this program. Instead, we installed IVMS-4200 and continued to work with the cameras through this program.