Admin Rights Justification

[landon_Starr]

Hi all,

I was hoping you could share your experiences in regards to allowing your user base to have full admin rights on their machines. I've had experience with both sides of the coin, but I know companies like IBM like to tout that they give their users full control, while others tend to lock them down completely.

I know admin rights can be a slippery slope, so I'm excited to hear your input!

[Chuey]

I don't see the point. We manage all the software distribution and self service. Certain things that need admin rights that I want to over ride like date/time, printers, setting DVD Regions, etc. I find a defaults write command to allow and apply it to their machines.

When I started at my current job with over 2,000 employees and they had admin rights -- it was insane the amount of malware, PUPs, etc that were installed that Virus Scanner did not catch. I have since migrated to a new Virus Scanner solution that helps but the first thing I did was remove admin privileges and have had no issues.

We created processes for users to request software and works well.

[Captainamerica]

With all the latest changes Apple have in their OS, it moves in direction that users must have admin rights like it or not.

Typically these kind of "non admins" views comes from Windows companies that are used to have non rights "and that is how it should be" politics without knowing the difference from windows to MAC

Block all untrusted applications on Mac through gatekeeper, use SIP and look to more advanced antivirus solution on company network, that can lock computers out of the network connection if malware/virus is detected on a client. With admins rights or not users can still download from Appstore, which is typically why windows users have removed their access so nothing is installed. But for Mac it does not change anything as App Store is still open

As also many other write in similar topics, if users cannot behave with admins rights there are other problems that should be solved internally. I have been macadmin for 10 years or there about, and think I have seen couple of malware on Mac´s even without we have super educated users at all.

But of course are you working in a super security area like Bank etc admin rights are probably difficult to enable, as then security is just something you have to enable without even looking at the pros and cons

[tomhastings]

In a previous job we changed all users to Admin because of a request that "came from above". The network and firewalls were secure enough and we did have a team that provided constant monitoring. We did create a policy that all agreed upon; any Mac with spyware, malware, unauthorized apps, etc. that was discovered would be wiped and the user was then demoted to non-admin. This policy opens the door to better end user education on the risks and in the end, worked out quite well.

[rhoward]

I think it depends on your environment. Being a quaker school we are more lenient due to the cultural values of the school. We have tons of users that want to use Spotify, Google File Stream, and other free apps. We just have them sign a policy that says they will not install torrent clients and other inappropriate applications. We also use the restricted software to blacklist things we know are bad/common ones that people abuse, Epic Games for Fortnite (yes people still think playing games on their work issued computer is ok), MacKeeper, etc.

In a more corporate structure, it makes sense to see how much you can limit for liability purposes. When in doubt, I think having a written policy as part of employment obligations is a great way get halfway there.

[gmendez]

From a pure IT Security perspective no matter the OS, users doing their everyday work with a account with admin rights is a bad thing. Accounts with Admin Rights are an open door for an assortment of malicious activities into what is supposed to be a secured corporate environment. If a user needs admin rights, they should be given a separate account with admin rights to be used only when necessary. Otherwise, you do your day to day work with an account without admin rights.

[nmanager]

When I started at my current job all staff had admin rights. We had multiple tickets a day of various performance issues, errors and virus related issues. The current model was to re-image every year, basically to clean up the machines and get them working again. Without telling anyone we removed admin rights at the next re-image. Since then the number of support tickets has dropped significantly and the user experience is much better. The most telling thing for me was most people didn't even notice they didn't have admin rights and even when we informed them overall they were ok with it since the user experience was so much better. No more slow or buggy machines, they just worked. To me the user experience is the most important thing and the only way to guarantee that is to limit whats installed on the machine. Any software that the staff would be installing most likely wont be coming from a big company (there is a reason its free) and who know what R&D they have done to make sure it works correctly with other applications. If you pair that with Self Service and the App Store I just can't see why to give them admin rights.

[damienbarrett]

