Automatically Lockdown/Disable Root access on MacOS

Disclaimer: This blog 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.

One of the first things I look for when performing a Health Check for organizations running Intune (if they have Macs) and Jamf Pro/Protect is whether they have systems enrolled with the root user enabled. If you’re unaware, root is the System Administrator on most unix based systems and has the highest permissions on the system (See Demystifying `root` on macOS, Part 1 – Scripting OS X over at https://scriptingosx.com for a great overview).

Root login is disabled by default on MacOS for obvious reasons, but users with local administrator permissions can enable root on demand. There are many legitimate reasons why you would want to do this temporarily, but root should never be enabled long term. Whether they enabled root and left it that way out of ignorance or forgetfulness, the solution is the same: Report on devices where root is enabled and automatically remediate.

In this post we’ll cover using Extension Attributes in Jamf Pro and Custom Attributes in Intune, creating Smart Groups based on it, and deploying a remediation script to knock root back to its disabled state.

Custom Attributes for Intune

It’s worth noting that as I discussed in a previous post (Intune for MacOS and how it’s different.) Intune leverages the Root account to execute commands via the Intune Management Extension and thus it is important to distinquish between disabling root login and disabling root completely. Root must still function, but not be accessible without an administrator actively enabling it and setting a password.

Results of a simple script which echos the output of whoami command run by the Intune Management Extension

Custom Attributes in Intune are relatively new for Microsoft and likewise have a long way to go before it truly offers feature parity to Jamf. The premise, however similar, does not yet allow us to populate dynamic groups based on the result, but we’ll work around that limitation by deploying it in two different ways. For reporting, we can create a script and Intune will take the echoed output as the final result under the individual Custom Attribute.

Note: Intune’s API may be leveraged to create groups either by script or PowerAutomate, but this particular API call is still in beta. See the following documentation for more information.

https://docs.microsoft.com/en-us/graph/api/resources/intune-devices-devicecustomattributeshellscript?view=graph-rest-beta

In this case, we are looking at the value of root’s AuthenticationAuthority using the Directory Service command line utility. If the value is “1” then root login is disabled. We’ll take that value and compare it to the expected result and echo out what we want Intune to report.

Shell

Intune-CustomAttribute-RootStatus.sh

#!/bin/bash
rootCheck=`dscl . read /Users/root | grep AuthenticationAuthority 2>&1 > /dev/null ; echo $?`
if [ "${rootCheck}" == 1 ]; then
	echo "Disabled"
else
	echo "Enabled"
fi

Save this script somewhere handy and head over to https://endpoint.microsoft.com > Devices > MacOS > Custom Attributes. Click Add and fill out the Name and Description appropriately. On the Attribute Settings page, make sure to select “String” as the Data type of attribute, then upload your script file and assign it to a group.

Custom Attribute scripts in Intune are run every 8 hours which is the normal check-in interval. If you really want to, you can include your remediation script here as well, but this defeats the purpose of using it for reporting as the result would always be “Disabled” due to the remediation happening immediately before the result (unless something went wrong in which case, your milage may vary).

For separate, more granular control over the remediation, we’ll create a normal script deployment which we can set to run anywhere between every 15 minutes to every week depending on your needs.

Shell

Intune-Script-DisableRoot.sh

#!/bin/bash
rootCheck=`dscl . read /Users/root | grep AuthenticationAuthority 2>&1 > /dev/null ; echo $?`
if [ "${rootCheck}" == 1 ]; then
	echo "Disabled"
        exit 0
else
	echo "Enabled"

        # remove the AuthenticationAuthority from the user's account
        dscl . delete /Users/root AuthenticationAuthority

        # Put a single asterisk in the password entry, thus locking the account.
        dscl . -create /Users/root Password '*'

        # Disable root login by setting root's shell to /usr/bin/false
        ## This will prevent use of 'su root' or 'su -' to elevate to root.
        ## Comment out, remove, or use 'sudo' with another admin account if needed.
        dscl . -create /Users/root UserShell /usr/bin/false

       # Let's validate and report back to Intune the post-script results.
       if [ "${rootCheck}" == 1 ]; then
            echo "Root was Enabled and is now Disabled"
            exit 0
       else
	    echo "Failure: Root was Enabled and is still Enabled"
            exit 1
       fi
fi

Save this script somewhere handy and head over to https://endpoint.microsoft.com > Devices > MacOS > Scripts. Click Add and fill out the Name and Description appropriately. On the Script Settings section, upload your remediation script and verify “Run script as signed-in user” is set to NO. Think carefully about the Script frequency. If your organization has a lot of scripts running all the time, you may run into unexpected issues when a device gets hit with a number of them at once. I recommend at least daily so that anyone with permissions and legitimate reason to enable root can do what they need to do and we can catch up with them later if necessary. If you want the ability to report on these devices before they are remediated, set it for weekly.

Once the script is run successfully we can confirm that root has been disabled and Intune is still able to function.

Custom Attribute reports Root is disabled again.

Intune is still able to run the Intune Management Extension as root.

Extension attributes for Jamf Pro

With Jamf Pro we can drive Smart Group membership based on Extension Attributes which allow us to only target and execute the script on non-compliant devices. From your Jamf console, navigate to Settings > Computer Management > Extension Attributes. Click New and fill in the Name and Description as appropriate. You can set the Category to anything you want, but be sure to set the Data Type to “String” and Input Type to Script. This will provide you with a text box where you can paste your script directly into. Once complete, double check the scripts formatting (lines often get broken into multiple when copying and pasting from a browser), then hit save.

Shell

Jamf-ExtensionAttribute-RootStatus.sh

#!/bin/bash
# Source: https://community.jamf.com/t5/jamf-pro/how-to-disable-root-for-users-that-have-enabled-root-on-their/m-p/242644
rootCheck=`dscl . read /Users/root | grep AuthenticationAuthority 2>&1 > /dev/null ; echo $?`
if [ "${rootCheck}" == 1 ]; then
	echo "<result>Disabled</result>"
else
	echo "<result>Enabled</result>"
fi

Next create a Smart Group called “Root Status Enabled” or whatever you like to that effect. If you have an SMTP Server configured for email notification, this is a great example where being notified of changes can be really beneficial.

Head over to the criteria tab and scope this group to anything where our Extension Attribute has come back with “Enabled”. Remember, you will need to Show Advanced Criteria to view all available option if you’ve never used them before.

Next we will upload our remediation script to Settings > Computer Management > Scripts. Click New and fill out the name and information appropriately. Then go to the Script tab and paste in our script (again, double check formatting) and click Save.

Shell

Jamf-Script-DisableRoot.sh

#!/bin/bash

# Source: https://community.jamf.com/t5/jamf-pro/how-to-disable-root-for-users-that-have-enabled-root-on-their/m-p/242644

# remove the AuthenticationAuthority from the user's account
dscl . delete /Users/root AuthenticationAuthority

# Put a single asterisk in the password entry, thus locking the account.
dscl . -create /Users/root Password '*'

# Disable root login by setting root's shell to /usr/bin/false
## Note: This will prevent use of 'su root' or 'su -' to elevate to root.
##       Comment out, remove, or use 'sudo' with another admin account if needed.
dscl . -create /Users/root UserShell /usr/bin/false

exit 0

Lastly, we’ll create a Policy to run the script when needed. Head over to Computers > Policies. Click New and fill in the Name and Description appropriately. For the Triggers, we’ll use Recurring Check-in and Ongoing so that the script runs whenever it is scoped going forward.

Next choose the Scripts payload and add our Disable Root Login script. Set the Priority to Before and no additional parameters are necessary.

Finally, go to the Maintenance payload and check Update Inventory. This will re-run the Extension Attribute scripts and unscope the machine from this policy so it does not re-run until the device falls out of compliance again. Once complete, click Save.

Finally, scope your script policy to your smart group and Jamf will run our remediation script after the next inventory update and check-in!