Half our company is local admin. Security team finally noticed. Now it's my problem to fix without anyone noticing.

[-]

tensorfish@reddit

Do not start with a 140-user scream test. Run EPM in audit mode for a few boring pilot cohorts, group the hits by publisher/path, and make dev and finance prove the exact executable that still needs elevation. In most shops half the 'needs admin' pile turns out to be updaters, bad installers, and one cursed legacy app.

[-]

pdp10@reddit

Twenty-five years since Win32 apps needed to be aware of permissions, yet perhaps 10% of them still don't work.

If the code is this bad at what you notice, how bad is it at what you don't notice?

[-]

Extension-Ant-8@reddit

That’s Microsoft’s fault though. Should drop support for old stupid shit like this. Oh what’s that your 32bit activex plugin that needs admin rights wants to run? No. You wanna run it then you run an old version of windows. Make the developer … you know .. develop.

[-]

killjoygrr@reddit

Until the developer has been out of business for years and that software is what runs a million dollar piece of niche custom hardware.

[-]

Extension-Ant-8@reddit

Again in a modern patched environment this isn’t my problem. Run it on an old version of windows. I mean why does windows 11 have a built in driver? Drop support for it. Move on. You can’t support everything and everyone forever. I mean remember when Apple dropped support for 32bit apps, they provided all the tools to migrate and have everyone 3 years notice. At the end only about 10% of the apps didn’t come over. The world moved on and people found alternatives. But if your multimillion dollar program needs investment but your company doesn’t invest in it then why does the OS have to be held back? I have zero local admin accounts in my environment. Never needed it.

[-]

killjoygrr@reddit

Keeping those things on old hardware and OS and segregating from the network, or isolating it is usually the way for such things.

It isn’t multimillion dollar software, but the hardware. I’m referring to vendor software, not internally produced software that runs one of many niche pieces of heavy machinery.

Windows 11 isn’t going to “have a driver for it”.

Often, there are no reasonable alternatives due to a few factors. Beyond the high capital cost for a single piece of manufacturing hardware, the downtime to the entire line while removing the old unit, installing the new unit and figuring out how to make it fit into the workflow pushes the cost into being calculated by how long the facility is shutdown in days or weeks.

Not something you will see in a strictly office environment, but anywhere with any amount of manufacturing will have at least a handful of these beasties lurking about. And telling the business that you are just going to drop support for their revenue stream will set you on the path to an employer or location far from a production line.

[-]

ReputationNo8889@reddit

We have had our main plant purchase a multi million dollar machine with a Windows 8.1 PC in it. Cant be updated to 10 or 11, of course has to be on the Network. Our sec guy went home early that day. But it is what it is. If a machine makes the business 100mil then they wont care of some sec guy has a issue with the attached pc.

[-]

psychopompadour@reddit

I too work IT for a non-tech company and yes, this exactly. We can't drop the vendors when our customers want their products, and for efficiency, we have to at least TRY to get their shitty custom catalog and ordering software that was developed for win7 (if you're lucky) working. The vendors do come up with new stuff now and then of course and we are grateful (oh, you went to an entirely online catalog/ordering system that will even export a custom csv we can import into our own inventory db because we're one of your biggest clients? BLESS YOU!! Please ask the other 15 vendors in your same niche to also do that!)

I think it's different at companies where tech is the product and developers are a big chunk of your users, but when you run a complex business dealing with actual products and physical locations, you don't have the luxury of just telling vendors to step it up, because a lot of them are small companies who paid a lot of money 10 years ago to get that custom software made by some third party. You might say to just not carry their products, but our directors tell us to make it work because that product makes us a lot of money, etc. We do what we can.

[-]

RCN_KT@reddit

Some well-meaning, and often absolutely correct for most circumstance comments but, unfortunately, have a myopic/limited view of how different industries work. Those with "digital-only" perspectives, training and education, the many, many dinosaurs of infrastructure out there are cautionary tales but for those in the industries that rely on these things, they are daily realities. IIWII.

[-]

i-am-spotted@reddit

Have you ever worked in OT? Multimillion dollar pieces of equipment running outdated operating systems is a way of life. As others have said, when replacing said equipment is measured in days or weeks of downtime, it makes more sense to maintain the existing equipment and software than replacing it

[-]

Extension-Ant-8@reddit

Sure have. I am an IT architect and had final design say for a billion dollar unique medical production facility that was the only one on the continent. Lives were dependant on it so any equipment, os or software that was not fully supported by vendor was dumped immediately. We had fully supported, patched and air-gapped networks. With as much support you could get. There were legal requirements too but we did it anyway If you are in the business of making something. Not maintaining your shit is a bad company that doesn’t give a shit about what it is making. Anyone who does not factor in maintenance windows, operational changes, enhancements as a part of regular ops deserves any outage it gets. I’ve also done 15 years in regular manufacturing, with a big focus on IT business transformation. Simply put for companies that don’t keep their shit right. The moment you dump an old shitbox computer on the table in the boardroom and say. “Hey that outage the other week that cost us $500k when it was down for a whole day? It was because you all decided not to pay for this machines replacement… we have hundreds of these… “ Or remind them about liability etc. it gets done. If it doesn’t. Move to another company where the business continuity plan isn’t just calling your phone number when the boss is playing golf.

[-]

i-am-spotted@reddit

So having also worked in manufacturing, I've seen plenty of equipment running on old operating systems. The equipment itself is perfectly fine. So you put proper controls in place so it doesn't cause security issues on the network.

But let's be real: not every company has a billion-dollar budget or the leverage to demand vendors update their systems. You had air-gapped networks and full vendor support? Great. That's a luxury, not a standard. Most of us are dealing with orphaned equipment that hasn't been made in a decade, running in shops where "maintenance window" is a dirty word.

Your boardroom shitbox story works if leadership gives a damn. If they don't, no amount of PowerPoint heroics fixes it. And telling everyone to "just leave and find a better company" ignores that for a lot of people, that job is the best they've got in their town.

So yeah — maintain your stuff. Isolate the legacy gear. But don't pretend total vendor support is always an option. Sometimes you just keep the old machine running because there's literally no replacement.

[-]

Extension-Ant-8@reddit

If the idea of a maintenance window is a dirty word then you are working for a shitty place that probably pays poorly and is circling the drain. Ask yourself. Why? I mean. I Recently bounced between 4 companies. 3 of them were shit. Who had their whole place like you described. So I moved. Why should I placate dumb management by being a miracle worker? I work hard. But I don’t work hard in dumb companies.

[-]

killjoygrr@reddit

The problem isn’t maintenance windows.

It is an issue where companies don’t have millions of dollars in capital lying around to replace working manufacturing equipment just because the system running the machine is outdated and there are no updates from the vendor.

In all of these situations, you are talking about spending hundreds of thousands if not millions of dollars because the sysadmin doesn’t want to support old tech. There is literally no vendor to pay to get updates. Perhaps in the medical field you can piss away millions to replace an old PC and whatever it controls while getting will zero gain in function, but that isn’t really the case anywhere else. Or realistically, you had lives on the line as well as legal obligations (aka lawsuits and PR risks).

Without outside requirements, do you really think it is worth a million dollars to not support a single windows XP machine? Or sometimes a MS-Dos system.

Seriously, how do you justify the cost of the upgrade for the benefit of what? So the sysadmin can say that they don’t support older tech? Because the ROI is basically never. What kind of manufacturing did you work in that had those kinds of margins to have that much cash sloshing around?

[-]

Extension-Ant-8@reddit

Maybe it’s because this is an American dominated sub. I’ve worked with enough Americans to understand your profit at all costs attitude. But I’ve kind of already answered this. I’ve also fully aware of what you are explaining. Simply put ROI is not the main metric for companies that have its shit together. If their/your process is run it until the breaks and then call you. Then you are working for a shit place.

There are both business and regulatory requirements that require more than that. I’m deeply governed by several things. Like ISO 270001 and you might want to read up on the ISO 27001 Patch Management Policy. Which is critical for certification. If your company doesn’t operate at lease ISO 9001, ISO 14001, and ISO 45001. Then hey your comment makes sense. I’d rather work somewhere else.

[-]

killjoygrr@reddit

What maintenance would you do on a PC to keep it from breaking? Particularly when there have been no patches available for years? If you want to be proactive, you have backup systems built and ready to put in place as well as plenty of spare parts.

I don’t really care to dig into ISO 27001 to try to figure out if they really have no way to deal with oddball pieces of equipment, but none of the other ones would impact this in the least. Again, it isn’t the manufacturing equipment itself that we are talking about, so replacing that equipment because you don’t like the OS for environmental purposes? Really? Or safety requirements? You think that the control box running Windows 11 is safer than running XP? How so?

I think companies are insane for running after profits above all else. I do not champion that at all. But in these situations, there aren’t safety or environmental risks posed. It isn’t profit at all costs. It is a fairly level headed risk/cost calculation. Spend a few thousand and you can be ready to fix whatever breaks. The actual equipment gets its regular maintenance. It isn’t as easy to let scripts do all the work, but sometimes just throwing money at a problem isn’t the best way.

Honestly, replacing massive, expensive equipment because the control box is outdated would go against the ISOs for environmental issues and likely safety issues due to the amount of waste disposal and safety risks due to new equipment and changed workflows.

I do think part of my issue here is the general attitude that companies should bend around what makes life easiest for IT.

[-]

Extension-Ant-8@reddit

I think I’ve answered this enough and you are pretty far from the mark here. You are pretty set in your ideas and fail to understand some basics around computing in a highly accurate, controlled environment or even the concept of certified systems. I mean if you think XP is fine and “a few thousands” will fix whatever breaks it’s clear we are not talking about remotely the same thing in the same orbit. I once had a piece of machinery become unsupported because the company were going under. We simply purchased the entire company. In your mind, you already manufactured a problem about changing workflows. But fail to understand the cost of it going unsupported, loosing certification, ransomware and risk. Loosing manufacturing ability alone would destroy the org. So you make sure you don’t buy a $10 million dollar medical machine and get no support and no maintenance and expect not to occur millions in losses if there an issue. Especially when that thing makes you money.

Here is some fun reading. it cost them 300 million by not patching their stuff in time. Meanwhile my entire environment, is vendor supported, both software, hardware and even the TV’s in the meeting rooms and every endpoint is patched within 48 hours after a full assessment in our lab. Plus every app and executable is white listed and we get regular pen tests by 3rd parties. If my environment gets hacked I and completely wipe and recover my every single endpoint in an hour. Plus got that Windows 365 pre configured so I can create virtual 1:1 environment for every endpoint and that is still certified.

[-]

killjoygrr@reddit

There is definitely a disconnect here.

We are definitely not talking about companies in the same orbit.

“We simply purchased the entire company” speaks volumes about the orbit you are in. Honestly, the concept of having the financial capability to buy an equipment manufacturer to get software updates for a single piece of equipment is mind boggling.

That is a level of wealth beyond typical American manufacturing.

I think you are viewing manufacturing companies as if they were equivalent to the medical organization you work for. They are not.

I would think that in the medical field you are seeing constant technological process on the capabilities of equipment so there is constant development and improvement and your typical piece of machinery isn’t going to be expected to last the life of the building they are in. Manufacturing equipment is designed and financed that way. You will have equipment that has been around since the 70s or 80s and was priced out to have the kind of lifespan. But in a niche market without much innovation, it doesn’t take much for those vendors to go under. And now the software for the PC that runs your hardware with an expected lifespan of 30+ years no longer gets updates. Keep in mind, you aren’t changing the task that the equipment does. The only purpose for the software updates is to stay on current hardware/software.

Talk to anyone who has spent any time in I/T who has worked with a manufacturer that isn’t cutting edge and everyone has run into this situation. No one likes it and the companies aren’t in that position because the were being cheap, but because you can’t always know what will happen to your vendor over the next several decades. They bought the equipment with support and maintenance, but that company goes out of business after a decade or two. To blame that on the company lacking foresight is bizarre.

I never said that XP was “fine”. But when the company runs the numbers and finds they can’t really afford to replace equipment a third to half way through its expected lifespan, you look at ways to deal with it. On one hand, you replace the manufacturing equipment with high capital expenditure the should have decades of life left and is easily repairable in it. On the other you find ways to deal with a control system that you cannot fix (update the software). You treat it the way you would any other part on the machine. But in this case you wouldn’t have a machine shop fabricate a part, you find and assemble the part from older equipment that you keep in a good environment and occasionally test. Total cost in the millions versus total cost of maybe as high as $10k.

I am not diminishing the risk to any company by having old equipment, but to act as if there is no way to harden old equipment from such attacks makes me question your understanding of the basics of computers and how hackers gain access. Real life isn’t a movie or tv show where the bad guy can just remotely take over any machine they think is there. There has to be a way to connect to the system.

As I said, you may have to segregate it or isolate it entirely depending on how it is used. But it is not as if having an XP system on site means that your company will explode due to its mere presence. Worst case, air gap it. At that point, the PC really is just another part on the piece of equipment. And if you have to deliver files to it, you use sneaker-net. Not glamorous, but cost effective.

I do think that the issue is being in different orbits. You are in a world where you can spend millions of dollars on a whim. Manufacturing relies on steady cost controls to stay competitive. You confuse most American manufacturers with companies like Amazon that have the “profit at all cost mentality” and the finances to spend whatever they need to get what they want. Most manufacturers are struggling to survive.

[-]

Vodor1@reddit

Manufacturing industry for many smaller firms is an impossibility to replace those old machines. It may well be country specifics, but they exist and there are many of them.

IT guys don't jump ship because the old equipment won't get replaced, we're the guys who do our utmost to help in any situation the best we can with what we have to work with. If we ran away from these things then so many companies would just have to shut down.

We can't always fix things, but we try our best, we're the unsung heroes of the technical world who are always under appreciated but that's how it goes. If you have a nice easy life in IT, you're probably an executive of some sort.

[-]

ReputationNo8889@reddit

Nah having legacy support is much better then good security. How else am i gonna run my XP apps on Win 11 /s

[-]

ReputationNo8889@reddit

I was in a simmilar situation but we had about 400 devices and EVERYONE had local admin. I just got the singoff from management to remove that broadly and then we restored access to anyone who said "this is broken" then piece by piece moved everything over to EPM once we knew the scope of "needs local admin"

The local IT had no clue what it was even needed fore, i have a feeling that it was just easier if the user is local admin to install stuff and not have to login with your user account

[-]

TheGenericUser0815@reddit

Back then it was AutoCAD LT that needed local admin privs.

[-]

itishowitisanditbad@reddit

Do not start with a 140-user scream test

Not until I head out to lunch anyway. Or maybe I should take a week vacation on this one.

[-]

nevesis@reddit

For the legacy/finance app, try running as a user while running procmon as admin. Filter to access denied.

I've seen many cases where the app just needed permission to write to a HKLM key for example and then ran fine in user mode.

[-]

thefinalep@reddit

Also for 140 people, BeyondTrust EPM will be relatively cheap and a very easy way to "elevate" those updater and maybe that legacy app without giving access to other things.

For my devs, stuff like visual studio installer, debugging tools, and a handful of others just have elevation applied without approval.

[-]

Undeadlord@reddit

This is what we did back in the day. It was called Avecto back then, installed it, let it run in Audit mode, and basically allowed our users to whitelist/Admin run anything already installed. Then we removed Admin from everyone and as new machines rolled out, apps they had before but were not part of our catalog had to be requested and approved.

It wasn't real fast, but it did work.

[-]

thefinalep@reddit

Fun fact. The modern product is still Avecto. The name is everywhere under the hood.

[-]

Undeadlord@reddit

LOL I still call it Avecto, no matter who bought or how they rebranded it :) We still use it, though apparently thats ending soon, but I just don't manage it any more (well I still do but I am not supposed to, I have other duties)

