Disclaimer: This blog (and this post especially) is not intended to be advice on how to manage your environment. As the name suggests, these accounts are based on experiences I’ve had in my own lab. Always approach information you find outside (or inside for that matter) official documentation with skepticism and follow the golden rule: Never test in production.
In one of my previous posts, I discussed Intune for MacOS and How It’s Different where I highlighted that unlike other MDM providers; Intune does not create a managed admin account on MacOS. Without leveraging a 3rd party utility like JumpCloud or NoMaD (now JAMF Connect); synchronizing passwords on MacOS with a centralized identity provider has always been a pain point; let alone leveraging a rotating local admin password similar to LAPS.
In this post, I’m going to borrow a topic Michael Niehaus wrote for Windows (You can use Intune to create a local admin account, but that doesn’t mean its a good idea) and show you how we can do the same for MacOS and demote all other accounts to Standard users at the same time. Before I do, however, I’m going to clearly restate what Mr. Niehaus has devoted a sizable chunk of his post to say: Just because you can, doesn’t mean you should.
Having an account on every device with the same credentials is all-around bad practice. Not being able to rotate the password behind the scenes where only authorized personnel can retrieve it is even worse. My intention here is to highlight that it’s possible and demonstrate a few system mechanics of MacOS in the process. Please use the correct tools for the job any time security is at stake.
WARNING: THIS POST INVOLVES PASSWORDS IN CLEAR TEXT AND NOT RECOMENDED FOR USE IN A PRODUCTION ENVIRONMENT!
Creating an Admin Account
Creating an account with a script in MacOS is actually fairly simple. The bulk of the work is simply creating directories and setting required attributes. We will use the Directory Service Command Line utility for each of these and more information on the available arguments can be found HERE.
1) Create the account container
2) Set the user’s default shell. Newer versions of MacOS use zsh, but you could use bash as well.
3) Set the user’s full name.
4) Set the Unique user ID number. These will start with 501 for the first user on MacOS and increment upwards. Be careful not to use a number that may already exist. In this case, I’ll use 510 as it is unlikely most machines have 9 users already.
5) Set the user’s primary group ID. This usually matches their Unique User ID, but in this case, we are adding them to the local admin group which is 20.
6) Set the user’s home directory.
7) Set the user’s password
8) Lastly (and optionally), we can add the user to any additional groups. If you set the PrimaryGroupID to match the UniqueID, you can add the user to admins here.
The final script will look something like this:
Demoting All Other Users
Yet Another Disclaimer: The very brief experiments I have done in my lab seemed OK and I did not notice any degradation in my ability to deploy applications or policies with Intune. However, since I have not forced myself to use a machine extensively like this I don’t know what hidden consequences there might be. Proceed at your own peril.
First, we need to understand what user accounts MacOS has built-in and what they do. There are several dozen hidden accounts on MacOS, but 3 are visibly located under the /User folder and it will be important to avoid making changes to them.
root – Comparable to System on Windows. This is a god-tier account that is disabled for direct login by default. Intune will elevate to this account when it leverages its Intune Management Extension to run scripts and packages.
Update: Automatically Lockdown/Disable Root access on MacOS
nobody – Used to run system processes and restrict access to things that don’t need any special permissions. It’s usually reserved for services that — if they become compromised — will do minimal damage to the rest of the system.
daemon – This user owns and runs system processes that typically run outside of the user session.
All the other non-user accounts should be preceeded with an underscore ( _ ) to mark them as hidden. We can create an array by getting a list of them using dscl and piping in grep to filter them and any other accounts out.
Once we have our array of accounts, it’s just a matter of looping through each one and removing them from the admin group.
If we combine this with our create admin account, we will get something that looks like this:
Deploying Through Intune (…for science)
Save your script as a .zsh file and upload it to the Endpoint Portal under MacOS > Scripts. You may wish to hide any notifications from the end-user and set the maximum number of tries if you wish. If you choose to make this script recurring, you may want to separate out the admin account creation as we aren’t checking for the existence of the account first, and trying to create the account again will result in failure.
After it has run successfully, log off and log back in to see the results.
If you have done this or something similar in your environment (hopefully your lab), let me know how it went and what complications you ran into in the comments below.