Re-evaluating Local Administrative User Rights
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Dashrender said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@IRJ said in Re-evaluating Local Administrative User Rights:
@Dashrender said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Dashrender said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Dashrender said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Dashrender said in Re-evaluating Local Administrative User Rights:
As for software/viruii that don't require local admin rights, uhuhm - CHROME, rights levels don't matter.
Huh? Chrome isn't a thread because of this.... no admin access whatsoever.
This was an example of software that could be run in user space with zero local admin rights - nothing more. The remainder of that post (or a followup one) pointed out that I don't want to see users able able to execute an executable that wasn't installed by an admin - but I'm not sure that's possible, or really reasonable.
Yes, but it's "run in the user space". Everything works that way. Office suites, you name it. Chrome is just a "portable app".
Yeah, I just don't like the idea of portable apps - as an admin, I'd like to prevent them. Because there is no reason in most businesses that a user would need to run a portable app. If you prevent execution from any user rightable space, you can kill so much of this malware.
That's not a good way to think of it. You should never dislike portable apps, all that means is that they don't require admin privs or need to be installed to run. Installing just means putting it into the system database.
Portable apps have loads and loads of reasons to exist. They are more stable, easier to maintain, avoid DLL hell, etc. They don't link to system resources and so are more resilient to all kinds of problems and tend to work across more OS versions.
Portable apps tend to be bloated, that's pretty much their only negative.
Execution allowances is totally different. Not allowing end users to make or acquire their own tools and run with their own privs is very different than disliking the avoidance of system dependencies in an executable.
You CAN get rid of all of those things mentioned in locally install apps as well.
There is only negatives to locally install apps IMO. Some would argue that it is required for speed, but in reality a properly built SaaS app does not have issues.
He's not intending to argue the "locally" part, but the "installed" part. The context was installed vs portable apps, both local in this case.
I guess what I want is a white list of allowed executable - I don't care if they are portable or not, I care that users shouldn't be able to execute them unless allowed by IT.
Right, that makes sense. DLL linking or database inclusion doesn't really. Portable doesn't imply any additional access from the users.
Just be aware that while listing means no OS level scripting from end users, even of their own making. But that's not necessarily bad.
Scripts shouldn't run unless they are signed and the cert is allowed. That's how we control that.
The problem is... you can't write your own.
Maybe I'm missing your point. So they can't run Vscode and write a script? Or notepad?
They can't write a script, at all. In any way. If only whitelisted things can run, you can't make any of your own automation.
Write or run?
Well they can write it, but that's it.
-
What are potential underlying issues and fixes that you all may have ran into, causing the perceived requirement of local admin privileges?
Quick easy example to make the question clear:
Issue:
- A certain app some people use requires local admin privileges to install.
Fix:
- Make the app available to install via the "Company Portal" or other self-service software install portals.
-
Another point:
Timed or temporary local admin privileges? Do you feel that is at all any more or less "secure"?
-
What's the advantage of giving users admin rights?
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
Another point:
Timed or temporary local admin privileges? Do you feel that is at all any more or less "secure"?
How is it controlled?
For me of course it's still more secure than simply giving the users local admin all the time. But really, why do they need it at all? Is IT so backed up that they can't get to a user request to install an approved something for the user? How often are users needing to install things that they need this access?
I mean, if they are a tester for the company - perhaps they should have a VM that has no access to network resources, say, just internet, and the user had full control over that.. just one idea.
-
@IRJ said in Re-evaluating Local Administrative User Rights:
What's the advantage of giving users admin rights?
This is still under evaluation, as well as evaluating all of the causes or perceived needs for local admin privileges in the first place. As of now, we do not allow any local admins at all (exceptions exists, as well as timed local admin privileges (similar to sudo I suppose in the "timed" way)), so currently, not an issue, but could be better.
This post is about being proactive on the topic, as I have direct influence over some decisions. So I'm gathering as much as possible from as many angles as possible.
I said from the very beginning (not here) that I'm not on board with it and gave quite a few of the reasons we all mentioned here, some of which that were met with a few anecdotal counters.
So, this is my change to gather as much as possible, showing all the points. This is why I'm trying to counter everyone's input, so that I can better prepare for the anecdotal counters thrown my way later.
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@IRJ said in Re-evaluating Local Administrative User Rights:
What's the advantage of giving users admin rights?
This is still under evaluation, as well as evaluating all of the causes or perceived needs for local admin privileges in the first place. As of now, we do not allow any local admins at all (exceptions exists, as well as timed local admin privileges (similar to sudo I suppose in the "timed" way)), so currently, not an issue, but could be better.
This post is about being proactive on the topic, as I have direct influence over some decisions. So I'm gathering as much as possible from as many angles as possible.
I said from the very beginning (not here) that I'm not on board with it and gave quite a few of the reasons we all mentioned here, some of which that were met with a few anecdotal counters.
So, this is my change to gather as much as possible, showing all the points. This is why I'm trying to counter everyone's input, so that I can better prepare for the anecdotal counters thrown my way later.
There has to be advantages to make it an actual consideration, correct?
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
Another point:
Timed or temporary local admin privileges? Do you feel that is at all any more or less "secure"?
Better, but seems like too much effort.
-
@IRJ said in Re-evaluating Local Administrative User Rights:
What's the advantage of giving users admin rights?
Bypassing formal IT for basic requests and customizations, and not needing or wanting to put in an automated system to handle those requests.
-
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@IRJ said in Re-evaluating Local Administrative User Rights:
What's the advantage of giving users admin rights?
Bypassing formal IT for basic requests and customizations, and not needing or wanting to put in an automated system to handle those requests.
Apparently that's not been an issue in another location for another company. However, I'd have to argue, how would you know?
-
@IRJ said in Re-evaluating Local Administrative User Rights:
What's the advantage of giving users admin rights?
Some applications are really tough to get working without it, and many lose support if you take it away. No legit app, of course, but the bulk of businesses run totally ridiculous applications.
-
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@IRJ said in Re-evaluating Local Administrative User Rights:
What's the advantage of giving users admin rights?
Some applications are really tough to get working without it, and many lose support if you take it away. No legit app, of course, but the bulk of businesses run totally ridiculous applications.
I believe I have heard this may be one of the issues, for some people... however, I'm still not on board for a blanket enablement because of a fringe app or two for less than 0.05% users.
Edit: But again, still evaluating that.
-
@Dashrender said in Re-evaluating Local Administrative User Rights:
How is it controlled?
In a way that works 100% well.
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@IRJ said in Re-evaluating Local Administrative User Rights:
What's the advantage of giving users admin rights?
Some applications are really tough to get working without it, and many lose support if you take it away. No legit app, of course, but the bulk of businesses run totally ridiculous applications.
I believe I have heard this may be one of the issues, for some people... however, I'm still not on board for a blanket enablement because of a fringe app or two for less than 0.05% users.
Edit: But again, still evaluating that.
Agreed, just one of the reasons that people state.
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
It seems like restricting users to non-admin privileges causes more inconvenience and service desk overhead than it's actually worth.
It absolutely causes more issues when users have local admin rights. I dealt with this crap daily until I finally got buy in from clients across the board to remove admin rights.
If you have a user that needs a local admin right to perform any daily task, the problem is the software being used. Not the user or IT policy.
-
@JaredBusch said in Re-evaluating Local Administrative User Rights:
If you have a user that needs a local admin right to perform any daily task, the problem is the software being used. Not the user or IT policy.
This is the hardest part to tackle. But it's worth tackling. It's amazing how easily this can often be fixed.
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
And, from a security perspective, doens't really seem like any more of a factor one way over the other.
Of course it is more of a security factor. While, sure most shit can run in local user space, and mess up the user profile, it is restricted to the user profile. Sure the odd 0-day that executes easily will ignore that, but most 0-day have tricks to make them most effective.
-
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@JaredBusch said in Re-evaluating Local Administrative User Rights:
If you have a user that needs a local admin right to perform any daily task, the problem is the software being used. Not the user or IT policy.
This is the hardest part to tackle. But it's worth tackling. It's amazing how easily this can often be fixed.
It is simple enough to fix with a unique account that has local admin rights and then a
batfile calling a/runas /savecreds. I have a number of old service applications that require this at one client. The first time you use the/runas /savecreds, IT staff can enter the password and then the Windows Credential manager will keep it and the user can just click the icon afterwards.Sure a malicious user will be able to figure out what is happening and exploit that, but that is not an IT problem. That is a HR problem.
-
What about cases where a computer is used for dev work on which the users are using mob programming practices and running docker containers?
What are some ideas in that space?
-
If you think about it, letting the users run as admins shouldn't be a problem. Not if you have designed your network with zero trust in mind - assume every computer sits directly on the internet, assume everything is compromised.
So the only thing they should be able to screw up is their own computer - in which case you should be able to bring it back quickly with automation.
That said, I think developers need their own server(s). A test environment where they can create and destroy VMs and run containers and whatever else they need. Do development and run performance tests. Let them run wild in there. It could be cloud or on-prem or whetever it is they are developing.