[-]

thefinalep@reddit

We had to move to cloud EPM as in Dec 2026 GPO is going end of support.

It's functionally identical, and a bit better to manage in a few ways, just costs more.

[-]

Undeadlord@reddit

I wonder if the people who handle it for us now know that .... I am sure they do right???

[-]

thefinalep@reddit

Well. There is no "Mirgrate" they'll have to recreate policies/access. Good news is you can run cloud/gpo side by side during the migration. Was a good chance to audit policy set.

[-]

bingblangblong@reddit

Boring, just do it. Come on, it'll be funny.

[-]

skiing123@reddit

OP, if you do this I will need an update post

[-]

billndotnet@reddit

"You're not stuck with the users, they're stuck with you."

[-]

ediblediety@reddit

This guy de-admins

[-]

Khue@reddit

Also there are undoubtably some users in that 140 person tranche who absolutely would not suffer in the slightest and be fairly easy to tackle. It may be only like 10-30 people, but it reduces your attack surface by a reasonable margin so knock those out to get progress going.

I'd do an indepth analysis of the user base and project to management the risk and the timelines. I would estimate in 6 months or so, you should probably be able to get that number down to about half and most likely at the end of this exercise, there will be a few users you will have to have a "risk acceptance" stance with because they will just not be able to have admin access restricted because of the software you mentioned.

Another important part of this is that new users that fall into roles for that original 140 person tranche should ABSOLUTELY not get admin rights and you should already have new user template figured out.

[-]

GenerateUsefulName@reddit

Honestly, I would be happy if any of my higher-ups took a stance towards security. I usually have to push from below and explain to them why it is important and hope they see it similarly.

Get a proper patch management software (I can recommend Action! as it is free for the first 200 endpoints, so good to test thoroughly). This way you see which software is installed where and you can uninstall any you see as a risk.

Then upload common apps to Intune, so people can install them via the Company Portal app themselves without admin rights.

If you do create local admin accounts as secondary accounts, add them to a no365sync group in your AD.

Going forward the policy is if you can't find it in Company Portal, you need to reach out to us via ticket. Then either install via patch management or have short calls with them. No local installation should ever happen outside of IT approval. The stuff my users would install if I let them. Someone tried to install a bitcoin mining app once but Defender stopped that shit right there.

[-]

DiabolicalDong@reddit

Our EPM tool ran in learning mode for a week or so. It collected data on which apps are run with admin. We then created the policies/rules based on this data. It took us about a month or so to get it set up. It is not a 'set it and forget' venture. We still update our policies when required.

If your developers need elevation constantly, you can configure automatic approvals for requests raised by them. They stay standard users but are able to do their job without any hiccups. We use Securden EPM btw.

[-]

billnmorty@reddit

Devs , the security gift that keeps on givin! .. amiright?!

[-]

therankin@reddit

That's insane! I can't believe that anyone has given out local admin after windows xp. With XP, you kinda had to in quite a few cases.

But since Windows 7, it has totally been not necessary.

[-]

Expensive_Plant_9530@reddit

The very first thing you need to do is NOT try to do this secretly.

You’re going to piss off your end users either way. Better to give them plenty of notice of the deadline.

I’d also start with small scale tests and expand the test groups until you’ve got the process fairly nailed down.

[-]

peace991@reddit

Exactly. Why a secret? Companies are authoritarian regimes. You are their police. Once the boss says this, everyone follows. If they don’t like it, they deal with it or leave.

[-]

montarion@reddit

We reiterate that any and all data on their machines is company property

idk where you are that that's legal, but I'm glad..

[-]

MidnightBlue5002@reddit

er ... almost everywhere? Where is this not legal ... you don't own the computer, the company does. It's not your toy.

[-]

montarion@reddit

you don't own the computer, the company does. It's not your toy.

true, but that doesn't mean the company has ownership of what personal data you put on there.

[-]

MidnightBlue5002@reddit

if you do not own the computer, you do not put personal data on it.

If you rent an Air BnB do you redo the interior carpeting while you're there and permanently hammer pictures of your family onto the walls?

Same thing. Company property, company data on it. Period.

[-]

FarmboyJustice@reddit

Is this even possible? How are you supposed to avoid looking at personal information on a company computer when it's your HR data, or your company provided 401k or health insurance program?

The reality is there's not this simple clean line you're arguing for.

Owning the hardware does not grant ownership of the data stored there in any jurisdiction I know of.

What legal remedies employees have will vary by jurisdiction, but most of Europe will be like "Hahahnope" if you try to claim this.

[-]

MidnightBlue5002@reddit

obviously ... data about your personhood that your company has to have ... is "personal data, which you've GIVEN to your company"

Pics of your kids or your horse farm is not.

[-]

FarmboyJustice@reddit

What I really said was there's not this clear sharp dividing line between what should and shouldn't be personal data and whether it's acceptable for it to be on a company laptop. I guess you have a hard time figuring that out.

I also said jurisdiction makes a difference. Apparently that's also too hard for you to figure out.

Gee, it sure is easy to just insult the opponent by saying they can't figure out what you mean, no wonder it's a popular tactic used by lazy and dumb people.

[-]

MidnightBlue5002@reddit

thanks for proving my point!

[-]

FarmboyJustice@reddit

Your analogy is still terrible, even though you downvoted my comment. Storing files on a computer is not equivalent to remodeling a house. Nobody thinks that but you.

[-]

FarmboyJustice@reddit

Terrible analogy.

Storing personal files on a work computer is not like remodeling an AirBNB, it's like unpacking your suitcase and putting your clothes in the drawers.

[-]

psychopompadour@reddit