I've written about this several times and have even presented at JNUC and PSU MacAdmins about how my school deals with this issue. All of our students are administrators on their Macs -- and here is the justification.

Similar to @tomhastings and @rhoward , we use administrative rights as an educational lever for our students. Before being allowed to be admins, each must take and pass a technology "Drivers Test" that we have created. They must prove they know about our AUP and what's in it, as well as knowing how to do basic management tasks like running software updates and avoiding malware and adware.

Is it perfect? No, of course not. I still have lots of students ignore the software update prompts and even more that believe MacKeeper is worthwhile software to install. However, the good still outweighs the bad here. For every student who doesn't fully understand basic stewardship of their computer, there is another who does. And every one of those is one more person in our world using computers successfully and competently. It's my opinion that locking down the computers and doing all the maintenance tasks for all users teaches the users nothing.

[gmendez]

@damienbarrett Your situation sounds great for an academic environment, but the potential risk for a loss to business in a corporate environment is too high. Not to mention, every trouble ticket opened represents an overhead cost, and loss of productivity to the company. There isn't much room for altruism in the corporate computing environment when money is at stake.

[maurits]

@gmendez If you mention tickets as 'costs' please do not overlook the fact that co-workers who have trouble doing their work, and spend hours to bypass the locked-down system are (hidden) costs too.
In general I feel that giving trust to users by making them admin is usually rewarded with good behaviour, and happy users, but all depends on the kind of users and the environment.

[Eyoung]

admin at a school (1-2-1 macbook airs, grades 5-12). So this is from that perspective.

The kids are an easy no admin. Worked very hard to develop the Self Service culture. That combined with Google makes for pretty smooth running overall. I work with individuals who would benefit from being admin (development projects, internships, etc..), its worked out on a limited basis, case by case with written rules governing do's and don'ts

The adult population is where this gets interesting (interesting in the broadest sense at any rate)

I have a completely mobile adult population as well. The IT director mandated all adults be admins on their own laptop from day one when we swapped over from a shared environment. A large percentage of the population then began the never ending upgrading of Flash because, well I never really understood why perfectly sane looking people feel the need to install EVERYTHING the interewebs puts in front of you... but I digress. Malware, unlicensed software, general instability reigned.

Over the years I have quietly demoted adults to standard users, beginning with the offenders, especially repeat offenders. If I have to have the malware talk with you more than once you get a standard account. This goes back to building out Self service to meet needs.

Now the standard is to make all adults a standard user by default. Those in the know, who are generally responsible/savvy enough are gladly promoted to admin if requested. I like to think I reserve the right to take that privilege away but who am I kidding. Overall, those who get the promotion do fine, and find the added benefits worth it, with little to no overhead on my part supporting them. This pool of local admins is a small handful of people. The majority of the clients do not feel the pinch at all. They know to go to Self service for the odds and ends. I've had a goodly portion express to me that they are quite content to not have to worry about "messing up" their machines unwittingly. It makes the experience easier for them so they can get the tool out of the way of the work.

[jhuls]

Admin at a community college here with about 160 Macs and 190 iPads. I'm full-time and just got a part-time person to help with things. We also have 5 full-time people each with 2-4 part-time people to handle about 3000 pc's. That is for desktop support only. I mention these numbers as the difference between having and not having admin on systems affects the strain from the amount of work that needs done. Admin access requires more resources.

Having said that a little background...we've had a number of cultural battles here over the years on this. I've been here for 21 years now and have served both Mac and Windows systems. We are currently locking down all student systems to no longer have admin. This wasn't always the case as some techs refused to invest in it because their rationale was that they could just put Deep Freeze on a system to keep it cleaned up. With newer OS's on both platforms Deep Freeze proved to not be reliable for the pace we were trying to achieve with upgrades. Either way I've never been a fan of it because it seems to always get in the way so I've ditched it in each area that I've supported and removed admin access. Keep in mind I'm talking about lab and classroom machines. Interesting enough my calls always go down in the labs when doing this. Removing admin privileges from students is more about protecting the system and ensuring the operation of them for classes since more than one student uses them. The only machines we have for students that I know of that are single user operated as those that our library lends out and I believe those are provided admin access. In those situations the student takes responsibility for their own operations. Labs and classrooms are locked down though.

