As someone who is currently having to take away people's local admin rights along with a ton of other privileges: it's not like we do this for fun, we have compliance goals to reach that were agreed to by higher ups outside of the IT department in exchange for public funding (we're a public institution).
You only need to experience what some people manage to do to their machines with and without admin access to favour a return to the abacus for the general workforce.
And software developers are simultaneously the best and absolute worst users.
everyone thinks they can pull it off just fine, but believe me, it's not a bad bet that your IT dept knows better than to bend to someone just dangerous enough to be a problem. it's probably happened before and that's probably why the policy is in place.
Cool, here is a VM without domain join and no access to internal resources. Feel free to use your admin permissions on there.
Seriously though: developers need admin access during prototyping unless you are a giant enterprise that already has CI\CD, dependency management, staging environment etc all set up and properly configured. For everything else, devs should have their contained sandboxes with admin permissions
*and all those environments come with admin teams (devops, sysops, call them whatever) actually good at what they do. Because I have a long list of things to vent about exactly because:
you're a dev, so fight us for access and permissions (edit: that I already have ssh access to prod servers and thus could wreak havok any moment if I wished to is completely ignored)
here's a botched something you asked. It is not configured/improperly configured - well, who da fuq cares. Let's have another kanban card for fixing this
Recently one of our devs was caught running Chrome portable (because he wasn't given admin access), where he logged in to his personal google account and saved his company credentials, where they were promptly synced to his personal malware-infested home system and ended up in a paid dataset on the darknet. IT Security, InfoSec and Governance policies have to be written with this kind of employee behaviour in mind.
Incidentally him and his team had just complained loudly about MFA being required for our critical apps.
The holy war between good (IT) and evil (npm) but my feature needs to be out end of month and I can't have everything installed immediately blocked or I won't meet the deadline
Y'all joke, but when that 'task' is run through process monitor, we see it's trying to overwrite a DLL in system32, create a directory at root of %systemdrive% or cache some data in the Program Files application itself, instead of utilizing ProgramData or Appdata properly.
When applications fail these simple practices and demand local admin, they shouldn't touch your network.
The hardcoded AppData path is the main reason I had to spring for a larger system drive a few years ago despite not installing any programs to it. Gradle/NuGet/every other package manager were the main culprits, with Microsoft themselves coming second. Every few months I'd clear out their caches and "temporary" file folders and it'd free up tens of gigabytes.
I'd mess around with symbolic links to move it to another drive if I didn't half-expect Windows to break them at some point.
I've had my PortableApps there. And the not so portable (but still standalone ones) too. Some of them could even permanently fuck up UAC, allowing acess to everything, as a side-effect.
LUA Buglight is also good for documenting why a program needs admin when it shouldn't.
After that, you just write an admin shim with the app compatibility toolkit and just add write perms to the necessary folders. ...Unless it's system32. Then your software request can die in a fire, and I'm forwarding the info to your boss (and mine) before you can complain to them.
It is the beating heart of Windows itself, the nuclear reactor at the heart of the facility. And much like with a nuclear reactor, you don't screw around in the core unless you have a damn good reason.
Doing so at random is a good way to make both go kaboom.
I've worked for two organisations that distributed licences for users. Being able to prove, under scrutinisation, that your general requests do not need to be questioned for that level. Anything above your level of liberty in the data governance would be checked—though 99% of the time you already know this and explain in full detail on the request to help.
It worked perfectly and I don't know why it's still not the norm.
In a 'wet cement' org structure, often the specialists in an area know far more about what's going on than the juniors gatekeeping. If you aren't buddies with the person on top, you join the queue and a 5 min job becomes 6 months and several meetings; if you don't already botch a dodgy workaround before then.
Edit: I'm in year 3 of getting the Oracle SQL add-on allowed to direct query, read only, in Excel. My current workaround is to use the IDE to export to CSV, store on SP, then PQ that... And, yeah, I have write access in the IDE even though I keep telling them that's bad... Apparently, that solution is more secure. I've spoken to the CIO about the concerns and how it breaks the fundamentals of our data governance framework. The new infrastructure architecture gets it, but has to spin the better way of doing things as a "trial" which has taken 6 months to approve and counting...
We audited every exe and whitelisted like majority with over 50 users. Some occasional victims here and there (I lost access to my self compiled ones, too) but overall no THAT signigicant rise in ticketing
I do industrial controls. The software we are forced to use is usually proprietary, sometimes old, and always very poorly written. Plus there's the networking issues. A huge amount of stuff is just statically addressed, so I might be switching the ethernet port on my laptop from an 89.89.x.y subnet, to a 10.10.i.j subnet, to a 192.168.a.b subnet, and back again multiple times a day. When IT first took admin rights off our laptops, it took away our ability to change IP addresses. There may have been some small amount of malicious compliance.
27 replies
As someone who is currently having to take away people's local admin rights along with a ton of other privileges: it's not like we do this for fun, we have compliance goals to reach that were agreed to by higher ups outside of the IT department in exchange for public funding (we're a public institution).
You only need to experience what some people manage to do to their machines with and without admin access to favour a return to the abacus for the general workforce.
And software developers are simultaneously the best and absolute worst users.
everyone thinks they can pull it off just fine, but believe me, it's not a bad bet that your IT dept knows better than to bend to someone just dangerous enough to be a problem. it's probably happened before and that's probably why the policy is in place.
Cool, here is a VM without domain join and no access to internal resources. Feel free to use your admin permissions on there.
Seriously though: developers need admin access during prototyping unless you are a giant enterprise that already has CI\CD, dependency management, staging environment etc all set up and properly configured. For everything else, devs should have their contained sandboxes with admin permissions
*and all those environments come with admin teams (devops, sysops, call them whatever) actually good at what they do. Because I have a long list of things to vent about exactly because:
Most of the damage is done with good intentions.
Recently one of our devs was caught running Chrome portable (because he wasn't given admin access), where he logged in to his personal google account and saved his company credentials, where they were promptly synced to his personal malware-infested home system and ended up in a paid dataset on the darknet. IT Security, InfoSec and Governance policies have to be written with this kind of employee behaviour in mind.
Incidentally him and his team had just complained loudly about MFA being required for our critical apps.
I'm forced to use windows to work. but having wsl2 with root makes it almost bearable.
The holy war between good (IT) and evil (npm) but my feature needs to be out end of month and I can't have everything installed immediately blocked or I won't meet the deadline
Y'all joke, but when that 'task' is run through process monitor, we see it's trying to overwrite a DLL in system32, create a directory at root of %systemdrive% or cache some data in the Program Files application itself, instead of utilizing ProgramData or Appdata properly.
When applications fail these simple practices and demand local admin, they shouldn't touch your network.
<3
As an insane person who moved all my folders to the D drive, it’s absurd how many big companies hard code C:\Users\you\AppData\Roaming
Easy fix, just mount your desired hard drive to a new root directory, call it /mnt/whatever and symlink... Oh.
The hardcoded AppData path is the main reason I had to spring for a larger system drive a few years ago despite not installing any programs to it. Gradle/NuGet/every other package manager were the main culprits, with Microsoft themselves coming second. Every few months I'd clear out their caches and "temporary" file folders and it'd free up tens of gigabytes.
I'd mess around with symbolic links to move it to another drive if I didn't half-expect Windows to break them at some point.
I've had my PortableApps there. And the not so portable (but still standalone ones) too. Some of them could even permanently fuck up UAC, allowing acess to everything, as a side-effect.
I... I'm sorry, I don't comprehend... Are you speaking some sort of archaic language or something?
LUA Buglight is also good for documenting why a program needs admin when it shouldn't.
After that, you just write an admin shim with the app compatibility toolkit and just add write perms to the necessary folders.
...Unless it's system32. Then your software request can die in a fire, and I'm forwarding the info to your boss (and mine) before you can complain to them.
Can you please explain to the laity what the problem with System32 is? So we know why to avoid it
It is the beating heart of Windows itself, the nuclear reactor at the heart of the facility. And much like with a nuclear reactor, you don't screw around in the core unless you have a damn good reason.
Doing so at random is a good way to make both go kaboom.
So is it like the kernel but for windows?
More of a combo of kernel and coreutils, but yeah. Pretty much.
I've worked for two organisations that distributed licences for users. Being able to prove, under scrutinisation, that your general requests do not need to be questioned for that level. Anything above your level of liberty in the data governance would be checked—though 99% of the time you already know this and explain in full detail on the request to help.
It worked perfectly and I don't know why it's still not the norm.
In a 'wet cement' org structure, often the specialists in an area know far more about what's going on than the juniors gatekeeping. If you aren't buddies with the person on top, you join the queue and a 5 min job becomes 6 months and several meetings; if you don't already botch a dodgy workaround before then.
Edit: I'm in year 3 of getting the Oracle SQL add-on allowed to direct query, read only, in Excel. My current workaround is to use the IDE to export to CSV, store on SP, then PQ that... And, yeah, I have write access in the IDE even though I keep telling them that's bad... Apparently, that solution is more secure. I've spoken to the CIO about the concerns and how it breaks the fundamentals of our data governance framework. The new infrastructure architecture gets it, but has to spin the better way of doing things as a "trial" which has taken 6 months to approve and counting...
Reading your comment at night does feel like a horror story
Too much jargon. Employee is just using an AI agent.
Sorry, gonna need a ticket to escalate that
IT tried to get super strict with that at my company, but they relented when ticket volumes went up by a couple thousand percent.
My company would respond by not processing tickets any faster and just let deadlines slip.
We have done this, and it took years.
We audited every exe and whitelisted like majority with over 50 users. Some occasional victims here and there (I lost access to my self compiled ones, too) but overall no THAT signigicant rise in ticketing
I do industrial controls. The software we are forced to use is usually proprietary, sometimes old, and always very poorly written. Plus there's the networking issues. A huge amount of stuff is just statically addressed, so I might be switching the ethernet port on my laptop from an 89.89.x.y subnet, to a 10.10.i.j subnet, to a 192.168.a.b subnet, and back again multiple times a day. When IT first took admin rights off our laptops, it took away our ability to change IP addresses. There may have been some small amount of malicious compliance.