Prevent removal of JAMF binary by local admin

not prevent, but a way to repair

https://github.com/jamf/JSSBinarySelfHeal

or

https://derflounder.wordpress.com/2014/04/23/caspercheck-an-auto-repair-process-for-casper-agents/

you need to modify the sudoers file located in /etc/ -> /etc/sudoers

comment out the line containing

%admin ALL=(ALL) ALL

result

#%admin ALL=(ALL) ALL

and any user that is an admin will no longer be able to run sudo commands. =)

they need to do "sudo" for all jamf commands and this will prevent that.

• please if anyone that knows sees the following, correct me if I'm wrong here

I've never taken this next stop as I'm not positive whether or not it's necessary but if you are really worried, to double down you should also chmod the directory utility application so only users with root privvies can execute it, by default its privileges are

drwxr-xr-x

i dont know if changing the admin sudoers privies prevents this, but i think admin users can still run this which in turn allows them to enable root account and then they could use terminal to login to root and run sudo commands as well. it is by default chowned root:wheel so no need for chownage.

We couldn't lock down the sudoer list, as some devs need to run sudo level commands for their work
We just rely on healing as a precaution, as if they're going out of their way to remove the management framework (whether its Mac, Windows or any other platform) then this is a HR issue, as they would have agreed to the IT acceptable use polices when they joined the company and this action would be in breach of this.

Thanks for your help guys. Although I am a bit disappointed that there is no way to prevent the removal of the JAMF binary I will look into gbidwell's links.
Disallowing sudo is no option as some of our professors use sudo a lot.

Hopefully JAMF will offer an easy and good solution for preventing the removal of the binary in the future.

Not to be a naysayer, but there is an end of life notice in the GitHub:

I will no longer be offering support for this Self Heal application. Due to the new User Approved MDM additions to 10.13, this is no longer a good tool to be running on client machines. This tool will break the User Approved status of MDM which will break user level profiles and the ability to install VPP apps. Sorry for the inconvenience.

Our people have the same capabilities, and I really don't have that many issues with people doing this. The one thing I can think of is making Jamf as valuable of a resource as you can with Self Service and not being too heavy-handed with how it all works.

So the correct solution to this issue is for Apple to allow MDM companies to install their agents/apps to a SIP location. As while that is really easy to write as a sentence you could see where it's a big can of worms.

That said it's no bigger can of worms than, Team Identifiers and gatekeeper certs.

C

You can also restrict commands through sudo. I have a number of developers that need sudo access so I have a list of commands that they are not allowed to run like any jamf commands.

here is the sample code to add to suders
<username> ALL=(ALL) ALL
<username> ALL = !/usr/bin/passwd root, !/usr/bin/su -, !/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

I don’t see having healing not being able to preapprove MDM profiles in 10.13 onwards being a too much of issue to circumvent, as it can actually be benifit when combined with conditional access.
As long as the binary is installed, it can still report back in to the JSS and update it’s current status.
By having a non approved MDM status for us it means the access to network services are revoked as the conditional requirements are no longer met.

But following on from wesleya’s comment, making Self Service invaluable to the user is the key to making this issue a mute point for the future.
We only give dev’s admin permissions due to their specific job requirements, as we have try to make as many of the benefits of having admin permissions to be made avalible to standard users through Self Service in a controlled & auditied environment.
By making standard users empowered via Self Service as much as possible, we find now that we hardly get any requests from them to make them a local admin.
Out of thousands of users and from the last few years running on Jamf, we’ve only ever had one incident where the binary was disabled on purpose, but they soon came back into the fold when suddenly they found their abilities greatly reduced and received a gental notification message that they were breaking company policy.

If you don't want them to remove the binary then I would do one of two things:

1. disallow local admin
2. report removal to human resources

I have made terminal, restricted software, so local admins can't launch it to remove the framework. We can remove them from the scope when we need to, but they try to launch terminal, they get nothing.

I hate to bring back an Old thread but how do I prevent the local admins who discover the JAMF bin and start playing with the JAMF commands. 100% of all my mac users are Engineers and Developers and have admin access to their machines.

But don't want them poking around on those array's. Is there a way to prevent admin from running sudo jamf commands?