With our faculty and staff we're still allowing them to have admin privileges and I don't know if that will ever change. Our president believes they all should have it while our CIO opposes it. Like I said we have cultural battles here. Some feel that there isn't any freedom if admin is removed(translation...I want my Spotify and games). Some feel that it's a waste of time to wait for us to install something that they could just easily do themselves. Some need to test software and that's where I admit that there are some who really do need some sort of access like so. As usual a blanket policy doesn't work well. For now though they all get admin. There are a few who we've tested removing admin from their systems and in each case calls went down drastically. Not only were there not calls about true problem issues but very little about needing to install anything.

There are arguments that sound good regarding keeping admin rights and in some cases I believe it really can work in the right scenario but I firmly believe that with a good evaluation of the situation, that most times removing them is going to be in everyone's best interests if you have to go with a blanket policy.

Keep in mind one avenue to explore for Macs anyways would be to provide admin on demand. Such a solution would have a user give themselves admin access for a set amount of time by clicking an icon in Self Service. There have been some here and elsewhere that have done this. I would love to do that here on our campus as I think it would help as a compromise but as of yet the Windows side doesn't know of a way to do this and the powers that be would like to keep both platforms similar in this regard.

As for those that say Apple is pushing in the direction that users need admin rights I would firmly argue against that. To me it seems easier than ever and this goes for Windows as well. If you're running into situations where admin solves an operational issue, I would ask if you're not putting the correct resources into dealing with the issue. Removing admin comes at a cost but so does providing admin access and then there are ethics and liability arguments that can come into play.

At any rate this question will probably rage on for decades.

[marklamont]

Shared machine users are not admins, so they can't mess it up for everyone else. Single user devices users are, if they break they soon learn when it either gets wiped to reset it or they spend quite while getting it fixed. That said we make sure they get updated, control OS version upgrades and blow crap such as mackeeper away by policies.

[Hugonaut]

All users are Non Admins - We have a self service script that grants users Admin Rights when they need them. Times out and makes them Standard user after a given amount of time.

[Chuey]

@landon_Starr @Captainamerica @damienbarrett If you are security certified and/or a security professional you know that the most basic and fundamental concepts taught is least permissions. Which means users should only be given sufficient permissions to do their job. Permissions beyond that is considered permission issue that could lead to access violation. In my opinion as a security professional and systems administrator -- giving someone admin rights to "educate" them is not an exception -- it is our job to ensure the network and all client machines are secure at all times. No one outside of the tech department should have credentials to administer anything. @rhoward With MDM solutions that allow white listing apps, kext approvals, self service, etc. admin is not necessary. People want Spotify, Google File Stream, Dropbox...put it in self service. @tomhastings If you are solely relying on your firewall and network you are not adhering to the concept of defense in depth when it comes to Security in IT. I understand when it comes from top down sometimes you have no option but at that point I would have built a case and stated why that's a bad idea.

[Seven]

I took a bunch of the "admin granting" tools from various sources on the forum and combined them in to one.

What we can do is allow users to elevate to admin level privileges for a specific amount of time. For example: for X minutes or permanently.

This works well because you can tie it to the needs of different user groups. Perhaps engineers need it for 4 hours while executive admins need it for just 15 minutes.

[rhoward]

While what you are saying is true, with a limited budget/staffing I manage 1000+ users and 1500+ Macs & iOS devices with just one other employee. The amount of time it takes to create packages, deal with specific requests for apps, etc doesn’t make sense for us to do this route for teachers. Now for our administration and staff that deal with financial records, student/business data, all of that lives on shares or things that require authentication using AD, Google or other sources that are cloud based. We have to do this for COPPA and many other compliances. We prevent data from being moved outside these parameters.

