7d ago

How do I make a domain account on Windows have administrative privelleges to use a particular app?

I want the account to be able to use one app that requires administrative privileges. I have contacted the support team of the app to find out why it needs these privileges, but I didn't receive any helpful information.

The app is for viewing surveillance footage, but it requires admin privileges to open. I don’t want to make every employee an administrator just for this one use case. It might be better to switch to a FOSS app that doesn’t require administrative privileges by default.

The cameras we currently use are made by the vendor of the app, so maybe we're locked in somehow? The NVR is also made by them, so it might be possible, but I don't know for sure. I need to look into it more.

13 comments

You need to put the domain user in the local administrators group. Easiest way to do this is through the Computer Management MMC snap-in.
It'll give full admin rights over the local computer though - You can't just give admin rights to one program AFAIK.
- I'm concerned because there are a lot of employees that are using this one program and I'm worried about them accidentally installing something down the line. Thanks for your response btw.
  
  The above is correct for what the vendor says their application needs.
  But I guarantee that the account that runs the application does not require local admin permission. That's just sloppy fucking code; someone realized that the accounts that run the app would need extra permissions, and just went "local admin it is."
  This is unconscionable from a vendor that provides software for viewing security cameras.
  Someone else said, "Escalate beyond tier 1 support," and this is true. You're going to have to be really persistent, maybe even a bit of an "asshole," but it will be justified, and nothing is more satisfying than that.
- Yep.
  Windows security model is predicated upon the user. So apps get the security context of the user that launched it.

Honestly, I've seen this too many times working in IT. The best option was always to set up a computer with a local administrator account, no access to the secure network, and let the entire department have access to it.
Install the camera software(s) on there and only there. Videos are then exported into a common file type and transferred through USB or DVD.
I've worked with Police departments that had dozens of different, unique software each with their own proprietary codec. Every time they requested a recording from a business there would be another unsigned .exe to run. Straight garbage.
- We have an app like that that has a lot of our clients pii in it and in order to keep it safe we host the app itself on a remote machine and when people need to use it they RDC into the machine with a shortcut.
  They have local admin permissions on that machine but the only thing that that device can do is run that application and the firewall outside of it prevents it from going out to the internet or other places.
  Maybe it's overkill, but doing things like that help prevent and protect our clients which is the most important thing for the company I work for other than making money.
- The physical security/life/safety/property world has some of the worst security management.

I have contacted the support team of the app to find out why it needs these privileges, but I didn't receive any helpful information.
Tier 1 probably doesn't have a clue, you'll have to escalate, or alternatively use procmon to see what files and folders it's accessing that might need admin privileges. Like if it's trying to write files to its own subfolder right off C: basically it's probably poorly coded.
Once you know what files/folders it's trying to access, you can give everyone permissions to just those specific ones and then it should run without prompt
Alternatively alternatively, you can screw around with the task scheduler, off the top of my head you could probably have TS run the program as an admin user on login of any user
- I did use procmon and saw that it was creating/closing a file in the C: directory. I gave access to the other folders it was trying to access (e.g. C:\Users\Public\CameraSoftware) but it's still asking for admin privelleges. I tried doing the Task Scheduler method as well, did not work for me unfortunaely. Thanks for your response btw!
  
  Did you check for registry keys too?
  Procmon is the shit.

... and this is why we use unifi... the ability to control viewer permissions and not require a chinese program designed for windows xp that requires admin privs just to view cams.
I assume you've already explored the option of using the browser page for the nvr and that doesn't work for some reason? Browser pages don't require admin.

There's some good advice in the comments already and I think you're on the right track. I'd like to add a few suggestions and outline how I think about the problem.
Ask if the vendor has installation administrator guides, whitepaper, training material, etc. If yes: ask that they send it to you. You may also be able to find these on the vendor's website, customer portal, or a public knowledgebase / PDF repo.
I would want to know three things.
How do users authenticate through the application?
What are all of the ways users may access the application (local only, remote desktop, LAN only, full server/client model)?
Does the vendor have any prescribed solutions for defining who has access to the application, at what privilege level, with access to what features?
i.e. What parts of the user access, authenticate, authorize pipeline do application admins or system admins have control over and how can we exercise that control?
Based on some context I assume that the app is reading from Active Directory using RADIUS or LDAP for user auth and that people are physically logging into the machine.
If this is the only method of authentication then I would gate the application with a second account for each employee who requires access for business reasons defined in their job description (or as close as you can get to that level of justification - some orgs never get there). You can then control who has access to the machine via group policy. Once logged in the user can launch the application with their second account (which would have the required admin access) via "Run as..." or whatever other methods you'd prefer. No local admins logging in directly and yet an application which users can launch as admin. Goal achieved.
This paradigm lets us attempt balancing security concerns with user pain. The technically literate and daringly curious will either already know or soon discover they can leverage this privilege to install software and make some changes to the system. The additional friction, logging, and 1:1 nature of the account structure makes abusing this privilege less attractive and more easily auditable if someone does choose the fool's path.
I can imagine more complex set ups within these constraints but they require more work for the same or worse result.
Ideally you run the app with a service account and user permissions are defined via Security Groups whose level of access is tied to application features instead of system privs. There are other reasonable schemes. This one is box standard and a decent default sans other pressures.
If other methods of auth are available (like local, social, cloud, etc) then you'll have more decent options. I would define the security objectives for application access, define the user access objectives from the Organization's perspective, and then plot each solution against those two axes (napkin graphs - nothing serious). Whichever of the top three is the least administratively burdensome is then selected as my first choice for implementation with the other two as alternatives.
An aside: unless there is only one reasonable choice most folks find one option insufficient, two options difficult to decide between, and four options as having one option too many - whenever possible, if another party's buy-in is desired, present either three options or three variations on one option. This succeeds even when the differences are superficial, especially when the subject is technical, and 2x if the project lead is ignorant of the particulars. People like participating.
I'd then propose these options to my team/direct report/client, decide on a path forward together, and plan the rest from there. There's more to consider (again dependent on org maturity) but this is enough to get the project oriented and off the ground.
Regarding FOSS alternatives: you're likely locked in with the vendor's proprietary software for monitoring the cameras. There are exceptions but most commercial security system companies don't consider interoperability when designing their service offerings. It might be worth investigating but I'd be surprised if you find any third party solutions for monitoring the vendor's cameras which doesn't require either a forklift replacement of hardware, flashing all of the existing hardware, or getting hacky with the gear/software.
I hope this helps! <3

I think my company uses software from Cyberark to do this sort of thing.

13 comments