I know you're infosec won't accept this, but our company's solution to this is just to remove it for all non-dev people by policy and for the rest, when they get a new computer, it does not have local admin and when they call to complain, we send the request to infosec and let them decide to give it back (or not). We also use thycotic to run legacy software of the type you describe which requires admin (or at least, full control of all the files in the program's directory) and although it has its own weird problems, it generally does work for that.

[-]

0xC0ntr0l@reddit

I feel you there, I am on the security side and was trying to figure this out for a while with out the above happen. We are half devs and they all do different stacks so getting a inventory or workflow is a struggle. Its come up again because we have been getting a lot of malware on these dev devices for downloading anything, and yeah we push out messages warning people. Long story short many holes in many areas so I am probably just also bad at my job.

I did hear MS might be pushing extra intune features to E5 licences, and one of them is just in time feature that used to be with Intune P2 I think? Looking forward to exploring as an option.

But what we did recently do was on the mac side push out SAP2 Privileges app with a script down set the account to normal. We communicated and I wrote out a quick document on examples when users would need to use it. Some were annoyed but most adapted and its just a button we pinned in the dock too. For apps that need admin to update (some are in our catalog but they try auto updating so you get the touch id prompt, or for apps not in our catalog) we found some success for moving them to the users application folder.

None of it really answers your question, but with the mac experience and migrating, user documentation on what changed and what to do helped, along with working with dept leads and explaining some things to get their "buy in". Having their support I think is key to keeping things smooth.

[-]

Odd-Landscape3615@reddit

We have a number of dev / dev like teams, and autoelevate took most of the pain out of the process for us.

Local profile installs (on Windows) can quickly become un-manageable, but it is a good workaround...

[-]

cheshirecat79@reddit

We’ve done it with Autoelevate, but most Pam solutions function the same. Roll it out in audit, flip the switch to enforce and remove local admin. Easy for users to digest as they can still get approval on a user, computer, or company level for elevations that weren’t caught during the audit. Nothing for them to get mad about. Your devs will be the people you need to coordinate with most.

[-]

Odd-Landscape3615@reddit

Another autoelevate place here :)

[-]

Future-Side4440@reddit

Developers with local admin, become bad developers. They don’t know where to put stuff in a properly secured file system.

Program data that is updated regularly and is not user dependent goes into %PROGRAMDATA%

User data that is persistent across every computer they use goes into %APPDATA%

User data that is temporary and useful to keep around what can be easily discarded or recreated such as cashes go in %APPDATA%/Local

Program registry settings that should only be changed by administrators or system go in HKEY_LOCAL_MACHINE

Per user registry settings go in HKEY_CURRENT_USER

Absolutely nothing should be in the Windows directory other than things that Microsoft puts there. No program data in the Windows directory.

[-]

deathybankai@reddit

My recommendation would to take it a department at a time. You use a deployment tool to install software as needed per department.

You take the departments rights away and see what breaks. See why it breaks and if there is fix. If it doesn’t you can do the JITE for the app launch and not the installs.

Hopefully there is a lot of shared software and that would make it a lot easier.

[-]

SilentFly@reddit

Get a high level manager to send out comms to the company indicating that this is in the pipeline, with a caveat to not shoot the messenger (ie, you). Then, get the other business owners to audit their apps to figure out if the admin role is being revoked, what level of access will be needed for their apps to work as well, devs to fix code in prod and write code. This will likely take a long time and ideally be done with the help of a project manager who gives regular updates to the execs/board. Good luck!

[-]

skidleydee@reddit

For sure find a bad guy to blame i just would make it your insurance company who made you get it for compliance reasons, most of my managers haven't been willing to play the bad guy

[-]

hkusp45css@reddit

In matters of security, I always blame the threat actors.

The rest of us are responding to their presence.

[-]

skidleydee@reddit

Insurance is the only one I have gotten the least push back on. It makes it a hard requirement that's out of everyone's control. Make a joke about bureaucracy and all the sudden your on their side.

[-]

itishowitisanditbad@reddit

100% I will blame compliance requirements and insurance.

Its the most successful thing.

Common enemy sort of thing. "We both got to deal with the bullshit yknow?"

The second its hanging on a person they know is the moment it comes down to simply how much they respect/fear that person.

Which is never enough.

Insurance/compliance? Shiiiiit, they can get 'out of my hands' fired for that one.

[-]

hkusp45css@reddit

My leadership is sane so, I don't have to play games with my ideas. I can simply say "This is unsafe, here's why, here's the risk, the stakes, the mitigation, the cost." and invariably I get back "Make it so."

So, when I have o tell ALL of the EEs here that their day is going to get a little worse, I have the full backing of my XO team behind me.

[-]

skidleydee@reddit

In my experience in the medium size business space (200ish to 2k) breaking rules in order to chase productivity is glorified not condemned by management. I haven't had to do this since I joined the Enterprise because we are able to refer to policy and procedure as a reason that we are doing things.

[-]

af_cheddarhead@reddit

DOD contractor space here, all I do is state "We lose your contract if we fail an audit." It makes both users and managers sit up and take notice.

[-]

chknstrp@reddit

“Can’t you just POA&M blanket admin rights?” - somebody somewhere

[-]

af_cheddarhead@reddit

My response, "yeah, you convince the ISSO/ISSM to accept that risk."

[-]

andrewsmd87@reddit

I use iso for this. Oh it's s compliance thing sorry. It's definitely not me saying you can't do that because you 100% don't need to to do you job Janice

[-]

ImportantMud9749@reddit

Within IT discussions, sure. Higher level it's just another set of disaster recovery guides and insurance negotiation, just like fire/storm/safety. It goes to the disaster insurance bucket because the question isn't "is our system secure and designed well enough to come back from an attack" it is "how do we pay the least amount of premium so that if we have to replace everything we're still covered?"

[-]

hkusp45css@reddit

Absolutely incorrect, in every way.

[-]

AcornAnomaly@reddit

The problem with that logic is that it can be ignored by people who aren't fully rational about it, and only care how the implementation of changes affects them.

"Well, there's no hackers in the company right now, so it will only be a problem if we get hacked."