Again what I said goes back to knowing your culture/environment. When I was working for Apple, it was locked down (and for good reason) because that is the culture. Teachers who experiment with lessons and software regularly make it outside of our general ability to have it as strict as possible.

[milesleacy]

@gmendez In what way does a user with a local administrative account on macOS expose a company to a greater risk of data loss than a user with a standard account?

[donmontalvo]

+1 to @Chuey and @gmendez.

I've only ever managed Macs at large publicly traded companies, where disruptions/outages can cost a company a lot of money.

In our space, it is very rare that a user would need admin rights, but that's what the review process is for, protect the Firm, and enable the user.

Apple has a position that they market, because their audience is mom and dad.

Enterprise has a position that mandates protecting shareholder confidence and share price.

So there's more to the issue than security breaches, or data loss.

Although if my mom was a famous actress, I might risk giving all my users admin rights and not running anti malware software, since I know if I get fired I'll have a cushy job waiting for me.

The rest of us need to be employable and marketable, so unnecessary risk, or keeping up with the Joneses isn't a very smart option.

With all that said, to each his/her own, as everyone has to deal with a different set of responsibilities, different requirements, etc.

[mark_mahabir]

All our users (the large majority of which are academic staff) are non-admin by default, but they can request a local administrator account via an online form if they need to be able to say, develop software or install packages when off the campus network.

For many years our Macs were self-managed, so when folks were migrated to our managed service they often got admin rights without too much justification. New users need to supply a few lines of justification, but we will grant those rights more often than not.

[Chuey]

@milesleacy I can already think of 10 scenarios off the top of my head. That could not only put the company at risk but the users personal life.

From an ethical hacker, sys admin, and security professional mindset ....... hearing people say things like "why does it matter? What can possibly go wrong?" is exactly why companies suffer data breaches, peoples identities get stolen, bank accounts drained, etc.

Does everyone forget the weakest link to any organization? The end user.

[damienbarrett]

@Chuey None of your arguments are invalid or illegitimate. And you make some great points about protecting data and enhancing security. But I still believe that it's better to teach a person to fish rather than just giving him/her a fish when hungry. The more people we train to be good stewards of the technology they use, the better off everyone is. Arbitrarily locking down environments only teaches people that someone else will be responsible for applying security updates or protecting against malware and adware. I prefer to place the onus on the end-users and give them the tools and knowledge to manage their own systems.

As others have pointed out, this does not work in every environment. In mine, it does. Every day, I spend time showing users how to enable Flash for websites, how to apply security updates, how to see their uptime, how to manage their file systems, how to update their browsers, how to use password managers, and more. Every time, I know that it's one more person in the world better equipped for when they go to the Apple Store or the Microsoft store and buy their computer, set it up, and the account they create is an Admin account. Until the OS manufacturers start leaning away from this default model (not likely), I will keep doing this. It's a better paradigm, for a better world. I guess I prefer to be altruistic, not draconian. Positive instead of paranoid. Take it as you wish. I am pleased there are people out there very concerned about security. Everyone, including me and my user base, relies on you and other security researchers to help alert us to threats, around which we can educate and inform (and for some, immediately apply patches). The weakest link in any organization is indeed the end user. I work hard to make my users stronger computer users.

[milesleacy]

@Chuey Don't get me wrong, I fully understand that risk exists.

My question is how does having or not having a local administrative account on macOS affect risk?

What company or personal data is placed at greater risk when the user has an administrative account instead of a standard account?

I would argue that local administrative privileges have minor to no effect on the risk of data loss. For example:

- I can just as easily be phished when I have a standard account as I can when I have an administrative account.

- Local administrative privileges on my Mac do not grant any elevated access to data sources. If I am a bad actor and my macOS account is a standard account, and I have access to a sensitive data source, I can still leak that data. Having or not having local administrative privileges does not help or hinder my ability to exfil the data.

- With management tools like Jamf Pro, I can detect and take action when suspicious activity occurs.

