Separate admin account from standard user

[danny_gutman]

In my environment, we have a local admin account that is not used to sign into, only to elevate to authenticate installations, and then the standard user account that the users use, which is not an admin.

This is the way it was set up when I got here, and I was told this is the most secure way.

What am I missing? What is the difference if a user uses their own admin account that they are currently signed into, to authenticate? Or whether they use separate credentials only for authenticating, keeping their current user as standard?

Does this make sense? Since we must give users access to a local admin account to authenticate, I'm looking to simplify, and simply elevate our users to admin, and lock down smartly with our config profile.

Any input would be so appreciated!

[jchurch]

if the current logged in user is not an admin it protects against websites running malicious code in the background as an admin.

[danny_gutman]

So what is standard practice here in the industry? To create a separate admin account like my environment was set up?

I'm curious, this malicious code will not prompt for admin credentials? It totally bypasses this?

[cpominville]

Im not sure I agree with jchurch. I know this is standard practice in the pc world....but Danny, I think your correct..nothing will install itself on osX without asking for a password / prompt. I'm going on my gut instinct with my limited 25 years managing Macs experience. I always let my adult users run as admin on their school laptops, and I don't recall any issues. There could be something new I don't know about, I don't profess or claim to know everything. Perhaps jchurch could enlighten us with some experience that he has had. I don't mean any disrespect jchurch.

[danny_gutman]

@jchurch has the same opinion as my Sr. Systems Admin guy, who's been in the game for a long time. I don't know if it's an old school/antiquated idea, but the way that Mac is set up now.... I think anything that can do any harm will ask for Admin privileges.

I care more about ease of security than malicious software that I can get rid of with a re-image, if that makes sense.

I know that elevating my users to admin on their own account, and eliminating the second admin (which has the same password for every account) seems like a more secure, and convenient solution.

[cpominville]

Danny, I do believe its an old school /antiquated idea, I have fought the PC mentality of managing Macs for years, not that they mean any disrespect, they are trying to manage things to the best of their knowledge. I know Apple would not set it up that way. What kind of user experience is that? The user experience principle has guided me well through the years. And I think, that's what Jamf is trying to do to.

[seraphina]

Anything that is a global setting requires admin authentication. I have actually been arguing to not remove admin privileges from our mac users because there's too many software/scripting cases to account for with self service. And what happens if a user is out of the country and needs administrator access? Even with a script in Self Service that grants temporary elevated privileges so they can make their changes isn't ideal because the tech-savvy users can just leverage that and give themselves permanent admin access.

If a user is a local admin, you will notice that some (but not all) padlock icons are gone. The stuff that remains usually modify global configurations and will still require authentication even if they are an admin.

Malicious code can't always bypass authentication unless it exploits an overflow or somehow leverages arbitrary code execution.
For example the defaults program:

A non admin user could call

#!/bin/sh
defaults read /path/to/file.plist

which will call the defaults in /usr/bin UNLESS for example, a malicious program named 'defaults' has been installed in the user's path. At this point the fake defaults program would run and it could very well leverage an exploit or simply ask for the admin password. At that point the malicious party would have administrative access.

In our environment we have hidden management accounts. One for our technicians and one for the sys admins.

In my opinion, having a standard user that knows the admin credentials is no different than giving that user administrative rights.
The main benefit is some malicious code might not be able to run, but again, if they are downloading a program (that happens to be malicious) and it needs authentication (to install), it still defeats the safety net because the user can still authenticate.

[david_hunter]

Here's my situation. We recently finished an MPAA audit of our company and had to remove admin access for any users accounts, except the IT Admins. We also removed 99% of internet access from certain groups, save for some whitelisted exceptions. Now, we have a group that needs to run beta updates (download and install) of their core app, but they don't want to call IT every time they need an admin to authenticate and allow the software to be installed. So, is there a way to setup a sub-Admin account that can make changes to just one app, without allowing them permission to change other apps, to disable security software etc.? Basically, I just need a secondary admin user account that has "whitelisted" admin software installation privileges. Is that doable in JAMF?