Auto Add Mac Clients to Jamf Pro?

[RedWings]

We have an office where admin users are re-imaging their Macs or removing the JAMF Pro binary and therefore are unmanaged. Is there any way to re-add a Mac client automatically that is on our internal wireless to JAMF Pro?

[ShaunRMiller83]

I'm sure there a lots of ways to "skin this cat". The 3 I can think of off the top of my head are:

1) If the systems are in DEP. They will automagically be reenrolled even if the systems are rebuilt.

2) I'm not sure if it still works since it is a few years old. Rich Trouton has a script called CasperCheck for this exact purpose.

3) If you use Cisco ISE or NAC you can setup network posturing or watermarking to route unmanaged systems to a guest network. Which will make those users have to ask to be re-enrolled to get back on a "regular" network.

[alexjdale]

I recommend something like option 2 for every environment. It resolves a lot of potential problems, either with users themselves or just general one-off corruption/failures.

[davidacland]

DEP is the latest way to do this and does exactly what you need, when it works.

I’ve also seen people use the 3rd option mentioned above, sending devices to the server’s user initiated enrollment page, only allowing no full network access once they are re-enrolled.

[hkabik]

I resolve this with the aforementioned caspercheck and it works great.

https://github.com/rtrouton/CasperCheck

[mm2270]

CasperCheck is a good solution for general connection loss problems, but it isn't going to be much good if clients are re-imaging their Macs, assuming by "re-imaging" you mean wiping the device and reinstalling the OS. The best way to stop that is to apply a Firmware Password to their Macs, and not give it to anyone other than IT personnel. If they can't alternate boot or boot into Recovery HD, they can't realistically re-image their Macs. Firmware Passwords introduce other complications and headaches, but it's still the best way to stop someone from wiping their system, unless they are in DEP, in which case as mentioned, it will get them auto re-enrolled.

Then, with something like CasperCheck in place, it can help with the ones removing the jamf binary/framework. It still won't stop anyone from removing CasperCheck itself, if they discover the parts that make it work. But it's better than nothing.

We also use Option 3 mentioned here, but with Forescout. The posture assessment done on network connection ensures Macs are under management. If they haven't checked into Jamf Pro within a set number of days, we assume it's no longer being managed properly and they don't get full network access until it's resolved.

[signetmac]

Not much you can do if they wipe and reinstall the OS on the computer outside of DEP. This is really more of a HR/management issue than an IT issue. Make removal of management software a punishable offense and make an example out of a couple of people.

.... buuuuuut knowing that HR/corp management doesn't always have your back:

1. Write the following code block to a file with an inconspicuous name and bury it somewhere that is universally readable (if it's root only, the next step won't work)
2. Edit /etc/bashrc and source it.

jamf() { 
    if [[ $@ == "removeFramework" ]]; then 
        command jamf policy -event report > /dev/null;
    else
        command jamf "$@";
    fi
}

sudo() { 
    if [ "$#" -gt 0 -a "$1" = "jamf" -a "$2" = "removeFramework" ]; then
        command jamf policy -event report > /dev/null;
    else
        command sudo "$@";
    fi

}

If someone issues the framework removal command as root or with a sudo command, it will fire off a "report" policy instead. Write that policy how you see fit. I suggest maybe a script with an API call to add the computer to a static group, or flipping an extension attrib, and monitoring that membership for violators. If they run without root privs, it'll just dump the error into /dev/null and they will be none the wiser.