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

Some thoughts:

Log in with the non-admin user and open a command prompt. Run "runas /user:YourAdminAccountName cmd.exe". Then in the command prompt window CD to the folder and run promon.exe. That should allow you run chrome as the user and procmon as the admin. Path not found is a common entry and doesn't necessarily indicate an error. .

Can LocalServiceControl run as a service? Or does it have to run as part of the user's session? Maybe try defining a scheduled task that runs at startup to launch that program. Run the task first as the SYSTEM account, and then as the admin account. If it can be a service you can use NSSM. (Another gadget.)

Run gpedit.msc and in Windows Settings\Security Settings\Local Policies\Audit Policy, enable failure auditing for object access. Something might show up the security eventlog.

FYI: I'm retired now, so I try to answer questions like this to keep my mind active. Kind of like a daily crossword puzzle. I didn't know about sordum.org. Thanks for the tip.

Answer 2

I am posting separate answers to separate parts of your post, since it will run too long otherwise:(

Service: I am not sure how I would make an application run as a service when it is not designed to run that way. This is some Chinese-written plugin (at least as evidenced by some of the poor design, current case in point, and the grammar in the help files), so there are no options when installed; it installs as it is or not at all. I once tried making a service on a server by adding what I thought looked like the logical registry entries to load an application, and then my server would not boot, which took most of my remaining hair sent me scrambling for a boot floppy disk (this was a while ago) to get it back up and running again. So no, I suspect there is no way to run this as a service.

Answer 3

RunAs

I just tried this while logged on as the end user: runas /user:MyAdminUser C:\Users[User's ID]\Desktop\ProcessMonitor\procmon64.exe. That got it to run, and I filtered to LocalServiceControl.exe. By the time I could stop the Capture maybe one second after I started the LocalServiceControl, I had over 100,000 entries within the filter. So I downloaded the admin and non-admin filter logs, converted to Excel, then pasted the admin Operation & Path columns into new columns in the non-admin one and set up a boolean formula to show FALSE where they diverge. The two files diverge with respect to Path on line after line 61. This is a RegOpenKey and shows this path:

Admin:      HKCU\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers
Non-admin:  HKU\S-1-5-21-1075141860-3377990681-1942396677-1139\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers

However, the result for both is NAME NOT FOUND, and they converge again on the next line, so I assume that is inconsequential. But starting with line 67, they diverge completely for both Operation and Path:

Line 66
    Operation   RegCloseKey
    Path        HKLM\System\CurrentControlSet\Control\FileSystem
    Result      Success

Line 67
    Admin
        Operation:  QueryOpen
        Path:       C:\Windows\SysWOW64\apphelp.dll (and this appears nowhere in any subsequent path for non-admin user)
        Result:     Success
    Non-Admin
        Operation:  LoadImage
        Path:       C:\Windows\SysWOW64\shell32.dll
        Result:     Success

After that, there is so much divergence that I cannot easily see how I can just shift one set up a line or a few lines to match the other; they seem to go completely different directions. So there is no smoking gun here that I can see.

Answer 4

One of the things I did early in this process, well before I posted (as noted in #3 in my original post here) was to dive deeply into running the application as a scheduled task. I tried it every way I could think of: running at Log On of Any User but using System user, then domain admin user, then local admin user, running at log on of the specific end user but running as an admin user, and probably a couple more ways. None of them resulted in spinning cursor because, of course, they loaded it under a different user, but none of them worked in the browser, either, so I infer that it must run as part of the logged-in user's session, and the only solution is to figure out what files/folders & registry entries need Users to have enhanced access to.

One slight complicating factor is this: the computer was joined to the domain in the office, then moved to the business owner's house. The last thing I need is to have to support any functionally unsecured computers, especially ones like this that are 90 minutes from my home/office. That would do nothing but make my 16-hour days even longer. So I insist that any computers I provide for the company be on the domain; the user just has to log onto it once while it is in the office to create their profile and cache domain logon credentials. Because the owner never took my advice to let me put a SonicWall (for hardware VPN to the office) at their house so they could act as a fully-functional branch office, all I can do is log on remotely via SSL VPN from my home/office through their DSL modem/router. But in this configuration, his computer cannot see the domain, so there is no way to elevate his domain user or Domain Users group, even temporarily, by adding them to local Administrators, since the domain is not visible in compmgmt.msc. I just never anticipated software written so poorly as to require admin rights for a non-admin user.

Note: LocalServiceControl, upon installation, is loaded via Run entry in the registry, and its failure is evident immediately upon logon of non-admin user; it does not require going as far as opening the browser to know that it has failed to load. So I removed that Run entry and have been doing all testing strictly opening LocalServiceControl, so there is no need to go as far as Chrome and failed video to know whether my load has succeeded; if I cannot get LocalServiceControl to load properly, the video stream will not work in the browser. The exception was when I tested it all as a scheduled task under an admin account separate from the logged-on user (see #3 below); since it would never indicate success or failure for the current user, I had to go to the browser to see the failure in action.

Answer 5

BTW, off topic a bit: I see your handle MotoxX80, and if you have ever raced, this may ring a bell: we live just about five miles from the Washougal national Motocross track and can hear the activity from our home every time the Nats or January 1 Hangover Scramble is running.