PSA: If you're still giving users admin rights, maybe try not doing that. Would've helped dampen 100+ Microsoft vulns last year – report Access management outfit BeyondTrust has urged organizations to remove admin rights from users, arguing that doing so would have at least mitigated more than 100 vulnerabilities in Microsoft products last year. Restricting privileges is infosec 101: as Microsoft explains here, it limits the amount of damage or change an …
Thank god I've got Admin rights on my machine! We've tried doing it without Admin rights but it just becomes a nightmare of perpetual waiting for responses from IT. e.g. Getting all your software installed on a new machine can take 2-3 weeks with 20 emails and 6 hours of calls if we rely on IT, instead of 1 hour if we just do it ourselves.
I do actually wish I didn't need Admin rights, but life would be so much harder without them. 24-48hr waits for a 2min change is not something I'd look forward to. And as for killing processes that have gone haywire/stuck I'd rather not my only option be to restart the machine.
we have normal accounts and admin accounts. every time i need my admin account it's locked as the password expired months ago.
some savvy colleagues oink their normal and admin accounts so they have admin access to their local machines etc.
its effectively security by obscurity if everyone on the tech team has 2 accounts.
As an administrator, I'd be out on my ear, if my boss caught me working in a local admin account on my PC - other than carrying out pure administration tasks, but even most of those can be done with account elevation and entering my admin account name and password.
Oooh this one too! Local IT is proactive, MSP's are reactive. I'm arguing to bring this back in house but I'll never win, it's too expensive. I'd be satisfied with some better administration of our systems but again, struggling to get traction.
I too wish for a better way. At my company we have started a new round of updating with new computers and I have been trying to deploy without the users having admin rights. Really quite troublesome, users can't install printers whose drivers are hosted on our own servers, and as noted previously can't even kill off wayward programs as they can't even bring up task manager. I do like that they can't install random software but ease of use is definitely not getting any high scores.
We have departmental printers. When a PC goes out to a user in a department, we install all the departmental printer, before the PC leaves the IT department.
During the first logon, we go through the printers with them, make sure the printers they need are there and set the default for them, if they can't do it themselves.
For printing, Have you tried setting these policies?
Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options\Prevent users from installing printer drivers: Disable
Computer Configuration\Policies\Administrative Templates\Printers\Point and Print Restrictions: Enabled
* When installing drivers for a new connection: Do not show warning or elevation prompt
* When updating drivers for an existing connection: Do not show warning or elevation prompt
None of our users get admin rights, not even us admins. We work in unprivileged accounts and switched to privileged accounts to carry out admin specific tasks, then switch back to our normal accounts afterwards.
We have a couple of banking applications that need updating every month or so. The accountant calls and we do the update with him remotely.
Same for our PLC engineers, when they set up a new machine, they call us and we install the software together.
All other departments get a fully installed PC, we just do the final in-account stuff with them, when they get it - setting up Outlook, check for missing shares and ensure the correct printers are configured. All software they need installed and configured has to be on the requisition form.
Using accounts with admin rights is almost always incompetence or laziness. All our staff run non admin accounts. Admins have accounts we can elevate with for admin purposes. There are some very limited instances where we need to log in with these accounts (certain updates spanning reboots for example). At no other time is anyone allowed to even log into a PC with an admin account. Elevation requires credentials and a second MFA prompt.
Where we get shitty apps where the incompetent/lazy developer insists it needs admin rights to run, we use tools like procmon to find out what needs relaxed security (usually writes to HKLM or Program Files or other places users should not be writing to in the first place but the developer has never heard of HKCU or profiles) and set appropriate permissions.
We are currently having a fight with one developer who insists their application (used by law firms) must have SMB1 enabled (along with admin rights).
Get rid of Redmond products entirely.
Me DearOldMum, Wife and Great Aunt run a cut-down version of Slackware. None of them have ever used root, not even with su or sudo. Between the three of them, they needed precisely zero technical support in all of 2020. Right tool for the job and all that. (I handle their software updates and backups from my desk here in the office ... or rather a computer does it for me. A simple cron job or two and some scripting takes care of those details, with only very occasional input from me.)
My sister, on the other hand, who insists that if she doesn't run Windows the entire planet will implode, is constantly trying to get me to fix her computers ... Sorry, Sis, I don't do Windows.
I'm missing the point you're trying to make here, provided there is one apart from your constant moans about Windows.
The article is saying that user accounts should not have admin rights. I think we agree on that. You apply that rule within your family. I do within mine, and I'm sure many El Reg readers do the same.
My pre-retirement second career was as a (mostly Windows, but some Mac and Linux) network manager. Of course the users did not get admin rights. The only real inconvenience to them was that they couldn't have Spotify. If they really did need something I'd set up the deployment and they'd get the thing they asked for pushed to their machine the next time they connected. Same with patches.
This is all common sense and standard practice in any sensible organisation. This article is not talking about sensible organisations.
What point does the Pavlovian anti-Windows comments serve? Especially as your last sentence suggests you're not exactly a Windows expert.
When I first went contracting I bought a shiny new Mac, happy to be free of Redmond's heavy chains. Then I had to buy Office 2011 for the Mac cos all my clients used MS Office and the freeware incompatibilities were unprofessional at best and unmanageable at worst. Then I had to get an add-on for Mail cos Mac mail couldn't process calendar invites from some clients with Outlook. Then I transitioned all my mail, calendar and contacts to Outlook 2011 because one client couldn't receive my emails. Then I had to buy Parallels so I could buy Windows so I could buy MS Project cos that's what clients used and there was no Mac alternative (there is, but it took me years to find it). I've also got a 365 account because a client used Sharepoint.
Getting rid of MS products is easy if you haven't got any customers, suppliers or employees.
Macs and mail! I occasionally receive emails which appear to be blank or allegedly include images which I can't see. Then I realise they're from Mac or iGadget users and have defaulted to sending HTML mail that's partly or entirely invisible to a mail client that's set up to be secure, i.e. expect plain text.
If I wanted. But it's not how email should work by default, is it? It's style over substance marketroids and the like who made HTML email a thing. A better solution would be to bounce it all and let the offenders learn. There is absolutely no reason why email should be sent in HTML. None.
Same here, except we use Windows. My wife doesn't get admin privileges and she doesn't need them. Even if she had them, she'd come to me to get me to do whatever is needed anyway - her decision, she isn't interested in how Windows works and if anything needs to be done she calls me in, she concentrates on what is important.
It's not just users but sloppy development, or lack of development resource by the vendor, means a lot of legacy applications demand excessive rights as well as out of date dependencies before they will work.
It's not as big a problem as it used to be but it's still there. Particularly bad with behemoth suppliers of near monopoly niche systems.
It used to be much worse, say, 10 years ago. Now it is mostly software installs, but that always comes with the baggage of 1) security = "Do we want that software on our machines?" and 2) licenses, "it might be free for personal use, but is it free for commercial use as well?" and "Whose cost centre is paying for it and do we have already unused licenses for that?"
I am actually happy that at work I can hand both issues over to people that are paid to do that and focus on my stuff. Yeah, it took me a few weeks to get everything in the beginning (mostly because of licensing question for software hitherto unused here), but I did have enough other things to work on. Plus there are (virtual) machines that are segregated from the normal networks where you can install things yourself, mostly for testing and evaluation purposes, and you can spin these VMs up with little effort (assuming you choose one of our standard OS). Installing software with a downloader-installer instead of a regular installer is a hassle though (I'm looking at you, Visual Studio).
At home I do have admin accounts on my machines, and have no problem doing regular patches, software updates, backups, ...
You're right about legacy apploications but things need to be seriously old to cause that sort of problem. The real problem I've encountered these days on Windows systems is apps that insist on installing to places they shouldn't such as Appdata. They do this in an attempt to get round access controls on Program Files. But any sensible shop not allow code to run from Appdata.
Yes, it can be fixed using, e.g., Applocker, but it's a pain in the arse.
"You're right about legacy apploications but things need to be seriously old to cause that sort of problem."
Sage Payroll, current versions. So not a small company or a niche product, and not really a legacy app. It STILL doesn't handle UAC properly so to install an update for it you need to be logged in as an admin user. If you attempt to install the update as a normal user and enter the admin credentials via UAC you find part way through the install it breaks out of the elevated security context and back to the user context... which doesn't have permission to do the update so the update crashes and often hoses your Sage Payroll installation.
It's not just users but sloppy development, or lack of development resource by the vendor, means a lot of legacy applications demand excessive rights as well as out of date dependencies before they will work.
In my reasonably extensive experiance (up to enterprise level) almost all legacy applications where people say "it needs admin permissions" usually actually just want write access to their installation folder, and occasionally to the folder where their dependancies from another company are stored. Digging under the surface you'll usually find that these programs started life prior to XP/NTFS when access permissions weren't a thing and were feature complete by around 2000 and haven't seen much development in the last 20 years beyond periodic reskins to make the GUI look less outdated and minor feature tweaks to deal with changes in the law.
This "problem" can be dealt with by right clicking on the installation folder and giving "users" write access to it. Giving somebody admin access to make these sort of programs work is like using a nuke to crack a nut.
The few times I've had that type of issue with programs, I've just selected a different install location than the default, a location that I (as the User) own, such as X:\MyPrograms
Quite a few older PC games have this issue as well, as they try to save config data into the install folder, sometimes even saving save files there! Often just installing somewhere else stops the prompt for admin privileges.
And developers too. I had one particularly 'pleasant' developer who insisted on having root access because not having it 'prevented him from innovating'. No idea why - the projects he was working on were pure application and should never require root access. The rule I always tried to apply was that the system being used to develop on should be as tightly configured as the production system its intended to run on - that way there are no unpleasant surprises when somebody tries to rush the code into production (yes, we all know it should go through testing etc first, but not every company follows even this basic common sense rule).
So I resisted, and he called me incompetent. In an email. Which did not go down well. Lets just say up until the point I left (some years later), he still didn't have root access.....
The title says it all. I work in a company where admin rights were (recently-ish) withdrawn, but there's no software request or release process. So when I urgently needed a piece of software for a customer presentation, I wasted two days trying to work out how to get it installed on my workstation because - while every other process known to man was designed (badly) and published (better), the 'non-previously-approved software' process seems to not have been a prerequisite to withdrawing admin rights. And of course IT support is designed so that the poor sods on the helldesk are your only point of contact. Everyone with the ability to *do* something is heavily shielded from the coalface.
I wouldn't say it is because of IT. Unless they are the poor sods who have to formulate the processes for your change requests. There should be a local change management for that. Yeah, this process management stuff is boring. Really boring. I'm glad I don't have to do it (much). Coming up with a good process flow is also hard! I know, I am involved in other (ITSM) processes. We did have to start close to zero as well. I'd rather focus more on programming and data science, but that's another two months away, I guess.
I am actually really happy that my company does have these processes in place - no, they are not perfect (far from it), and sometimes things get messed up, but in general the "standard" stuff (i.e. software that others have already requested) can be rolled out with relative ease. Assuming the licenses are there already...
So: yeah, it is a problem, I totally agree with you, but management should know about it and do something, maybe hire people to come up with a process, document it and test it. No, it is not as sexy as coming up with crypto-blockchain-empowered-whatever.
In every company I've ever worked for, IT has wanted to position itself as a trusted partner for the business, rather than a service provider. And that's as it should be - otherwise (as a company) you're wasting the tremendous competence that exists in the IT unit. The ownership for the IT processes goes hand in hand with that, so IMNSVHO, my pain is very much IT's accountability.
It sounds as if your IT is either outsourced or lining itself up to be outsourced whether it intends that or not. In-house IT staff, and especially manglement, need to realise that it's what the rest of the company does that pays their wages and that it's in their own interests to make sure that they support that fully.
An IT department that's so disconnected that it might as well be in India is likely to find itself out on the street and replaced by one that is in India. Getting out of the the office/cubes and going to talk to some of the users is a Good Idea.
That's a governance issue not an IT issue.
Senior mangment need to set the rules which IT will operate within. If they don't and leave IT hanging out there to 'deal with' IT stuff because those execs are scared of IT (or scared of looking stupid) then it's their failure not IT's.
But IT will get the blame, because that's what always happens.
From the IT dept perspective, "Lack of planning on your part does not constitute and emergency on mine."
I have lost track of the number of time the super urgent request that has to be done RIGHT NOW is accompanied by and email that goes back weeks & IT were only contacted at the last moment when the end user found out they didn't have the permission to install software whenever they wanted.
"The shoemaker's children and all that..."
Alternatively, "Eating your own dog-food". This might be the service they provide to customers. If the manglement can't see what's wrong with the service they provide to themselves they're not going to see what's wrong with the service they sell.
there really needs to be more options in corporate IT world to enable scientific computing staff to run different operating systems from the office droids. I've worked on locked-down Windows environments for years and frequently ended up using my own computer for work because the corporate sanctioned Windows box was useless. It's 2021 and IT is still a blocker more than an enabler.
Of course it is, manglement wants control and privileges are not for the hoi-polloi.
As a freelance consultant, I see many companies from the inside. As far as IT is concerned, my customers are all over the map. One has a strict non-admin policy, which does not bother me because my workstation there has the stuff I need to work. Another has a strict no admin policy for employees, but a rather lax policy for consultants that work with the IT department, meaning that my workstation there functions under admin access - and my workstation is the one dedicated to external consultants, meaning that every other guy or gal that works there uses that workstation. With admin access.
And lets forget about the companies where I am the only person who knows their network and how to fix things - which is frightening when you know that I am not a network admin.
I recently got a new contract at a large administration which has an interesting policy. Normal users do not have admin access and software requests must be approved by manager and deployed by IT. It works. But some people, me for example, do not fit the general population and get granted an admin account. Now wait before you howl : the admin account is not the work account. I can only work on the work account, but when I need to install something that is not in the IT list of approved software (because they had no idea), I can do so in my work account by giving my admin account login and password. So I have the flexibility to do what I need, with the security of my work account. Not bad, I think.
"But some people, me for example, do not fit the general population and get granted an admin account."
Yeah we do the same with our customers. User accounts are never granted admin access, but if they insist on needing admin access then they're issued with their own separate admin login that can be used via UAC. If the user needs admin access to all the machines (so they can enter their admin login, but their users can't) we setup the admin user as a normal domain user within a local admins group, and use group policy to assign that local admins group to the local administrators group of every machine... excluding the server obviously.
Of course, most companies make it punishable by summary dismissal to have sensitive company information on personal equipment. You did have it agreed in writing with the people who wrote those policies that you could do work on your own equipment, right?
... right?
It appears that you might have more of a problem with corporate policies and HR than IT who are enforcing those policies.
Most companies? Perhaps most *within a particular market sector*, but widening the scope out to *any* company which has any sort of IT requirement and where an employee might want to use some BYOD kit to work on, I think you'd be surprised at just how much of a free for all it is in general.
Leaving aside the definition stretch that "companies subject to GDPR" is a market sector in the same way as actual market sectors such as "finance", "engineering", "medical" etc.- there are very few companies where every single employee spends their entire working day doing nothing but handling data subject to GDPR or other legal restrictions, and where BYOD could never be an option.
Even in companies where most of what they do is covered by such restrictions, there's going to be at least *some* work that could legally be performed at home using BYOD gear, and in many companies it'll only be a minority of the data for which this is an issue, quite often then concentrated within the data subsets handled by specific teams within the company (e.g. HR, accounting) leaving other teams almost or entirely insulated from having to worry about data handling legalities, and only needing to concern themselves with whatever their company policy is on BYOD.
So I still stand by my earlier point - BYOD *will* be an option for many companies generally (even if not for every single employee of that company) unless they're working within market sectors where GDPR or other restrictions apply to most/all of the data the company generates, hence my "within a particular market sector" reference.
"Let's assume a particular market sector of "subject to the GDPR"; because how are you controlling and securing data access if your letting home users store the data on their personal equipment?"
How do you control the salesman who has all his contacts written down in his private notebook "just in case"? Because that is also as much a potential breach of GDPR as having it on a personal laptop or personal phone. Data is data whatever its physical representation.
Embedded systems engineer here, and we have the same problems with lack of local admin access when it comes to getting hardware and software configured, although to be fair to our local IT team they do understand only too well the problems the "no local admin rights for anyone except IT" policy is causing for R&D users, but it's part of the IT requirements set by our parent organisation as a blanket policy across all the group companies so they've no choice but to go along with it.
Every evaluation board, devkit etc that has a USB connection wants to install its own vendor-specific driver, diagnostics cables might also then require you to tweak driver parameters to fine tune the cable performance to the needs of whatever it is they're connected to. And every so often you find yourself needing to use unsigned drivers - there was a period of time where I was having to do this so often during one particular bit of product development, that I ended up dusting off a spare W7 laptop from home just so I could run this particular setup without having to constantly jump through the crazy hoops required by W10.
Engineering software then often feels like it's stuck in a timewarp when it comes to installation processes, and that's just considering the stuff that's still in active development and could therefore have been brought up to date if the developers could only be bothered - where legacy product support is concerned, the need to run legacy design software (whether it be commercial such as a compiler, PCB design tool etc., or something in-house like a production test tool) often goes hand in hand. Then there's the older niche design tools you've been using for years/decades, which still do the job just fine and which you can use without giving them a second thought (none of this "oh look, it's a new version with yet another new UI redesign" crap that seems to be so in fashion these days), which you really don't want to have to do without or try to find a comparable alternative.
At a general, abstract, level I get why IT teams are keen to not dish out admin access to ordinary users, and in an ideal world I'd be only too happy if I could do my job effectively without ever needing to try and remember what the bloody admin password is, but when these policies come crashing up against the real world requirements of certain types of development environments and in turn prevent certain classes of user from being able to do their jobs effectively then there either needs to be an acceptance from whoever's setting these policies that there are some users outside of the IT team who may well need additional rights beyond the bare bones essentials given out to everyone, or an understanding from management generally that applying these policies without exception *will* lead to random reductions in productivity from those users as they wait for IT to configure something that they used to be able to do themselves, often at those times when you're expecting them to come up with results ASAP.
We have a "Trusted user" in some areas, someone who also has an elevated account, linked to a group of PCs in their area. It means that a lot of the time supplier updates can be installed by the local admin in the dept but only on the PCs specified. So Bob can update the software on the 6 PCs in the warehouse so the barcode readers recognise some new style of code but his elevated credentials won't work anywhere else.
It's not everywhere & has been withdrawn from some areas after "issues" but in balance it makes things a little easier for everyone.
One of the most important areas where restricted rights is critical is in the web browser. The whole world (statistically speaking) allows anyone to run untrusted and essentially unverifiable scripts on your computer when you visit a web site. As JS is, and has been for ages, the primary vector for practically all client side compromises, this doesn't seem a very good idea. However it's increasingly being forced on everyone by web developers, even to the point where without scripting enabled web services simply don't function at all. So we're being forced to expose ourselves to compromise just in order to use the web, despite in many cases the function being offered being implementable safely and effectively without the use of scripting at all (e.g. loading images, displaying menus, submitting flat forms).
One of the most important areas where restricted rights is critical is in the web browser.
Good point. Any thoughts on how to warn users that they are about to run a scripting enabled browser as a privileged user? There's probably a way -- at least in Unix. But nothing pops into my mind. Especially if said browser is already running in another window/workspace for some good reason.
"Any thoughts on how to warn users that they are about to run a scripting enabled browser as a privileged user?"
You don't have to be a privileged user. There are plenty of ways JS can mediate successful attacks via the browser without requiring admin privilege. The fundamental problem is running completely untrusted and unverified code from unknown sources. Pretty much every "user policy" prohibits doing this, but the browser by default does it silently most of the time, because the majority of web sites and services don't work any longer unless JS is enabled, commonly for no obvious good reason.
"gives an example of an overworked IT support desk granting users long-term special rights to perform tasks to stop them filing new tickets each time they need to access something."
so now instead of logging on to x system & having a nose around you have to create a ticket in your ticket system, log in to the beyond trust portal, tell it your ticket number then select the correct device for it to then log you in. You then realise it wasn't that box you needed but the other one, so close your ticket, open a new ticket then log in to the portal then log into the correct box see that the thing you need forwards to another box so log another ticket and repeat the process.
What took a few minutes will now take hours. Heaven help you if you need to get your tickets authorised by a manger or change control.
Suddenly troubleshooting is far more complex and arduous.
Also your access logs become meaningless as guess who's logging into all those boxes, not you but the beyond trust system.
who made that change last Thursday at 14:43? It was Beyond Trust!!!!
"Why would anyone, or any organization, allow a user to browse the internet with administrative privileges?"
"Because I have to have Administrator rights because I'm a director of the company!"
Worked for this company for 15 years - until it went bust. Never did manage to explain why this was such bollocks.
""Because I have to have Administrator rights because I'm a director of the company!""
Well then, more fool you for granting them to the person. Directors of a company don't have to have Administrator privileges, at any time. They are not in charge of Administrating all of the computers deployed throughout the business. If you were stupid enough to give them Administrator rights, then it is no surprise to me that the company went bust, even if you were otherwise directed to do just that. If, on the other hand, it was some other person who went and did that, then they ought to have been terminated on the spot, regardless of their ranking within the business. Even the MD isn't exempt from that. My experience is that the louder people shout that they NEED Administrator privileges, is that they should under NO circumstances be granted them. End of rant!
Maybe if Windows wasn't so breathtakingly stupid, we could do that. But there are too many things users need to do that require admin rights.
Hell, certain software _requires_ admin rights to function properly, because most windows software companies can't code their way out of a paper bag. I'm looking at you Intuit.
No, the application vendor will tell you it requires admin right because they are lazy and/or inept. Almost all of the time, it doesn't. You just need to work out where it is trying to write to and fix the permissions.
Why is a developer writing software that puts stuff in the wrong place, the OS being stupid?
I wish windows had a better system for rights elevation. I got spoiled in Linux, my daily driver account was a normal user, so if I did something stupid there were at least some guardrails. When I needed to do something privileged, sudo made it painless to elevate permissions, but *only* for as long as I needed them.
When I started at $currentjob, I was expecting to fight permissions issues (I'm one of those annoying engineers that has wacky software and development needs that require local admin all the time). My employer is big enough and has old enough IT systems that we have one of the original class A blocks. Our policy for local admin access is essentially 1) you fill out an online request with justification, 2) your manager approves, 3) you acknowledge that accepting local admin rights also means that if you trash your computer and come to IT to sort things out, they can tell you to pound sand. The only fix they'll guarantee is to reimage the machine, you'll have to re-request local admin and that future admin requests will be reviewed with the knowledge that you already messed up before.
Yes, it's easier to run as an administrator. Yes, your personal kit and software can make your job easier. Yes, an IT department can hold things up.
Yes, it's a security risk to run as an administrator. Yes, personal kit and software is a security risk. Yes IT departments are overwhelmed.
But the article is right too. Companies have to spend money and customer goodwill to fix problems, up to and including major breaches, caused by overuse of admin rights.
Until companies decide to spend money proactively, increasing IT budgets and making them usercentric, instead of reactively, the problem will remain. And judging from management trends (e.g. how many lo-code, no-code solutions will require admin rights?) and management knowledge (e.g. today's ElReg interview with Twilio's Jeff Lawson) it's not changing any time soon.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