You would need to add the devices to ABM and then a PreStage in Jamf. This will let you make the Jamf binary and MDM profile non-removable.

@cpresnall forgive my ignorance but what's "ABM" and can you go into more detail on this processes I would be most grateful.

ABM - Apple Business Manager

Also, that is not quite correct. With DEP enrollment you can make the MDM profile non-removable, but not the Jamf binary.

Thanks @ryan.ball I was about to say the very same thing I have never seen either of those option on the Apple Business Manager (ABM)

The option for restricting MDM profile removal would be in your Jamf Pro DEP Prestage Enrollment.

ABM = Apple Business Manager. This is what the DEP or Device Enrollment Program has become.
Basically it allows you to link your devices to Jamf during initial setup through certificate based communication with Apple. Businesses sign up and then add their devices by purchase order number to their ABM account. When the device goes through setup assistant it reaches out to Apple, confirms that the serial number in in ABM, and then ABM tells the device what MDM to talk to. In this case, ABM tells the device to talk to Jamf, and in Jamf you set up a Pre-Stage telling the device what to do on setup (create users, install profiles, make MDM non-removable, etc.).

Once set up, this makes things much simpler for businesses especially where the users are admins, or where IT does not have the throughput to physically touch each device prior to handing it out.

@cpresnall The thing is our Business never gets to see the DEP processes our company has a middle man since we don't use apple directly. So I have no idea what it looks like from that end.

I usually restrict MDM removal from the profile itself but that's not what I was looking for.

@CorpIT_eB

https://help.apple.com/businessmanager/en.lproj/static.html

I would recommend that you require your middle man to set up DEP/ABM. We use many vendors all over the world and they all support DEP/ABM.

C

CorpIT_eB, you can still use DEP even if you don't purchase directly from Apple. Most resellers are DEP enabled these days. At my last position I had to request the reseller to complete their part of the DEP process. Enabling it for current and future purchases is a simple process for them but apparently a "real difficult process" for Macs that had been purchased a few years ago.

The best solution may be a non-technical one.

This is what I would do. Use a LaunchDaemon to detect if the binary is present, and if it is not reinstall it. The LaunchDaemon would be set to RunAtLoad and StartInterval of say 60 seconds. This would be a script to start with (I have not tested this script):

#!/bin/bash

log="/Library/Logs/Jamf_Framework_Rescue.log"
jamfBinaryPath="/usr/local/bin/jamf"
jamfProURL="https://jamfpro.yourcompany.com:8443"

function writelog () {
    DATE=$(date +%Y-%m-%d %H:%M:%S)
    /bin/echo "${1}"
    /bin/echo "$DATE" " $1" >> "$log"
}

function jamf_framework_rescue () {
    if [[ ! -e "$jamfBinaryPath" ]]; then
        writelog "Jamf Binary is missing, reinstalling..."

        # Download the jamf binary from the Jamf Pro server
        curl -ks "$jamfProURL/bin/jamf" -o /tmp/jamf | while read -r LINE; do writelog "$LINE"; done

        # Create required directories
        mkdir -p /usr/local/jamf/bin /usr/local/bin | while read -r LINE; do writelog "$LINE"; done

        # Move the jamf binary
        mv /tmp/jamf /usr/local/jamf/bin | while read -r LINE; do writelog "$LINE"; done

        # Make the jamf binary executable
        chmod +x /usr/local/jamf/bin/jamf | while read -r LINE; do writelog "$LINE"; done

        # Create a symbolic link
        ln -s /usr/local/jamf/bin/jamf /usr/local/bin | while read -r LINE; do writelog "$LINE"; done

        # Create a configuration file
        jamf createConf -k -url "$jamfProURL" | while read -r LINE; do writelog "$LINE"; done
    fi
}

# Run the function
jamf_framework_rescue

exit 0

And surprise surprise, you can create the LaunchDaemon using my tool, Launchd Package Creator.

@ryan.ball I wish I knew how to utilize that tool just by looking at it, it looks amazing.

@CorpIT_eB You can do it! Let me know if you have any questions about it. ryan.ball on the MacAdmins Slack.

You can most likely, set your VPN to verify that the binary is there.

C