Re-evaluating Local Administrative User Rights
-
@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.
-
@Pete-S said in Re-evaluating Local Administrative User Rights:
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.
LANless design
-
@Pete-S said in Re-evaluating Local Administrative User Rights:
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.
In theory, but even in a zero trust, simple rebuild you need a process for them determining that they need to be rebuilt, a rebuild, an update.
you can make the system ephemeral, but it almost always causes a productivity loss.
-
@Pete-S said in Re-evaluating Local Administrative User Rights:
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.
Devs don't need to be admins to do that. I have devs, they can do this... without admin rights. Could they be admins in dev? Sure, not a big deal. But no reason for them to waste time doing that, either.
-
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Pete-S said in Re-evaluating Local Administrative User Rights:
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.
In theory, but even in a zero trust, simple rebuild you need a process for them determining that they need to be rebuilt, a rebuild, an update.
you can make the system ephemeral, but it almost always causes a productivity loss.
agreed - sure, it's only their computer screwed up, but isn't that bad enough? Removing admin removes a lot, granted not ALL, but a lot of the risks, enough that not giving them admin, or at minimum, not running as local admin is worth it in my mind.
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
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?
Use AWS / Azure dev environment for them.
-
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Pete-S said in Re-evaluating Local Administrative User Rights:
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.
Devs don't need to be admins to do that. I have devs, they can do this... without admin rights. Could they be admins in dev? Sure, not a big deal. But no reason for them to waste time doing that, either.
Well, they need to be admin on their VMs they create for sure. If they need to be admins on their own workstation depends on what tools they need to run there. If they are working like they are on thin clients and use their dev environment for everything, then they need nothing local.
-
@Dashrender said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Pete-S said in Re-evaluating Local Administrative User Rights:
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.
In theory, but even in a zero trust, simple rebuild you need a process for them determining that they need to be rebuilt, a rebuild, an update.
you can make the system ephemeral, but it almost always causes a productivity loss.
agreed - sure, it's only their computer screwed up, but isn't that bad enough? Removing admin removes a lot, granted not ALL, but a lot of the risks, enough that not giving them admin, or at minimum, not running as local admin is worth it in my mind.
Depends on how they work and what they are developing.
Unfortunately it is far too common that IT serves itself and not the need of the users. Question is if you are trying to make your own job easier at the expense of making their jobs harder, or if you are trying to come up with something that is better for everyone?
-
@Pete-S 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:
@Pete-S said in Re-evaluating Local Administrative User Rights:
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.
In theory, but even in a zero trust, simple rebuild you need a process for them determining that they need to be rebuilt, a rebuild, an update.
you can make the system ephemeral, but it almost always causes a productivity loss.
agreed - sure, it's only their computer screwed up, but isn't that bad enough? Removing admin removes a lot, granted not ALL, but a lot of the risks, enough that not giving them admin, or at minimum, not running as local admin is worth it in my mind.
Depends on how they work and what they are developing.
Unfortunately it is far too common that IT serves itself and not the need of the users. Question is if you are trying to make your own job easier at the expense of making their jobs harder, or if you are trying to come up with something that is better for everyone?
Many will say that tools that require local admin on their own machine are likely horribly tools to begin with. Why would a dev need local admin to write code? - the written code should be running in a test environment that I could be convinced that for expediency the devs have local admin rights over...
-
@Pete-S said in Re-evaluating Local Administrative User Rights:
Well, they need to be admin on their VMs they create for sure.
They don't, actually. If they were spinning them up completely from scratch... actually even then they wouldn't. It's really not something that devs need unless there isn't IT. If you don't have IT, then you might need it for anyone, even a janitor.
-
@Pete-S said in Re-evaluating Local Administrative User Rights:
If they need to be admins on their own workstation depends on what tools they need to run there. If they are working like they are on thin clients and use their dev environment for everything, then they need nothing local.
As someone who owns a dev company, I can assure you devs don't need this stuff. And rarely is it helpful. Devs often demand this, but I can't think of why they'd need it. Devs designing code environments is actually a pretty major, and common, mistake. If the devs are local admins to their dev boxes... how do you know that they are setting up the dev environment in a way that will be reflected in a proper production environment?
Letting devs do this would actually explain some of the common massive blunders we see in software design where software is built with the expectation of not being deployed in a production manner (for example... by requiring ridiculous dependencies, not considering licensing, or requiring that the software be run as admin.)
-
I would agree in most situations no user needs to be admin on their own box. I think this is the way to go about things. Of course there are a lot of other factors as others have mentioned. However, if someone at your company tells you to compromise, what about having a seperate admin account that they only use when necessary? Then the rest of the time they use their regular account.
-
@jmoore said in Re-evaluating Local Administrative User Rights:
I would agree in most situations no user needs to be admin on their own box. I think this is the way to go about things. Of course there are a lot of other factors as others have mentioned. However, if someone at your company tells you to compromise, what about having a seperate admin account that they only use when necessary? Then the rest of the time they use their regular account.
This is exactly what IT and those users should be doing...
It's what I do - I have a user account just like everyone else at my company and a domain admin account for my admin stuff.
I know that since I can easily do much of my work without local admin - no user in my company needs admin (our uses are pretty low - we are a medical company, not a technical one).
-
@jmoore said in Re-evaluating Local Administrative User Rights:
I would agree in most situations no user needs to be admin on their own box. I think this is the way to go about things. Of course there are a lot of other factors as others have mentioned. However, if someone at your company tells you to compromise, what about having a seperate admin account that they only use when necessary? Then the rest of the time they use their regular account.
Perhaps. But actually logging into an admin account means they they would be logged in and have admin rights full time while logged on, and that works around the whole thing.
As a compromise, I think sticking to exceptions being able to temporarily obtain local admin rights, with warning, acceptance message, etc. That will force consciousness of the fact.
-
@Dashrender said in Re-evaluating Local Administrative User Rights:
@jmoore said in Re-evaluating Local Administrative User Rights:
I would agree in most situations no user needs to be admin on their own box. I think this is the way to go about things. Of course there are a lot of other factors as others have mentioned. However, if someone at your company tells you to compromise, what about having a seperate admin account that they only use when necessary? Then the rest of the time they use their regular account.
This is exactly what IT and those users should be doing...
It's what I do - I have a user account just like everyone else at my company and a domain admin account for my admin stuff.
I know that since I can easily do much of my work without local admin - no user in my company needs admin (our uses are pretty low - we are a medical company, not a technical one).
Domain admin is a totally separate discussion and nothing to do with this.
