Lock Down JAMF System Files

How are you detecting these folders are being cleared?

What grade are we dealing with here? And are these lab computers? If so, why do the students even have admin access on them? Are these part of a 1 to 1 program? If so, then that may get a little tricker, but I think ultimately falls on disciplining them and getting administration involved. Depending on how you are detecting those folders are being cleared then I'm guessing that there is still an MDM connection to the computer which probably means you can 'lock' the computer forcing the student to have to bring it in. These are just ideas though. Maybe others in education will have better advice.

They are 1 to 1 devices from grades 6 to 12 - we are detecting them based on the fact that they are no longer checking in to the JSS so there is nothing we can do as far as pushing anything out. The policies I mentioned are currently being pushed out as preventative, but there are about 145 students we have determined have not been checking in since the beginning of May.

If the students are local admins, then that's the biggest issue. There will almost always be some way of getting around restrictions as an admin, unless it's part of Apple's MDM spec (which as you've been able to see, this is not).

You could try restricting Terminal access; that would be a way to remove those files regardless of Finder restrictions.

You may also want to look into @rtrouton's great CasperCheck script. If your users are given the permission to remove LaunchDaemons then they could certainly remove CasperCheck's, but perhaps naming its plist file something misleading would prevent at least some users from removing the file indiscriminately, and could help restore the connection to the JSS should the other steps be ineffective.

Seconding removing local admin rights and CasperCheck.

There is no perfect solution here. As others have mentioned, with end users having admin rights on a box, all bets are off regarding keeping these machines under management. If its possible to remove admin rights, and then open up some of the items they may still need to be able to do such as get at some System Preferences that normally require an admin password to unlock or such, that would help a lot. Other things can be put into Self Service that might be hard or impossible to allow them to do as non admins.

Lastly, I doubt I would really do this myself, since it could cause some very strange issues, especially with future Casper upgrades pushed down to your boxes, but just as an extra option, you could also set the immutable flag on the /Library/LaunchDaemons/ directory. This would prevent even a sudo rm command from working on removing it without first removing the immutable flag.

sudo chflags schg /Library/LaunchDaemons/

Of course the big problem with the above is that going forward, any installers that might need to drop something there or make modifications to items in it would fail. At least until that flag is removed from the directory. Maybe the better option would be to set that immutable flag on just the LaunchDaemon plists you care about and not the whole folder. Of course, test, test and test some more before relying on something like this. I'm afraid you could run into some problems with that approach as I mentioned.

I've got to agree here. High school students will ALWAYS 'play' with stuff if they are admins. I'm not sure how you can manage this without risking the normal operation of the OS. Are there specific reasons why your students have administrative access? I've always found simpler ways to enable features and functions that might have otherwise required Administrative access for.

You can't resolve a personnel issue with an IT policy.

If you want a big stick, and are allowed to use it - Kill the login process if they bin the files. They will have to come back to you to get it fixed.

You can create a script to run at boot as a LaunchDaemon, you can then get the script to do whatever you want if the contents of any folder changes. You could store copies of the files in a safe location, and then copy them back and re-launch them. The script will work at this point, because the process will still be running. They have to use launchctl unload to stop the process, or reboot the Mac. My guess is they are rebooting. To save time you can create a onetime Daemon, that does the copies for you at boot, this will make the process very quick, it then bins itself when completed.