- I can detect installs of undesired software or removal of required security tools or settings.

- Through 'compliance' smart grouping and/or complementary tools such as MS InTune, I can revoke access to sensitive apps/networks/etc. when a device is altered into an unacceptable state.

On the other hand, not having administrative privileges represents a major hit to UX & productivity and a significantly increased workload for IT.

This calls for a real cost/benefit analysis. Each org may come to different answers in that evaluation. However, I do argue that in general, local macOS administrative privileges in themselves do not introduce major risk.

[jhuls]

@milesleacy I think context matters for much of this like how a system is managed and what policies exist regarding use and administration of said machine.

At a technical level though...in my environment we have several multiuser systems...most are lab and classroom systems as I work at a community college but we also have some office systems like this. Based on the class I took that I believe you taught in New York(awesome class btw if that was you), I'm quite sure you know that in having admin you then can invoke sudo and su as well as enable root. That ability alone can be dangerous for other users on the same machine. A few years ago I thought I would test whether I could, as a local admin, be able to access a mounted share by another user already logged in while fast user switching was enabled. It was incredibly easy to access. I was able to access that user's mounted Windows server file share and anything I did to a file appeared as if that user had done it. I'll admit I haven't tried this since then so maybe Apple has addressed this but my CIO was none too pleased to see how easy it was.

Several years ago before DEP was completely implemented we had users who would receive their system fully configured and then wipe it..."in the name of educating themselves how to install the OS and support it themself"...translation..."I want what I want and do what I want to do no matter how it impacts anyone else". It was pretty laughable because we regularly had to support them and routinely found things on the system that should not be there and caused their very problems. So much for remotely accessing inventory of anything about the machine with Jamf which was exactly one of the goals for some.

Basically part of the argument is that for any access you give, certain users can and will find a way to exploit it and that can take many forms with various degrees of impact. This then affects cost of support which then impacts cost to the company or institution. The overhead of just removing admin for most users is much less in most cases than managing every possible tool to monitor and fix systems that just might have the same overall impact in the end.

Lastly, I've actually found the exact opposite in that these days most people can get by just fine as a standard user. Not everyone as different jobs have different needs and that also goes back to why I was talking about context. The key, to me, is can the user get their work done? If it can be justified that they need admin then it has to happen; otherwise, admin should not be provided until that time.

[Chuey]

@milesleacy

I would argue that local administrative privileges have minor to no effect on the risk of data loss.

That's a very bold statement -- You better go watch David Kennedy and see what he has to say about this very topic in InfoSec.

If you cannot think of what risks are associated with having this type of elevated access on a production network -- I can't help you.

But maybe a few of these will:

You Can remove local admin rights
Why to disable local admin on Servers
Why you should remove local admin
Reclaiming the Keys to the Kingdom in Higher Ed

[rhoward]

@Chuey all of those articles are still subjective to culture/environment and mostly reflect a Windows mentality. MacOS isn't built the same, it's primary function is to be a consumer device, not an enterprise device. We apply permissions on network shares and Windows machines very differently than we do on our Macs because of this. And with almost all of our systems (Google, Blackbaud, Citrix Remote Access, etc) are cloud based, actual business data doesn't live on the machine. If someone gets malware, our Cisco ISE takes it off wifi and notifies us. If a user installs applications that break our responsible use policy, they're removed right away using JAMF and we're notified.

The practice of keeping data safe and having good access control is something everyone should do. As @milesleacy said, data can be leaked even if you aren't a local admin. Once we gave our users local admin access, our ticket requests were cut in half.

Again, your environment/culture matters.

[milesleacy]

@Chuey

elevated access on a production network

As you mentioned, context is key. This, I believe is the key piece.

An administrative account on macOS ≠ elevated network access.

If the two are linked in a vulnerable fashion, as can happen in some AD bound scenarios, then there can be (but is not in itself) valid cause for the conflation. This is one of the many reasons that I strongly advise against AD bind.