(Maybe "rational" is the wrong word to use. It could be they're entirely rational, just weighing the risks differently.)

If the ones that behave like that are regular users, that's no problem. Ignore them and have their managers deal with them, if necessary.

If the ones that follow THAT logic are your superiors, however, you often need to point to something immediately tangible as a problem to get them to accept it.

"The insurance company will drop us or raise our rates to insane levels if we don't do this" works better for that.

[-]

waitwuh@reddit

You can lean on “legal and financial liability” for potential software licensing infringements.

With 140 users having local admin, I’de bet at least one of them has installed something that’s not actually license for commercial use.

[-]

LUHG_HANI@reddit

Cyber insurance does state that they won't accept liability if the user has local admin. This was a policy from last year.

[-]

MidnightBlue5002@reddit

This. I usually blame "insurance requirement" or, for those older than 50, I tell them "it's a server issue" and they go quiet.

[-]

skidleydee@reddit

I'm sure thats in 99.99% of policies but i worked for a company that sold Cyber liability insurance and the contracts are not standardized. Or at least weren't in 2022.

[-]

Kwuahh@reddit

I find most finger-pointing to be in bad taste. 80% of users will accept the change. Instead of blaming someone else, explain the change and why it's necessary. If anyone challenges you past that point (without a valid reason), then it becomes an issue for management and office politics. At that point, you escalate to your manager so they can deal with it.

[-]

skidleydee@reddit

Overall your probably right ,and this works great at my current company but in experience in the small business space people are willing to get around red tape by any means necessary, it's often times even glorified by management, watch any movie about a tech start up and this is a plot line. In my experience if your not with them your against them.

[-]

pdp10@reddit

Then, get the other business owners to audit their apps to figure out if the admin role is being revoked, what level of access will be needed for their apps to work as well, devs to fix code in prod and write code. This will likely take a long time and ideally be done with the help of a project manager who gives regular updates to the execs/board.

I'm not sure this is practical in the median organization with 250 Windows users, when OP hasn't mentioned any developers.

[-]

bluegrassgazer@reddit

Yeah, your title confused me: "...without anyone noticing." Everybody needs to know the "why" and timing. Communication for something like this is key to its success. Don't do a rug-pull.

[-]

Cormacolinde@reddit

Absolutely 100%. “Without anyone noticing” is the wrong approach and basically impossible to achieve. Don’t give yourself or allow someone to give you impossible or unrealistic restrictions.

[-]

Octoclops8@reddit

Just send out an email saying that all application installs will now require the approval of the security team. Here is their email address. Then lock down local admin and wait.

[-]

pugs_in_a_basket@reddit

Well, shutting everyone off right now would be a bad move. Talk to bosses, if necessary talk to your boss to talk other bosses that changes are a coming.

As for the audit 90 day window, I doubt you can make it. What you can do, is enact detailed plans with a roadmap. Again, talk or muscle your boss to make sure other bosses and especially the head jefe are on board.

Like who needs local admin rights if they're running local virtual machines? If deployment is x86 and development works with MX apple machines, provide them with virtual machines.

Developers do not need access to production. They do not need clearances, audits, certificates, or otherwise, use your judgement. Separation of duties.

[-]

Assumeweknow@reddit

Add new local admin for them to use then remove local admin rights from thier user.

[-]

iambuga@reddit

We removed all the local admins, minus the engineers, at one time. Didn’t tell them anything. 90+% never noticed. The rest we dealt with as needed. It brought our ticket count way down for malware and broken stuff they shouldn’t have been messing with but it brought the count up for installs and certain upgrades. However, overall ticket count went down. It did make some tasks harder for us as admins but the overall benefit outweighed everything.

[-]

blackjaxbrew@reddit

Anyone that does require admin gets a separate admin account outside of their primary too. That is standard practice

[-]

fra1ntt@reddit

What about users opening mmc/local users and giving with the admin user, local admin rights to their “standard user” ?

[-]

brokensyntax@reddit

Auditing, monitoring, reporting.

[-]

lordjedi@reddit

Don't forget to severely limit that account. Users will just run as that account all the time otherwise.

[-]

brokensyntax@reddit

Any time I've done this, the local admin account doesn't belong to ANY groups, not even domain users.
Its only purpose is the controls necessary over a specific device.
Also have to make sure you're not using "Authenticated User" everywhere on network shares.

Definitely do want it in AD still for management purposes.

[-]

SpocksSocks@reddit

This can work in very small orgs, but having no ability to audit, log or limit admin activity is problematic. A proper PAM solution is best practice.

[-]

Gadgetman_1@reddit

Don't forget the classic 'Deny Logon Locally'

Admin accounts should only be used for 'Run as...'

[-]

dustojnikhummer@reddit

Doesn't Deny Logon Locally also apply to that?

[-]

Gadgetman_1@reddit

nope.

Deny Logon Locally stops the creation of a local user profile and the other resources used during a logon. Run As doesn't need those resources.

It also doesn't cache credentials, so it's a bit of a security point, too.

[-]

dustojnikhummer@reddit

I swear I once denied local logon instead of RDP logon and it blocked "run as", on Server 2019?

[-]

Gadgetman_1@reddit

Never added that to servers, so... Then again, servers can be weird.

[-]

dustojnikhummer@reddit

We use to block connections through our service user that still needs various high level permissions.

[-]

UltraEngine60@reddit

Came here to say this. It's the best way to hold users accountable without adding a new monthly expense to some vendor who will eventually be bought by private equity or Kaseya'd.

[-]

Froggypwns@reddit

This is what we do at my place and it has worked great for us.

We don't prohibit local logins like others suggest, but it only has admin on the PCs we add it too and no access to most network resources. A user can then make a wide array of changes like installing a bulk of applications without having to elevate each time, then go back to their regular account to actually use them. These users are ones we would trust with admin rights in the first place, not just any rando.

[-]

brazzala@reddit

EPM in audit, Psript to remive alll admins bia Intune script.

[-]

juciydriver@reddit

I haven't read all of the comments so, apologies if this is redundant. Would Autoelevate work for you?

I have it where I work, we don't use it to its full advantage but, we have a lot of users with QuickBooks desktop edition requiring monthly updates like an only be applied by admin. How to elevate allows us to configure that QuickBooks desktop will always get admin for, basically anything. I'm sure we can refine the rule but, we only have 20 people and the office. It works for us.

[-]

TerrificVixen5693@reddit

Pull everyone’s admin with an MDM package, if they complain, they can pound the sand straight to info sec.

[-]

dustojnikhummer@reddit

And I will now ask you to come back to reality

[-]

TerrificVixen5693@reddit

The reality that your company won’t be compliant? The reality that your company is voiding its insurance policies? The reality that policy exceptions need to exist per user?

Yeah, back to reality, this is r/shittysysadmin territory and you are too for defending it.

[-]

dustojnikhummer@reddit

You do realize every corporation is subject to different insurance and cybersec policies?

[-]

Aware-Spot-2649@reddit

With a 90 day window to handle this fix. Step one needs to fixing the problem and deal with the issues. With a 140 targets I would keep it simple using remote computer management remove the users from the administrator group at least after 90 days you can say the hole is plugged. Second, users who need elevated rights create a secondary ID username.priv place them on an AD or AAD security group giving those ids administrator access, users then run as using the new id.

[-]

kingslayerer@reddit

As a developer I hate not having Admin privilege. I'd rather quit than raise a ticket for every single time I need a admin privilege.

[-]

marvinnitz18@reddit

omg just let them have it

[-]

badchadrick@reddit

Run as Admin is a giant pain in the ass. Half the time it doesn’t work.

[-]

Liontenderloin@reddit

Admin by request is a pretty good one as well.

Whitelist the few things they otherwise was full blown admin to perform

[-]

-TheDoctor@reddit

I cannot recommend Admin by Request enough. It allows you to remove local admin, but still give your users a certain level of control.

I would also suggest getting some of the most commonly installed/used apps in your org set up in Intune and deploy them through Company Portal if you aren't using it already. Set up a request workflow in your ticketing system if it has that capability so people can request for new apps to be added to the Company Portal catalog.

This transition is going to suck for both you, your IT team, and your users. I worked for a university a while ago that had gone through this transition before I got there and everyone said it was a massive PIA for all involved. But the users eventually adapted and relented. Yours will too. Eventually, not having admin rights will just be how it is.

You also have the benefit of this change being a direct mandate from your leadership/board. If you can, try to lean on them when you inevitably get push back from the users. You just do the work. Let them field the complaints.

[-]

Dufsao189@reddit

I feel like a group policy could fix this.

Along with some AD permissions to ensure the ICT team stays admin on all endpoints.

This way your users shouldn't need to let you do anything with their machines, but you still get the desired effect.

[-]

mercurygreen@reddit

If they didn't flag Win10 as a pretty major concern, I'll be surprised.

Also, there is a huge difference between being an administrator and "Run As Admin"

[-]

EquivalentSilent776@reddit

Scream test while using PTO on a Monday and you’re infamous. You only get one life don’t waste it

[-]

WFAlex@reddit

Sounds like something some of my customers would do, while turning off their phone, leaving me as external consultant to make an executive decision lol

[-]

EquivalentSilent776@reddit

Right, phone off, lol it’s not real if I don’t answer

[-]

WFAlex@reddit

Man as long as it´s not a customer I personally have to consult, I would call the admin that does it legend. if it affects me I would call him an asshole lol

[-]

EquivalentSilent776@reddit

I would give you an award for smashing this if Reddit didn’t make me buy it

[-]

Affectionate-Cat-975@reddit

Just be like the Bobs when they just stopped paying Melvin and let it sort itself out

[-]

ImUrFrand@reddit

group policy time.

air gap the stuff you can't lock down.

[-]

zerassar@reddit

Their base level device should still be locked down. Sure try just in time mechanics if you really must... But frankly that is still a risk allowing people to install whatever the fuck they want to.

IMO their standard corp device should be managed and all software packaged, deployed and updated by IT. Company Portal availability for them to install as they desire.

They can then hyper-v a VM to do their messier dev work in where they can self manage what's in the VM themselves. But the corp device with corp data should be protected to a higher standard than the wild west

[-]

ikylek@reddit

my company for windows removed admin privileges for everyone. you have to use a "-a" account that we have, and then also request elevated privileges for said account. the password for the "-a" changes daily and held in our company's password tool, which requires MFA to gain access to. so, of my regular lab account is johndoe, the elevated account would be johndoe-a

[-]

Soylent_gray@reddit

This might be easier by ripping off the bandaid and officially announcing a new IT policy. It helps if you can get someone high level enough (with a spine) to back it up. If you have a breach, then it's going to happen anyway.

[-]

trobotics@reddit

Check out Make Me Admin.

This is what we used when we pulled local admin rights from everyone.

They can then still elevate themselves when needed with a click, for 10 minutes.

And Privileges for Mac.

[-]

linhartr22@reddit

Where I work you have to be approved to get "Make Me Admin" works great!

[-]

pee_shudder@reddit

I wouldn’t do this anywhere near the way others are suggesting, which gives me pause for myself but..

Having a user pool that large, with Entra Joined accounts, that have local admin privileges, is a hard stop the day I am hired. I would not say a word to anyone, and would systematically, manually, revoke local admin rights to every single workstation immediately, create security groups to handle the necessary executables or developers, join them to it and have the exe’s run-as as a utility user who is in that group, make sure auditing is in place, and call it day. I do not give two fucks who gets mad about it it’s 2026 that is absolute madness from a security standpoint.

[-]

Plenty-Wonder6092@reddit

What? This takes 2 seconds in intune, set your IT admin account policy in intune from "Update" to "Replace" it will now delete all other local admin accounts on the device. If you need to keep the local admin accounts on some devices, simply create another group for the excluded and keep them as "Update"

[-]

way__north@reddit

Last time I encountered "application needs local admin to run" , it turned out it only needed write/modify access to 1 specific config file located under Program Files.

there are some useful tools in the sysinternals suite to troubleshoot this - might be that some of those apps are somewhat easy fixes

[-]

Limeasaurus@reddit

Admin by Request might be worth looking into. We’ve been using it for 3 years with good results.

[-]

DaemosDaen@reddit

tbh, developers need to not be admins. that way they know hos the users' environment will react to their applications.

Most legacy and finance apps will not throw a fit if the user is in the local 'Power Users' group,. This, generally gives users access to the Program Files folder, but not windows. You will need to test with your apps if something lesser permissions (like just access to the program files folder

Your vendor sounds like Tenmast. 🤣Tenmast being the app where i first figured it out how to fix it.

[-]

Suspicious_Drummer27@reddit

Out of curiosity, has management actually defined what “good” AI usage looks like (e.g., reviewed, context-aware output), or are they just tracking usage/adoption metrics without any quality control?

[-]

Wonder1and@reddit

Deploy endpoint privilege management in monitoring mode. (Microsoft isn't the only player so consider checking around before committing) Allow what should be allowed then ban the rest backed by a policy signed off by someone with a sufficient title.

[-]

pnlrogue1@reddit

Finance are a legitimate exemption

Developers can fuck off

No-one else needs local admin

Sorted

In all seriousness, developers do need unusual tools but you can work with them to compile a list of, say, 10 dev tools which do not require local admin and whitelist them for install/update or whatever Entra does (sorry - haven't administered Windows for 5 years so never touched Entra). If they really need 12 tools then push back on the other 2 but let them have them if they really need them. If something new comes out that they really need then so long as they legitimately need it then let them but push for annual reviews of the allowed list and prune if appropriate

[-]

jayhawk88@reddit

Half our users are developers who will raise an absolute ticket storm the second they can't run something as admin. They install tools constantly, some of which aren't in any approved software catalog because we don't really have one.

Something you may want to consider to address this point specifically is to implement the concept of what we call SA accounts. Probably stood for "Service Admin" or something like that, but honestly I've forgotten why we chose those initials.

The idea is that users login with their normal account, but also have an SA-username (or whatever format you choose) account that has admin rights to their computers. But the SA accounts do not have any file rights to shares, discouraging people from just using that account to login all the time. Need admin? Plug in your SA creds to the UAC prompt, and off you go.

This isn't perfect from a security perspective of course; certainly leveraging EPM would be more secure. But especially in smaller environments, if it's not realistic to rely on EPM for everything, it's a step up from just having local admin everywhere, or continually having to manage your way around things like devs needing to install stuff all the time, admins/techs needing to remotely access resources, etc.

[-]

Ark161@reddit

Top-down approach.
- Communication comes from CTO/CIO saying this is happening on X date. Have where Directors or managers need to provide list of staff requiring admin rights with business justification(s).
- Create AD group for admins based on prolicy/preference and populate
- Deploy
- Rip out any non-AD group in local admin and lock it down.

That way you have your butt covered. It is usually either full send with fix foward, due dilligence with fix foward, or a workaround that becomes perm.

[-]

Jaereth@reddit

Create AD group for admins based on prolicy/preference and populate

I'd give them a separate AD account to use to elevate as admin when needed. Blankly running as admin with stuff like Outlook open you know what I mean that's where the real big money problems start.

[-]

GoonOfAllGoons@reddit

From the dev side, this is probably the best way to convert them over to your side of the fence, too.

I would rather not run as admin if I don't have to.

[-]

BatemansChainsaw@reddit

as a former dev, playing in the limited sandbox as a regular user helps understand the limitations of a general user account that doesn't have admin privileges.

[-]

Kodiak01@reddit

For many years, I had local admin on my end-user desktop. Eventually they dropped it during a refresh. If I need to run an installer, I call into the MSP, explain what I need to run/install, they remote in and type the password for me.

This is necessary maybe 1-2 times a year these days.

[-]

AlfaHotelWhiskey@reddit

What about auditing installed apps beforehand? I agree with the d-day approach but how many of these unknown apps will seize up and launch a flurry of irate tickets? Or is that a manageable risk?

[-]

Progenitor@reddit

This! You cannot do this without top down backing and complete air cover by your management chain, and also the development team's management chain. You need to publish this well in advanced and communicate this clearly. No way to do this bottoms up for sure. You will be overwhelmed by the noises and people pulling ranks over you.

[-]

Likely_a_bot@reddit

Without anyone noticing? Disaster in the waiting.

[-]

mjbmitch@reddit

This is an AI-generated post!

[-]

brokenmcnugget@reddit

good luck

[-]

justmirsk@reddit

If you want an alternative to Microsoft tools, check out ThreatLocker. They have a learning more (like EPM) but their platform is the most robust out of every one I have seen. User can also submit a request through Threatlocker to request approval to elevate for something not approved by policy and you can approve it, then they are notified when it is approved. They also have a Cyber Hero team that can do approvals for you, if you wanted.

[-]

djDef80@reddit

You can even create auto elevate policies for specific applications with ThreatLocker. That's been a godsend for those pesky QuickBooks updates!

[-]

HITACHIMAGICWANDS@reddit

I agree that this is a good option. The best middle ground I’m aware of.

[-]

Revolutionary_You_89@reddit

Communicate communicate communicate. If there’s a detection mode you can run, do it in small groups.

[-]

NickBurnsCompanyGuy@reddit

Just pull admin, blame board. Done deal. Care less.

[-]

stephendt@reddit

Good way to get fired. Imagine breaking workflows for half the company and expecting no repercussions

[-]

NickBurnsCompanyGuy@reddit

I'd literally just send an email, then pull it.

"A recent audit of our security controls has determined that local administrator privileges need to be removed. On X date we're removing your administrator access. To request application installs or make something available in intune, please log a ticket going forward. Thank you for your understanding and keeping the company secure."

If the board doesn't understand the cost of their decision, then that's on them.

[-]

Kwuahh@reddit

I can understand your reasoning, but I'd argue that if you want to remain employed, it's best to inform the decision makers when their decisions will have consequences to their bottom line. Most competent IT workers will know that pulling administrative rights from all users without notice or planning would result in financial harm to the organization. Once shit hits the fan and you cost the company millions, those decision makers won't just say "oopsies".

[-]

NickBurnsCompanyGuy@reddit

I've never worked at a place that gave local admin to end users in the last 10 years. I have maybe three end users with the ability to elevate our office 1000. They have dedicated admin creds and are required to log tickets with details every time it's used.

I hear you though, but it sounds like OP has vocalized the severity to the board. Additionally they're not allowing them to hire more people to deal with the upcoming bandwidth crush so they're really just going to fuck themselves over.

[-]

FlyingBishop@reddit

I've never worked at a place which didn't give local admin to developers. Upthread someone talked about giving exceptions for WSL and Docker. So two different ways to run any application they want. Which, like, I can see how there's some benefit to denying local admin, but if you're letting people install entire operating systems alongside Windows in principle you've totally erased the benefit.

[-]

NickBurnsCompanyGuy@reddit

Yeah, but everywhere I've been with Devs, we gave them dedicated administrator credentials and logged and monitors everything done on those privileged accounts. JIT I also recommend highly.

[-]

Jaereth@reddit

Exactly. His only value here is as a consultant/project manager to get this done. When the board says do it they don't mean "at all costs" lol.

[-]

hankhillnsfw@reddit

Honestly this lol.

[-]

crystalbruise@reddit

Honestly, I’d phase it. Start with new hires and low-risk groups, then audit what actually uses admin rights before touching power users. Pulling access cold turkey creates chaos. Use telemetry/tickets to build your allowlist, then tackle legacy apps separately. Slow and boring usually wins here.

[-]

haksaw1962@reddit

About 20 years ago I came into a position with a team running a strictly internal automated testing environment. Log onto the team's website, select your product and tests and they would be automatically carried out and a report generated. Windows 2003, IIS. Admin who built it out was no longer with the company. Digging around I found a few red flags. Asked some of the team that had been around for awhile, and was told that the settings where to make the application work properly. So Isolated internal domain with a one-way trust to the company domain. IIS Anonymous user is set as a Domain Admin.

I just sat and stared for awhile. I confirmed that if you removed IIS anon from DA it broke everything. Needless to say we changed thinks up as we updated to a newer version of Windows server.

[-]

nerd217@reddit

Wanted to add to what other comments are saying..

Intune EPM sucks. It has no alert mechanism built in, so stupid, classic Microsoft bs.

I’d strongly recommend switching to AdminByRequest, AutoEoevate, or any of the other recommendations mentioned by other comments.

Depending on your environment and requirements, but if EPM solution causes issues with legacy software and users need to be local admin, then you most likely end up in the situation of isolated PC/VMs running that software.

[-]

batedcobraa@reddit

Admin By Request is a great use-case for this. When something needs admin approval, it sends a request to certain users of your choice (IT department as an example) via email or app notification to approve the request.

It also has the option to remove all local admin permissions, then adds a local user account with a randomly generated (and periodically changed) password. The password can then be retrieved from the Admin By Request admin portal at any time.

Additionally, it has a toggleable feature called "Smart approval" where if one application has been granted admin permissions X times (default 3, configurable), it will auto approve the request.

[-]

waitwuh@reddit

You have more than a security risk here…

How many of these employees with local admin have software installed that is not properly licensed for corporate use?

Probably quite a bit! People get pretty nonchalant about downloading software, as it only takes a few minutes. Many may not even be aware of the nuance that the free tiers are often only permitted for “personal or educational use” and explicitly forbid “commercial use” or “for business purposes” etc. Practically nobody really reads terms and conditions too closely. Even when users are vaguely aware, they often don’t take it too seriously. But software companies can and do discover and sue for these infringements! And the users can get pretty dumb and give away clues, like registering with their company email address, or even reaching out to or responding to the software’s support staff and letting details slip about what they’re doing with it.

So the scary words you can say now are “legal and financial liability.” This can give the mandate to lock down local admin more weight.

Consider looping in a legal person, if you have any at this company, to push for supporting audit and lock down from this additional angle. The advantage here is that this expands the interest stake beyond IT security, shifting the “blame” a bit for any potential business disruption. Like hey, you’re not trying to be a bad guy, but some day there may be a letter from some lawyer… The disadvantage here is that someone in legal may have a little freakout when they learn about this and spends a few minutes googling. But it’s a play of politics, because you are here to help solve the problem, and legal can help apply pressure and get you support to move faster.

[-]

WWGHIAFTC@reddit

Identify the drone workers. The ones that literally just use Word/Excel/Internet/Email and the ERP or Finance or HR app. This will be easy and they won't notice.

Then work your way through departments. I was able to go from 110 to 0 in about 2 weeks. Nobody noticed, but I took precautions. 6 months later, someone noticed and I helpdesk got them going with a update of approved software that needed admin to install.

[-]

ThinkMarket7640@reddit

Oh look it’s the travel agent “sysadmin” with yet another completely real AI generated slop post.

[-]

PlannedObsolescence_@reddit

Yep. Engagement bait posts and karma farming comments. I don't know why on earth people don't see through this, and instead upvote it...

[-]

1z1z2x2x3c3c4v4v@reddit

I don't know why on earth people don't see through this, and instead upvote it...

Because most people have a basic human desire to help out another person. And they can't see past the question.

[-]

Skyler827@reddit

This may be completely true, but in the moment when we are reading a post and responding to it, a lot of people are not focusing on weather or not it's AI generated, and are going to respond anyway. And AI detectors powered by AI are not fair or accurate enough. When you're on the open internet, It is just really hard to escape the watchful eye and the bulbous excrutiation of the slop machine.

[-]

Kittamaru@reddit

I mean... where I'm working, we are frequently told it doesn't matter and that a ticket needs raised for anything and everything that requires elevation.

Real fun when we get mandates from the ESO to patch Java vulnerabilities... and we can't do it ourselves, so have to get an OAS admin to do it for us... and they then have to put in a request to have a temporary exemption in the firewall to let them download said patch.

Generally, by the time its done, it's time for the next patch... repeat ad nauseum.

[-]

1z1z2x2x3c3c4v4v@reddit

Anyone done this at scale without either a 6 month project or a full user revolt?

Whatever... it will take AS LONG AS IT TAKES. Do not worry about this. If you can't get it done in 89 days, what are they going to do, fire you...

The goal is to show steady progress. Do the easy ones while working on the hard ones. Ecvebtually you'll be left with all the ones that can't or won't comply. And you escalate that to your manaher.

This is not your "problem", its only your project to work on. Compliance with this new rule will only last as long as anyone higher up cares. And its clear they didn't care for a long long time.

[-]

vgullotta@reddit

I wouldn't try and do it without anyone noticing, I'd send out a notice that it's gone after you do it and why it is gone. I'm about to hit my 20 year mark at the company I with at, I'm a senior sysadmin in charge of thousands of servers, I do NOT have local admin on my workstation. Our IT team has admin and that's it. There is an approved software list that we can install on our own, (office, Outlook, teams, company software, etc.) but anything that is not standard needs approval. It is better this way for everyone. I don't mind it at all, if your users do mind they're likely doing something they shouldn't be doing lol

[-]

Ok-Measurement-1575@reddit

People get too jumped up about local admin tbh.

[-]

burkey_biker@reddit

For the love of god, just remove it and deal with the fall out.

[-]

Sufficient_Duck_8051@reddit

I’ve been using a different method - remove admin access but make it still possible via audited powershell script that lets users grant themselves temporary admin rights for 10 minutes, max 5 times per day, asking them to provide explanation why admin access was requested.

This automated system doesn’t limit anybody from using their computers but adds some layer of accountability and makes it easy to audit / limit access if needed

[-]

lordmycal@reddit

I would try and build application shims for the software packages you know that have issues because in my experience they typically need rights to an additional set of files, folders or registry keys and that's it. Once those users can run things without admin rights, take the rights away.

[-]

xSchizogenie@reddit

That’s not a technical thing, it’s management. You can - on a technical side - easy take the admin rights away, yeah. But the situation is not solved through this tho.

[-]

duane11583@reddit

i help lead a large 40 person sw engineering team (total engineering is 50% of company 220 peple today) we have very simular problems. dod type contractor - we must comply with cmmc and nist800 rules or loose contracts a company death sentence

on windows we engineer's need probably 30 or so other utilities on our machines the average user does not a huge problem is the lack of it dept responsibility. it runs windows onky they think they have linux but not really we hired our own devops engineer - i bet you have not your mistake. you are paying for this

example: on windows i require the tool “hexedit” and putty or tera term. and a specific version of python. Katie and Mary in accounting do not need these tools. and you are solving their problems nicely you are ignoring engineering needs.

the IT dept sees all users/customers as just another “Katie and Mary in accounting” and stops there. you customer is the entire business, not mary in accounting.

your team will not spend time to put it in to solve the engineering tool problem you are failing to do your job. you could create a sw catalog that users can install but you will not spend the time to do this. a self service solution.

but to do my job i require this tool. and others on my team will need it too. you refuse to,solve the problem. either provide me a way to install it or shut the f up.

interesting problem: at honeywell i was writing usb drivers for a barcode scanner we are in the bug fix cycle. bug found, update driver and redeploy to test team. policy no-one can install drivers period. policy if 5 or more people are blocked it is a priority one ticket. so i was filing priority one tickets about ever hour - the entire test and dev team was blocked! after a week of this i got called into a high level call with corporate IT dept asking questions why this is happening… i explained they went oh shit your group needs to be in another active-directory group.

dont get me started on bluetooth key boards (barcode scanners do that!) the IT VP type was silent when i asked him to write to my VP and tell him we are not allowed to test or develop the critical new “bluetooth barcode scanner” due to corporate policy and it will add another 6 to 12 man months to the development cycle and require an outside contractor we wanted the ability to charge their dept for this addition development cost he quickly fixed the problem

our current approach is this:

you may install anything in the server directory: l:\software\downloaded - it gets vets and copies files into that directory, l:\software\purchased you can also install, l:\software\licensed - requires manager approval and a license /budget charge back to the dept.

that L:\software directory is read only to the world, writable only by it dept.

any thing else is installed you will be fired we audit installed sw weekly. it only takes one or two firings to make it very well understood by the team

we only purchase floating FLEXLM licenses never node lock unless it is for exactly one user. yea they cost more but it is worth it in admin time

we run about 40 or so flexlm servers on a vm

if you (IT) set up the auto installer make damn sure you install *all* features not the bullshit typical ones. my classic example: excell hexadecimal functions where in a special add on package (today they are mainstream) that is not installed by default nobody in accounting needs that but you might think developers will require this

=====

on linux - do this: run a vm server (hyperv works) but build the vm from a script - install *all* packages any user wants on all linux machines universally we use Ansible for this. ie if one user wants emacs install emacs on all machines, not his machine only

i can destroy a vm (I own) in 5 minutes via a script. and it takes 30 minutes to get a new vm (scripted) same with windows vms they run in their own private eng-test domain.

if you do not the engineering community will engineer you out of the equation by using docker and that is worse far worse because you cannot control anything that runs in the docker container

if instead your linux vms must be universally the same and have all features the engineering community will not engineer around and over the top of you

[-]

beached89@reddit

There is nothing developers need that require admin access in theory. Package installs only need user, applications should run in user space. And preventing them from installing software without review is the entire point.

You also can configure applications to run as admin, without giving the user local admin, your 2nd and 3rd bullet point are already solved. See option 1: https://www.tech2geek.net/how-to-run-a-program-as-administrator-for-standard-users-on-windows-11

You will have some dinosaurs who think running as local admin 24/7/365 isnt an issue, but for the most part, people understand the massive security risk it is these days.

[-]

Mechanical_Monk@reddit

without anyone noticing

Lmao I hope this part was click bait. Everyone should know, and everyone should be involved. Whether or not they're pissed at you is their problem, not yours. But if you pull admin rights from something critical and you have no one to point to that signed off on it, then it will be your problem.

[-]

onebit@reddit

idk how i could develop software w/o local admin

[-]

1d0m1n4t3@reddit

Rip out everyone's admin rights today at 4:55pm then call in sick Monday.

[-]

Odd_Environment2269@reddit

We have separate local admin accounts with no licenses for users who need them. The passwords are in a vault and the passwords change every few hours. This meets the security requirements while giving your developers the access they need to install software.

[-]

pdp10@reddit

So now I have a mandate to fix it, a 90 day window

Blame it entirely on the consultant, the report, and any compliance goals. Achieve the 90-day window even at the cost of some bruises.

The majority of the time you won't have any moral backup, so on this occasion when the cause is effectively not you, make sure to take full advantage of that.

You're going to have to work in parallel, and learn a huge amount of technical detail. I'd probably start by making groups for devs and for each of the known-broken-legacy-apps, then drop privs for everyone else immediately, and pick up the pieces concurrently. Then drop privs for the others as possible, before the 90 day deadline.

[-]

Tornado2251@reddit

Thers only one way you will fix it in 90 days. Spend like a month to try to prepare for the smoothest solution you can.

Then make sure management is looped in for the chaos. Then just brace!

Stuff will break and the only workaround thats not 6 months of work will be local admin. Management need to be ready for that.

Or management need to leave some wiggle room by allowing some local admins.

[-]

mini4x@reddit

Or management need to leave some wiggle room by allowing some local admins.

The better solution is to provide an alternate workflow.

[-]

Tornado2251@reddit

Absolutely but that's impossible in 90 days. Long term absolutely.

[-]

mini4x@reddit

It would take less than a week to get an alternative ready. I'd bet 3/4 of them don't need anything anyways, pretty small org.

[-]

Tornado2251@reddit

For most users you could fix an alternative pretty easy. But the long tail is usually long and expensive.

[-]

lordjedi@reddit

Highly doubtful that anyone actually screams once it's gone. Yeah, they'll tell you they need to install something and when they can't, they'll just tell their manager that they can't proceed until IT installs the software (that they probably don't need anyway).

Legacy software probably doesn't need admin either. The program needs to ability to write to a folder, but not actual admin. The trick is finding out where in program files that it's trying to write to. It'll take some time, but it's doable.

But something tells me that you've known about this for a while and just didn't want to do anything about it. You inherited the environment 3 years ago and didn't make any inroads? And now you're freaking out because the board knows due to a security consultant? I inherited a similar mess and had it solved within a year without a security consultant. People complained, but so what? You push all the software they need. Anything else requires an approval process.

[-]

Fallingdamage@reddit

I dealt with this years ago. I began quietly pruning off local admin on workstations in a deliberate 'scream test' approach. One user complaining is an annoying outlier in a department. Many users complaining is an uprising. You start small.

Now, many months/years later, nobody has local admin and nobody thinks twice about it. Things that came from this slow rollout:

Users get used to asking for help elevating credentials for installs. This can be automated as well with various baked in or third party solutions. I never ended up implementing this as the request volume really didnt warrant it.

On the first point, by slowly revoking local admin, I was able to determine what software users were attempting to install. Patterns of product usage and shadow-IT become more clear. This helped me identify broken processes or departments going against standard policy (finding that policy was broken.) As I learned more about how work was being done, I could standardize software deployments across the network. Departments spent less time trying to setup their workstations when they sat down to find everything they needed was there already. The calls for UAC prompt help went way down.

Gaining insight into departmental processes helped build stronger administrative policies on software usage and enforcement. People got used to using what we provide as there are less gaps in their available tools to complain about. If a user is constantly asking for admin access to do something, management or IT will need to figure out why that one particular employee cannot work within our policy and access framework. Most of the time, its not a problem with us, its a problem with a squeaky-wheel employee. Example might be an employee who wants a bunch of strange unapproved clipboard tools or someone who claims foxit is unacceptable and needs adobe. Usually they get told no.

Now our workplace is like any other well run, organized network. You stay in your lane, make proper official requests for things, and the one who doesnt like not having local admin is the outlier, not the majority.

[-]

uptimefordays@reddit

I just switched from a platform engineering role to a software engineering role, Beyond Trust is great for “letting me install stuff” while also not giving me admin rights and logging my use of privileged access on dev devices.

[-]

SpotlessCheetah@reddit

Why do you need to come up with an excuse? Just use the corporate shield.

"We have a security mandate that was brought to our attention and we have to fix it." That's the line. End of story. You're not the bad guy.

[-]

Mrhiddenlotus@reddit

BTW it was always on you to fix

[-]

gnopgnip@reddit

You can make users a local admin on their machine without giving them local admin domain wide

[-]

RiceKrisPSquares@reddit

Threatlocker might help. You can set policies to run certain apps as admin. As a bonus, you'll block anything you dont want running. It can take a while to set up properly, but it works well.

[-]

MyUshanka@reddit

+1 for Threatlocker, once it learns your environment it's really solid. Good for MSPs too

[-]

davietechfl@reddit

Threatlocker early adopter and long-time user, this is the way. It is work but a great platform, great support, great company to work with.

[-]

pistolpete9669@reddit

Worth the money, immediately solves your exact need

[-]

ranhalt@reddit

Threatlocker is great.

[-]

YSFKJDGS@reddit

I've done this across thousands of users, it's not a big deal. 250 users? That was the size of some of the rollout groups lol. Just start with your IT group since they will need the most elevation support, and go from there. Send clear communication and just pay attention and be proactive. Pick 1-2 people in each department to try and get samples of applications, etc.

[-]

1stPeter3-15@reddit

Simply saying "we don't allow local admin" is not a strategy, it's a policy statement. Deploying Intune EPM is not a strategy, it's a tactic. My point being, you're going to likely have a lot of user impact by taking the "let's scramble to fix this in 90 days" approach (its FAST and CHEAP, not GOOD). You're skipping important steps if you want this to be a GOOD long term solution.

So the conversation I would have with my leadership is describing the "Iron Triangle" problem. GOOD, FAST, CHEAP; you get to pick two. GOOD in my opinion is a must, otherwise why bother. FAST is expensive, slow is CHEAP. So your leadership needs to pony up cash for resources to get you GOOD and FAST. Or, give you more time so you can accomplish GOOD and CHEAP.

The only way I've ever seen such an effort work well was when it was done thoughtfully, and with full buy-in from the entire organization. Specifically buy-in from the users that are impacted.

I'd recommend starting with a proof of concept, develop your requirements, understand where Intune EPM works well, where the gaps are, and adjust as you expand the solution out. Start with your own team, then your most trusted customers, who will be willing and candid in testing and feedback.

[-]

Previous-Low4715@reddit

LAPS

[-]

slugshead@reddit

I inherited an environment where every member of staff was added to the local admins group.

When the workstations were all up for replacement, that's when I took the opportunity to review the build and revoke their access.

Nobody noticed.

[-]

D3str0yka@reddit

I was able to fix a lot of „needs to run as admin“ problems with the MS „Application Compatibility Tools“

Don’t know if this is still working tbh

[-]

mighty1993@reddit

Time for a long vacation and a long period of paid sick leave. Hope you live in a country that has proper workers rights.

[-]

CeC-P@reddit

Sounds like you need Autoelevate or BeyondTrust. The implementation is a massive pain but it's not too pricey.

[-]

jmk5151@reddit

You have board approval. Send out an email indicating their was a security audit, one of the findings was too much access, the board requires changes. In the future any installation of software will require a ticket.

Layout the timeline, over communicate, roll it out in phases.

I also agree with threat locker being a good product but you do have to manage it so be prepared for the TCO.

[-]

rswwalker@reddit

Most software will install in user space these days, so full admin rights may not be needed and OP can use AppLocker to control what software users can install. For the few packages that do require admin rights those can be installed using Intune or GPO to the computers where they are needed.

[-]

oldhorsenoteeth@reddit

We used Delinea Privilege Manager. Set a policy to auto elevate if UAC detected and remove admin rights. Audit the auto elevate policy for triggers and use the reports to create and deploy application policies. After two weeks, change the UAC policy to justify so you can catch any left overs. Wait two months and then change UAC policy to approval only. By the end, any application requiring admin rights should be auto elevating. No local admin rights required.

[-]

TemporaryFatGuy@reddit

Autoelevate, put it in audit mode for a few weeks, make rules for the most common occurrences, then enable

[-]

RabidTaquito@reddit

How the shit does a company with a security team have half the company be local admins??

[-]

rack_and_stack_42@reddit

We did this with about 200 users. The discovery phase is the part everyone underestimates.

What worked for us: before pulling any rights, we ran a logging policy for 30 days that captured every time a process triggered a UAC prompt. That gave us a real list of what actually needed elevation vs what people just happened to have admin for but never used. Cut the "unknown apps" list by about 70% because most users were not actually using admin rights for anything specific.

For the devs, we created a separate elevation policy. They got a self-service elevation window (2 hours, logged, auto-reverts) instead of permanent admin. Most of them were fine with it once they realized they could re-elevate without filing a ticket.

The legacy apps that require admin are the real pain. We ended up shimming two of them and just accepting the risk on the third with a documented exception and a quarterly review to check if the vendor has actually fixed it.

The 90 day timeline is tight for 140 users but doable if you batch it by department and start with the groups that are least likely to push back.

[-]

nwr923@reddit

Rip off the band-aid. You might want to update your resume and get that search started first.

[-]

autogyrophilia@reddit

Do yourself a favor and make a plan. Put all users that may be complicated for later, then schedule it so you don't pull from more than 5-10 persons a day.

I assume there is a reason why that was so. You want to identify that as quickly as possibly and see if you can work around that (incompentent devs that can't check for write permissions so they just ask for admin rights ...)

[-]

mini4x@reddit

Sounds like the reason was the previous admin was lazy.

[-]

KeyHalf6609@reddit

You won't be able to do this secretly in the grand scheme of things and you really shouldn't attempt to do it secretly either. It will blow up in your face if you do.

Get someone from leadership to make some kind of announcement/notification to the company, make it so that it towards everyone and not specifically those who currently have local admin. It'll be easier to handle push back if people aren't specifically targeted, those who have admin will know it involves them those who don't won't matter. When it comes time to play the blame game and point to the "bad guy" taking this away I'd recommend insurance or bad actors.

As for actually rolling this out you need to find out everyone who has local admin, which you should hopefully have a list of already post audit. Figure out their departments and then have someone higher up than you reach out to the heads of the department to figure out what they're doing/using that "requires" local admin. Figure out a plan on how to manage those items first, and once you have a plan you do small test groups in each area.

Those test groups will be critical to ironing out the kinks when they inevitably show up. Once things are working smoothly 90% of the time with the test groups start rolling it out to everyone else in slightly larger batches. This will let you iron out any additional kinks that show up until everyone has local admin revoked.

Also, while you're doing this keep track of every software you come across. Regardless if it needs local admin or not, this is going to be a perfect opportunity to update your known software list. It'll also be good prep for the inevitable removal of unapproved software that shouldn't be in your environment.

[-]

mini4x@reddit

We use a combo of LAPS and Admin by Request.

[-]

redit3rd@reddit

Developers need debugging privileges, which still might require being Admin.

[-]

Sad-Offer-8747@reddit

ThreatLocker can help you with that with its elevation control and application whitelisting.

[-]

Aedonr@reddit

Don't do anything unless leadership is behind this decision 100 percent. If leadership is not behind this policy, then your users will riot. Removing admin credentials took our group around 5 years. We phased in new machines/replacementswith new policies "oh, we don't setup admin on new system setups". Work on bolstering managed software offers that will allow users to install the most common software packages on their own .

[-]

Arudinne@reddit

My company was merging with another company when the other company got hit by some bad actors due to every having local admin.

Put a lot of the merger stuff on pause until that was cleaned up. It cost a lot of money and the first things to go was everyone getting local admin and the BYOD policy they had.

[-]

Skinny_que@reddit

Sounds like you need to create an approval process for users getting alt accounts and do a training on when to use it vs your regular account.

Do you all not have a dev environment? It sounds like it’s time to create one

[-]

Calm-Display8373@reddit

We did this with admin by request. I created rules to approve specific vendors via cert and auto approvals for specific network drives where we keep installers. I also deployed base apps via Intune.

Intune EPM had no way to notify of a pending request so we nixed that as a possible solution.

I have ABR integrated with teams so I can approve from my phone on my couch.

Ultimately it seems to have went pretty well. 130 person company running engineering software / Autodesk / Revit / Bentley

[-]

Jaereth@reddit

I also deployed base apps via Intune.

This is a huge part of it too. If your fear is "install requests" and not this old tool must absolutely run as admin - then just automate your installs and you're covered.

[-]

LookExternal3248@reddit

Same here. Good user experience and you can setup many granular policies for different kind of users if you want, auto/pre approve apps if you want etc. Does really remove local admin without getting the management hassle in return.

[-]

moobycow@reddit

Same. No issues at all, even from the devs.

[-]

Jaereth@reddit

Now it's my problem to fix without anyone noticing.

No it's not. Policy needs buy in from management. If management is bought in yes we need to do this then you are following policy.

I've done this before. Just do it slowly (It might be 6 months doesn't mean it's a huge project especially if you already have LAPS in place) because you're gonna find stuff that breaks you need to find workarounds.

Also have the deviation approval framework ALREADY in place before you begin. Absolutely need a local admin account still? Separate account user uses to elevate, 2FA enabled, has to go through an approval workflow with users manager and whoever on the security side depending on how your org is structured.

But the idea you're going to do it "Without anyone noticing" is the wrong paradigm to look at this. IF MANAGEMENT is bought in users are going to need to accept there's a "new way of doing business" and that's that. Don't let them bully you.

[-]

Greerio@reddit

People are going to notice when they can’t sync their clocks any more.

[-]

sheikhyerbouti@reddit

Just chiming in here. There are also ways of setting up local admin access temporarily by using a GPO. I'm not positive of the specifics (that's managed by a different department than me), but how my org sets up local admin is they scan weekly for any user IDs that aren't in a specific GPO, and then remove local admin access if they aren't in it. This allows the users to install updates or new applications without presenting too much of a risk.

[-]

VandyCWG@reddit

My company used to give out local admin access this way. We went to to a product called Admin-by-Request that allows us open admin access for up to an hour. It's logged and you have to provide a reason why.

It's actually not been bad at all. Allows me to update the 2 apps that I use all the time without having to bug IT

[-]

Soft-Hamster2909@reddit

I would just like to say that I went through something like this several years ago. We had several applications that supposedly needed to be run as admin. But I found out that that's not really true in some of the cases. By granting the users full permissions on the program folders, often being an admin is not actually needed. I would recommend testing this. And for the people that actually do need admin rights, a second admin account to run as should work 95% of the time.

[-]

UltraEngine60@reddit

Finance uses software that silently breaks if the user isn't admin.

No... it breaks because it does not have the proper permission. Those audit failures CAN be logged somewhere. Find what permission it needs and give only that permission. I suspect it is writing to some folder or registry key you need to to apply a custom DACL to.

That said, 90 days is untenable unless all your other work drops. I'm sure 784 products will be mentioned in this thread to band-aid it and create a new expense.

[-]

MeetJoan@reddit

Done this at a 400-person shop with a similar mix. The trick that saved us was running a 2-3 week audit phase before removing anything - using Intune EPM in "audit only" mode (or Admin By Request's discovery mode if you end up going that route) to log every elevation request without actually blocking anything. That gave us the real list of what people actually elevate for, not what we guessed they needed.

Developers were the biggest worry and turned out to be the easiest group. Most of what they were running as admin didn't actually need it - it was just habit from having the token. The genuinely admin-required stuff (Docker, WSL setup, specific dev tools) we put in a pre-approved EPM rule set and pushed via Intune. After that, dev tickets dropped to basically zero within a month.

For finance and legacy apps, EPM elevation rules scoped tightly to the specific executable path and publisher cert are the answer. You lose the battle on principle - those apps run as admin — but you win the war because the elevation only happens for that process, not the whole session.

Communication matters more than the technical rollout. We sent a clear "here's what's changing, here's how you request something new, here's who to ping if you get stuck" message a week before, and had a dedicated Teams channel for the first two weeks. People complained way less than we expected because they knew there was a path to get what they needed.

The thing I'd do differently: pilot with the IT team itself first, not a business unit. Eating your own dog food for two weeks surfaces issues you'll never catch in a test group.

[-]

arslearsle@reddit

Do not change ACLs in c root or HKLM registry…never.

Vendor refuse to fix their shitty installer and/or shit show product?

Good luck 😎

[-]

ziobrop@reddit

ive done this,

Give everyone who thinks they need admin a separate admin account. and remove rights from the primary. Monitor that last logon on these accounts and disable them if they havent been used in 60 days.
get ready to package and deploy alot of software. subscribing to something like PatchmyPC will make keeping random stuff uptodate.

Here is my advice on Making applications run without admin rights:

File and Folder Permissions.

Users do not have rights to write to C:\Program Files or C:\Program Files(x86) Folders. Many applications will have a local database or logfile stored with the application. Typically you get a permission Denied, or cant write to file error, rather then a UAC prompt.

In this case, Permission the Applications Folder so the pcname\Users group has modify rights. The Permissions should propagate, down to files and subfolders, and this will clear up your issues. if you have many installs of an application, you can deploy a script to Change the permissions.

To automate this, We simply use a bat file that calls ICACLS. This gets deployed Via SCCM to the System

ICACLS /grant :(OI)(CI)M

The options at the end Specify

(OI) - object inherit

(CI) - container inherit

M- Modify

So the command ends up looking like:

ICACLS "C:\Program Files (x86)\PFC6000" /grant Users:(OI)(CI)M

Full ICACLS documentation can be found on technet. Always use the local group - frequent calls to AD for application permissions can slow the system down.

** I recently encountered an application that required users to have Read and Write permissions to its registry Hive. this is where the app stored config, and needed to be set by the user.

AppCompatFlags

Some Applications can be flagged in the registry to run in compatibility mode. You can use AppCompat Flags to specify an application to run in XP mode, and require admin access. Just because an application prompts for admin, doesnt mean it Requires it.

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers

Simply deleting the key can cause the application to work. I have also seen this key below used, though much less commonly.

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers

Manifest Files

EXE's can use a manifest file to require an application to run as admin. The manifest file will be found with the EXE, and will be the name of the exe with the .manifest extension. So notepad.exe would have notepad.exe.manifest.

and example manifest file is shown below:

<assemblyIdentity version="1.0.0.0"

processorArchitecture="X86"

name="Myobp.exe"

type="win32" />

Manifest for Premier

<requestedExecutionLevel

level="RUNASADMIN"

uiAccess="false"/>

I have had luck simply deleting the file, though manifest files can also point to older versions of DLL's. In that case, You may have better luck replacing RUNASADMIN with ASINVOKER

4.Invoke Installer

The UAC can be prompted if it thinks you are about to run an installer. You may or may not be running one, but if the following conditions apply, you will get prompted.

(From: http://msdn.microsoft.com/en-us/library/aa905330.aspx)

Installer Detection only applies to:

32 bit executables

Applications without a requestedExecutionLevel

Interactive processes running as a Standard User with UAC enabled

Before a 32 bit process is created, the following attributes are checked to determine whether it is an installer:

Filename includes keywords such as "install," "setup," and "update."

Keywords in the following Versioning Resource fields: Vendor, Company Name, Product Name, File Description, Original Filename, Internal Name, and Export Name.

Keywords in the side-by-side application manifest embedded in the executable.

Keywords in specific StringTable entries linked in the executable.

Key attributes in the resource file data linked in the executable.

Targeted sequences of bytes within the executable.

Note: The keywords and sequences of bytes were derived from common characteristics observed from various installer technologies.

You can turn off Installer Detection by modifying the EnableInstallerDetection Registry Key

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

and setting the value from 1 to 0.

This Can also be done Via GPO enterprise wide. The UAC Policies can be found in Computer Settings\Policies\Window Settings\Security Settings\Local Policies\Security Options

The User Account Control: Detect application installations and prompt for elevation policy setting controls the behavior of application installation detection for the computer.

The options are:

Enabled. (Default for home) When an application installation package is detected that requires elevation of privilege, the user is prompted to enter an administrative user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.

Disabled. (Default for enterprise) Application installation packages are not detected and prompted for elevation. Enterprises that are running standard user desktops and use delegated installation technologies such as Group Policy Software Installation or Systems Management Server (SMS) should disable this policy setting. In this case, installer detection is unnecessary.

Application Compatibility Tool Kit.

Pending - Please see TechRepublic Article @ http://www.techrepublic.com/blog/windows-and-office/selectively-disable-uac-for-your-trusted-vista-applications/

[-]

theMightBoop@reddit

As others have said you need management buy in. Work on a communication plan and be sure management is going to back you.

You are not these people’s boss. So you saying this needs to get done is ignored. The CIO or whoever is, so then saying this carries weight.

Then identify the developers and the apps that need admin access. Get their management to write a justification.

Then do the people who have no justification. Get their management low hanging fruit.

The apps, look into moving them to a VM or cloud solution. Odds are if they are running some program in their local computer that needs admin access it’s old and a security risk anyway. If they claim it’s vital then running it locally is a vulnerability and a single point of failure. So you frame it that way. Document it all. When they tell you they can’t move it, get a justification. Then you write up why it’s a vulnerability as is. Get the cost of changing it. Then you get management to agree to the vulnerability or they upgrade. You covered either way.

I had this entire back and forth on some software that “we can’t upgrade to win11.” When I pushed and investigated it required a new license for the upgraded version which was $150. Not every problem is that easy but at least investigate and document.

Developers will be harder but it sounds like you have the solution. They just need buy in.

[-]

britannicker@reddit

Perfect answer right here.

[-]

idontknowlikeapuma@reddit

Vlans. Do the devs need access to HR data? HR loves a computer issue, because then they can’t work, so they can piss off with an excuse to chat with the accounts manager, accountant, and receptionist.

Block the devs into their own vlan. Done and done. Just make sure you don’t have bleed points. Know your ports.

[-]

brispower@reddit

So you've had three years to fix this?

[-]

Sylogz@reddit

We had the same. We made a exception/accepted the risk for developers. they still have local admin accounts but the others was all removed.
It has not been a big issue at all, we have almost all software in software center. The regular users can install from there.

[-]

-GenlyAI-@reddit

Oh another marketing question. That's all this sub is anymore. Helpdesk employees complaining and marketing disguised as legitimate questions.

[-]

phobug@reddit

Dude, ask for 6 months project to complete this. If they say no tell them to do it themselves in 90 days.

[-]

PanicAdmin@reddit

"by management request we are revoking your admin right. for any enquiry please refer to manager@managed.com, we won't answer to any e-mail."

[-]

The_Wkwied@reddit

Agree with the others. Don't do a scream test. Don't do anything at all without leadership backing you.

If you do, and leadership doesn't have your back, you're shooting yourself in the face.

You will create new problems solving this problem. That's a fact. You're likely not going to have the tools to work on those new problems, because they are not IT. Keren complaining about not being able to run notefotenotepad.exe will be the least of your worries, when they start to complain to leadership that you are blocking them from your job.

Users (and devs) don't care about your reasons. They care about their workflow. No matter the task, when IT makes it harder to do something, IT is the bad guy. Even if they admitted to getting phished, if you pull their PC to investigate their hack, you're the bad guy.

Get leadership to back you, else your career ship is heading to an iceberg. Even if you don't sink, you'll take a grazing blow

[-]

BadSausageFactory@reddit

At some point, fuck the users. Get management behind you and security pushing them and this is not your call.

The problem you will have is every middle manager 'going to bat' for their team, meaning they want to be special. I have a bunch of Mac users now that are about to lose their elevated privilege button because the department head decided to have them all install some AI tool without running it by legal or reading the fine print. Before I do this, the CEO will have a talk with that person. THEN they will all lose access to the tool but I won't have to hear the arguments because it's very clear it came from above me.

[-]

Superb_Raccoon@reddit

Get everyone a Mac.

Yes, they will notice, but they will like it.

[-]

Yake404@reddit

Cautionary tale incoming. I walked into a situation very similar to yours. Almost EVERYONE was a local admin on their machines for the same reasons you listed above. Voiced my opinion about this a few time and was brushed aside.

Two years ago we got hit with a wicked ransomware attack from a group in Belarus. Thankfully between our cyberinsurance policy holder bringing in a remediation team and our solid backups we only lost about two weeks of business (with my team working long hours) but the #1 reason the RW spread the way that it did was because of all the local admins. They basically had unlimited lateral movement. From that point on the C-suite basically gave us everything we had been asking for. Better EDR/XDR, better monitoring tools, but the most overlooked thing they gave us is teeth in policy pushing for things like the local admin change you are suggesting.

[-]

reol7x@reddit

You need a PAM solution to handle elevation requests... If it's too expensive for everyone, just license the dev users and those that need it the most.

Another tip regarding your software that 'needs' admin rights, we've found that with our vendors...it's usually because it needs to write files as a user to a protected folder, like program files/terrible app and giving "users" full control over said folder often allows it to work.

Is it a great idea? Not the best, my ut it's better than full admin or it mitigates that issue.

[-]

ethnicman1971@reddit

For those situations where the fallout is too great determine what possible compensating controls can be put in place that will satisfy both the community and the security team. If not satisfy at least less mad :)

[-]

xampl9@reddit

Developers have a legit need. But also a higher expectation of not going to sketchy sites and installing malware.

There should be a policy on the dev management side that “you screw up, you’ll need a really good reason for us not to fire you”

[-]

thedizzle999@reddit

100%. As a dev all these nonsense approvals to install software I wrote and signed with our company’s cert is beyond ridiculous. So I cloned my crappy W11 laptop and now I run it as a VM inside my Linux laptop. I don’t really need much on the domain anyway beyond pulling some files every now and then from an internal repo. So now, I just test our SW on another W11 VM (or in docker for server apps). Our local IT folks are aware and amused by this. They’ve even asked me how I cloned/run it. 😂.

I do not have time to open a ticket every time I need to rebuild/install/test something. Our tickets go to a non native English speaking helpdesk who has no power to approve, they have to forward it to somewhere else and all this takes days. Our local IT has been effectively neutered. I filed a ticket to have our SW signing cert added to the Approved list and it was declined (after 30 days…). I’m not even kidding.

It doesn’t have to be that way, but unfortunately it is. Fortune 500 companies have outsourced so many things it’s like pulling teeth to get anything from corporate IT.

To be clear, I don’t blame IT for this bureaucracy, I blame our mgmt who decided to outsource everything which adds sooo much more overhead for us little people. I get it that Joe in Sales clicks on every phishing emails…but not all of us are “Joe”. I don’t click on phishing emails, I don’t run crapware, let me do my job.

I realize I probably won’t make friends on this sub with this view, but I’ve been on the other side too, so I know the struggle.

[-]

LadyPerditija@reddit

Maybe an intermediate solution would be to create a second user with admin privileges for those who need it, so they can always run their stuff as admin. Revoke the admin privileges from their normal users with which they log in to their devices and do their other day-to-day tasks (nobody needs an admin user for editing an excel sheet). That way the use of admin users is at least greatly reduced. Then go from there.

[-]

StaffOfDoom@reddit

You use that 90-day mandate to just shove it down the throats of everyone, frame it as you’re stuck and in the same boat as everyone else. You’re not the heavy-handed enforcer, you’re the unwilling pawn, play it up. Agree how horrible this all is as you take away admin, promise you hate it too, encourage them that you understand.

As for the apps that don’t work, beat management over the head with every broken request ticket, remind them at every turn this was their fault. Be the advocate for the masses, but don’t push it too hard.

[-]

SVD_NL@reddit

I'd leave the devs for last, and put their management to work, making them provide a list of software, or coming up with a solution that doesn't require admin rights (build servers, containerized development, etc.). For PEM, make them responsible for admin access requests. This will be so annoying they're basically forced to do a good job with software inventory.
No matter how you go about this, you'll need buy-in from the dev department, and you'll likely need more than the alotted time. Check the mandate, maybe it's enough if you have a solid plan before the deadline.

As for collecting software inventory: maybe you can use Defender advanced hunting to pull process creation events, and parse the processes starting as admin. Or use some other log collection process. It starts with solid software inventory, there's a bunch of methods for that. Anything that isn't legacy likely won't need admin permissions, so i wouldn't worry about things breaking on the shadow IT side.

And start small. One or two users per department, slowly expand the scope.

[-]

RNSD1@reddit

Threatlocker is the way.