Do I Really Need a Local Administrator Account?

[Mwhitten]

We have been creating a local Administrator account during enrollment on every machine. We are now questioning whether this is necessary at all. Currently all of our users are administrators and we do not use standard accounts. Can anyone think of a good reason as to why we would need another administrator account on the machine? 

[MatthewGC]

What are you going to do if people forget passwords? Will you ever need to recover data from a machine after someone leaves the company? Are you encrypting the drive? Without another admin you can lose all data. Those are just a few reasons. 

[B_Hanson]

As long as they are enforcing FileVault for the end-user, they can get the recovery key from jamf and reset the user's password to get in and poke around (as an admin, to boot). I agree having your own admin account makes it a little easier, but you're not locked out if you have the keys.

[B_Hanson]

If the LAPS solution is not something you need, then you can forego the two options for a local admin account.

The Jamf Management Account, according to the docs, is "only required for some workflows", and most of those workflows are deprecated at this point (the old Jamf Remote.app, FileVault stuff using JMF, etc). It's basically there if you want a local admin to login with either locally, over SSH, etc.

The Pre-stage "Managed Admin" account's main purpose (in my view) is to provide a required admin account on Macs that you want to setup with Standard Users during the Setup Assistant. But since your users are being created as admins during Setup Assistant, you already satisfy having the required admin account.

If you were using Jamf Connect and skipping native account creation, you'd also need the managed admin account. If you're concerned about the security of the admin account, then your end users probably wouldn't have admin privileges anyway, but the newer LAPS options are a nice improvement over the previous method of "master admin account across the fleet".

[Mwhitten]

Thanks for the information. We do use Filevault so the encryption keys would get us onto the Mac. Since we do use Filevault the Admin accounts we create are not Filevault enabled accounts so we can't even log into the Macs with them. If we could make it a Filevault enabled account then I could see a potential use for them but that doesn't seem to be an option. 

[pbenware1]

We have a similar environment, in that all users are admin users, except in a very few cases. We stopped creating local admin "support" accounts about 2 years ago.  Having a local admin account with a shared password, especially with our high number of remote users, was considered too much of a security risk.  While LAPS addresses that to a degree we decided to not add the additional complexity.

For those who want it, we offer CrashPlan as a centralized backup tool for data recovery in the event of data loss, which has come in very handy on a number of occasions.

For those who forgot their password, there are a number of ways to assist the user through resetting it.  Yes, it's a bit extra work on the part of the support staff, but we had to weigh that against the security impact.  Most of our users have Apple ID's that, when properly setup and the recovery key is recorded, can be used to reset local user passwords.  We can also use Jamf to reset a known user account password or create a new local admin "support" account on the fly and then help the user reset their forgotten password, followed by immediately deleting the support account.

[Mwhitten]

@pbenware1 

Thank you for the reply. I did have one question. What is your process for creating a "support" account on the fly? How do you make it a filevault user so you can log into the machine with it?

[pbenware1]

We use a policy using the Local Account payload, but we're not creating it as a FileVault user. (FileVault is not in widespread use here)

[B_Hanson]

If you can deploy Apple's Platform SSO, for macOS 14 you can now leverage "Using nonlocal IdP user accounts at authorization prompts", which basically means you don't need a local support account, you can just enter credentials of a support user that belongs to an "admin support" group in your IdP. Also read up on the bootstrap token, since one if it's jobs is to unlock FileVault for directory users. The notion of creating an additional local account and enabling FileVault for it is outdated now.

[guzhogi · Accepted solution]

I like having a generic local admin account with LAPS, just in case I need to get into the computer, and change settings or what not without having to ask the end user to enter their password.

[Karl941]

Hello Whitten,

Same here as Pbenware1 , we decided 2-3 years ago to remove all IT Services admin account. Now it's only 1 user per Mac device (admin) allowed with a strong control on SIP. If anything happens, we fully rely on the FV recovery keys stored in Jamf for Helpdesk. Positive impact = Better security posture and no more SecureToken issues anymore (and all problems coming with, especially on Apple Silicons).

[B_Hanson]

And a reminder that the new Platform SSO stuff from Apple supports "external authorization", so you can use Identity Provider accounts for authorization prompts in macOS without that account existing locally!

[Karl941]

@B_Hanson Did you test it? I am trying to find practical documentation about this? Any recommendation