Device is not the same as network, application, or data source. In this type of discussion, many conflate these. I hold that it is not the device’s job to make up for poor security/workflow in a network, application, or data source. Proper access controls, auditing, and behavioral modeling can prevent and/or identify undesirable behavior and access to sensitive applications and data.

For example: If one has a good personal security posture, one accesses internet banking with multi-factor authentication. The banking data and the bank’s web app do not reside on the device. So long as one has reasonable certainty of the device’s privacy (we should have a high level of certainty in privacy on Apple devices), the risk is minimal regardless of device used. Further, and to the point of the thread, that risk is not affected by the presence or absence of an administrative account.

This all assumes a 1:1 deployment. The threat model is absolutely different in a shared computer context.

In a rough sketch, without examining particular workflows or needs, some options that come to mind for a shared computer model:
- Don’t use shared computers for sensitive operations/data.
- Users do not get administrative accounts on shared computers.
- Don’t have persistent end user accounts or data on shared computers. What does not exist cannot be compromised. A “guest-only” model.

[Chuey]

@milesleacy

An administrative account on macOS ≠ elevated network access.

LOL, I was not saying because you have admin rights on a macOS device means you have elevated network access. I understand how it works and I believe my statement was mis-interpreted.

I'm network certified, security certified, data center certified, ACMT certified, and the list can go on.

My point is -- your reasoning is only justifying why you hand out admin rights. Based on culture, environment, educating, etc. Also, this isn't a "windows" mentality thing. It's a "security" mentality @rhoward . . . I keep hearing that and operating systems are not boundaries in InfoSec.

If you hand out admin rights that's fine -- but justifying it with your reasoning doesn't make it right.

It's not wrong because I say it's wrong.....It's wrong because it doesn't follow basic Information Security protocols and guidelines. Simple as that. I've read the books. Taken the certifications. Attended the conferences. Least permissions is all I can say.

Like @donmontalvo said

...to each his/her own, as everyone has to deal with a different set of responsibilities, different requirements, etc.

All I'm trying to do is let OP @landon_Starr know that he should not hand out administrative rights on his macOS devices based on Security Protocols and Guidelines in the InfoSec world. Especially if he wants to help mitigate risk everywhere he can. Just because you do it over there and he does it over here ... you have all these justifications on why ... doesn't make it right.

That's all.

[milesleacy]

operating systems are not boundaries in InfoSec

Perhaps, but fact must apply. I’m left to wonder if the argument against administrative accounts would have legs if group 80 had a different label.

admin@macOS ≠ admin@Windows I think everybody agrees there. But admin@macOSMojave isn’t even as powerful as admin@macOSEarlierVersions.

With recent versions of macOS and Mac hardware, even root isn’t really what most people understand root to be any longer.

In an MDM-managed fleet, MDM is the only “true admin” by traditional “administrative” capabilities.

hand out admin rights

It’s not a matter of granting. It’s a matter of not interfering with defaults.

Least permission is a great tenet of infosec. So is usability. The primary use cases that Apple and other major vendors such as Adobe provide assume an administrative account is used. Modifying this default and the expectations of vendor workflows and user experience to revoke administrative privileges has a high usability cost.

I have yet to see a threat that local administrative accounts introduce and isn’t mitigated by compensating controls, either built-in to macOS or implemented as part of best-practice deployment strategies (for non-exhaustive example: Gatekeeper, SIP, Secure Boot, MDM, 3rd party security tools). I’m not saying such a threat doesn’t exist or couldn’t in the future, just that I have not seen one presented here or elsewhere.

This leads me to the decision point of: “Is the degradation in usability associated with loss of administrative accounts an acceptable cost to provide a theoretical benefit that cannot be quantified in practice?”

[ChrisMike]

As a Mac administrator and a certified security professional, I definitely agree with @Chuey and @jhuls , they make some fantastic points. @milesleacy I would like to address the following point, "What company or personal data is placed at greater risk when the user has an administrative account instead of a standard account?"

