Since the MDM profile and management framework can be removed by users who have administrative access to their computers, how would one build in a failsafe and have machines automatically re-enroll/re-manage themselves if someone removed the profile or figured out how to remove the framework?
I'm sure this has been hashed out before, but I cannot find a discussion the explains it. If anyone has a link to a discussion with a solution, please share.
http://derflounder.wordpress.com/2014/04/23/caspercheck-an-auto-repair-process-for-casper-agents/
There is no method out there that's perfect, even if JAMF decides to build something to do this, especially when talking about admin users. Pretty much all bets are off on keeping them managed, but take a look at the above for something that can help.
Truthfully though, you should look at trying to get management/HR to have a published policy in place (that clients must sign!) that there could be repercussions for actively bypassing IT controls.
@mikedodge04 from Facebook discussed things like this last year…
http://www.jamfsoftware.com/resources/managing-the-unmanageable-in-a-hacker-culture/
I'd second Mike's opinion though that should be an HR policy issue.
Don't forget those in education ;-) Something like Rich's script can save entire school districts from the same sort of thing that cost LA it's iPad program. That or testing; One of the two. ;-)
P.S> Just in case: Yes I know this script would not have done a thing for an iPad school system like LA. It the precept that a school system that loses control of it's students computer have a failed implementation on their hands.
i'm trying to resetup the casper check in our environment now that we've changed JSS URLs and stuff, but for the life of me, I can't figure out how to post the file to the server. so that when it goes to jss.server.com/quickadd.zip it finds it...
@Chris_Hafner Yeah really! Talk about meddling users!!!
Just want to throw in my vote for Rich's script.
Just to add a bit more protection, I would also restrict access to the profiles system preference, or remove it from view to take away the temptation. Possibly restrict access to the profiles command as well.
One of my favorite things to do is to watch for students deleting the .AppleSetupDone file on their computers. We don't set root PW for SU on BYOD units... in part because I want to see who's mucking about. We make great interns out of those types of students!
I agree with it being an HR type problem. So now what we do is take Macs that have not checked in within the last 45 days and send that report to management. They can then query the users as to why and leave us out of it. We also delete those Macs from the JSS so we can gripe and it makes their management even more unhappy. Trying to reel in Admin users is never going to happen using technology - it's better to hit them with unhappy bosses.
I've built my own spin on a self-healing script that re-enrolls the client in specific situations. I went through a lot of iterations and found some approaches tended to generate false positives, but a daily launchdaemon script runs some checks and takes appropriate action as needed (with a cached quickadd, but can also curl down the jamf binary from the JSS to use for enrollment).
For me, it's a catch-all that is targeting minor meddling or simple accidents. If I have to roll back to an old database backup (for example) then systems will re-enroll and I will just need to address lost FV recovery keys. If someone deletes the JSS cert from the keychain or a record gets deleted from the JSS, that would get fixed.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.