When a user has administrative right to their account, that obviously gives them the ability to install third party applications at will. This also makes them susceptible of installing malware and viruses. Threats like Remote Access Trojans, Keyloggers, and remote backdoors can all lead to data leaks on client machines that go unrecognized by the user. Many of these threats even operate at a level where they are unnoticed not only the user or support staff, but by the computer's antivirus or MDM. Down the road these threats can lead to network breaches or larger security concerns. Sure, you can do your best to blacklist or restrict the software installed on the computer, but thousands of new threats are surfacing daily.

The concept of least permissions is not a suggestion, but more a standard for protecting your data, end users, and organization.

[donmontalvo]

@ChrisMike wrote:

When a user has administrative right to their account, that obviously gives them the ability to install third party applications at will.

This opens the door to interoperability and compatibility issues can result in critical deadlines being missed.

Missing a critical deadline can be quite costly to the company.

Giving a user admin rights increases risk beyond data loss and access.

[milesleacy]

install third party applications at will. This also makes them susceptible of installing malware and viruses.

The compensating controls for user-installed software are Gatekeeper and code signing, the built-in malware protection in macOS, SIP, T2, and any 3rd-party product(s) the organization may be using.

So what if someone can install Angry Birds? Apple have provided systems, tools, and a platform that can give us confidence that, so long as we retain and enforce defaults, that they can only install software from reputable sources, and If a bad actor sneaks in, the system is well protected and Apple have a kill switch. All of this is before we add any 3rd-party tools that may provide additional intelligence, protection, and response options.

Anyone who has worked with a DISA STIG knows that implementing every recommendation in the STIG will likely result in an unusable system. An organization must take these lists of ‘most secure states’ of each feature and setting and decide which are necessary in a given deployment and which represent necessary or acceptable risks given the nature of the work to be done on that system.

We als need to consider duplicate controls. If we have, for the sake of argument, ten controls against a particular threat, but each of those controls inflicts a 10% usability cost, simple math says we can’t use all ten. So how many do we use? Is two too few? Is seven too many? This is the conversation and decision each organization must make.

Least permission, on its own, is a desirable ideal. It must be weighed and considered as part of a well-reasoned security posture, not dogmatically adhered to regardless of impact and compensating controls.

I’m not telling anyone what their organization’s position on administrative accounts ought to be. I am saying that coming up with that position requires a thorough examination of real factors rather than dogmatic adherence to an abstract ideal. There may be (and I would argue, should be) several answers for different populations in an organization. I believe I’ve made clear that in my own view for general user populations, having administrative accounts tends to be the best choice. However, when considering computers that will work with PCI data, the determination is obviously different, but only for that specific set of computers based on their unique needs and requirements.

In general, my advice is:
- don’t be dogmatic - use established tenets of security as a guide
- customize posture and policy to the needs & requirements of specific groups
- don’t forget the tenet of usability
- consider compensating controls
- determine when there are enough controls
- define acceptable risks

[donmontalvo]

@ChrisMike wrote:

The concept of least permissions is not a suggestion, but more a standard for protecting your data, end users, and organization.

+1

[pete_c]

In my last (solo) Jamf admin role I had 200ish managed devices and up to 150 users including freelancers and contractors, multiple offices and timezones, plenty of senior sales people working from home, and from the start I decided to not grant admin rights at the account level, but instead to grant admin rights via Self Service on a part-time, as needed basis.

My primary justification for this was not to lock users out, but to slow down potential malware and to force anyone making any change significant enough to require admin rights to have their machine check in (recon).

This policy meant that all I had to do was teach a user for to use the 'Grant Admin Rights' task in Self Service - the trick being teaching an understanding of the timing, run the task before starting an installer or trying to unlock a preference pane - rather than keep up with software engineers wanting their own IDE, salesfolks installing who-knows-what webinar software, home users needing to connect their own personal printers, etc.

By occasionally reviewing the logs of that Grant Admin Rights policy I could get a sense of who was constantly installing software or doing anything that require those rights, and either follow up with them individually, write and share documentation, or add policies to Self Service for items that were being installed regularly.

In any case, the key to this type of policy decision is to explain and sell the justification: what is the actual need - not simply the emotional idea of 'owning' an organizational device - balanced against the environment and the available support resources.

The SAP team released this https://github.com/SAP/macOS-enterprise-privileges although I've never used it - it's probably a better solution than mine:

promote_to_admin.sh

#!/bin/sh

# dseditgroup to promote the currently logged in user to admin rights

if [[ `/usr/bin/dscl . read /Groups/admin GroupMembership | /usr/bin/grep -c $3` == 1 ]]
    then /bin/echo "$3 is in the admin group, exiting"
        exit 0
    else /bin/echo "$3 is not an admin, promoting.." 
fi    

/usr/sbin/dseditgroup -o edit -a $3 -t user admin

demote_from_admin.sh:

#!/bin/sh

# dseditgroup to demote the currently logged in user to standard account

/usr/sbin/dseditgroup -o edit -d $3 -t user admin

Then from a Self Service task, run Promote as a script set to Before, use jamfHelper etc to notify the user to proceed, then from Files and processes run something like:

sleep 300 && /usr/local/bin/jamf policy -trigger demote && /usr/local/bin/jamf recon

This could obviously be a lot more graceful, but it worked well for being able to quickly clone the policy and change the sleep value to allow, say, a member of the Engineering dept. 30min of 'admin' time instead of 5min. Having the scripts broken out separately also provided some flexibility to handle one-off edge cases, like permanently promoting someone who had shown themselves trustworthy.

[donmontalvo]

@pete_c something similar to the two scripts I posted here to temporarily elevate non admin users trying to update/upgrade/reinstall 10.13.6.

Scroll tdown to bottom...

https://github.com/kc9wwh/macOSUpgrade/issues/56

[bwoods]

Hi everyone, my secadmin team wants to remove admin rights for all of my users. I initially thought that the Jamf Connect Login P.A.M module was able to do this, but I was mistaken. the P.A.M module only allows you to run sudo commands and use a cloud identity provider to enter your password. Since I couldn't use P.A.M, I created a simple script that would make it possible to run sudo commands without an admin account based on all of the information you all provided. Thanks to everyone for pointing me in the right direction.

1. Make sure to run this script with a Jamf policy
2. I've included security features to prevent users from editing System Preferences, attempting to remove the Jamf Binary, and editing the sudoers file.
3. After you've removed admin rights, work with your users to determine standard software to keep in Self-Service for installation.

#!/bin/bash

# Identify the username of the logged-in user

currentUser=`python -c 'from SystemConfiguration import SCDynamicStoreCopyConsoleUser; import sys; username = (SCDynamicStoreCopyConsoleUser(None, None, None) or [None])[0]; username = [username,""][username in [u"loginwindow", None, u""]]; sys.stdout.write(username + "
");'`

# Create file named "standard" and place in /private/tmp/

touch /private/tmp/standard 

# Populate "standard" file with desired permissions

echo "$currentUser ALL= (ALL) ALL
$currentUser    ALL= !/usr/bin/passwd root, !/usr/bin/defaults, !/usr/sbin/visudo, !/usr/bin/vi /etc/sudoers, !/usr/bin/vi /private/etc/sudoers, !/usr/bin/sudo -e /etc/sudoers, !/usr/bin/sudo -e /private/etc/sudoers, !/usr/local/bin/jamf" >> /private/tmp/standard

# Move "standard" file to /etc/sudoers.d

mv /private/tmp/standard /etc/sudoers.d

# Change permissions for "standard" file

chmod 644 /etc/sudoers.d/standard

exit 0;     ## Sucess
exit 1;     ## Failure

[Nix4Life]

@bwoods

Many including myself have been doing this with Puppet,Ansible,Salt or pick you CM tool, which offers better control. I have seen strange things happen sometimes when trying to grab the user from the console