Hey all,

Nothing much to share, and especially not something which is on the roadmap for Jamf Pro as far as I know. So a big disclaimer, don’t build any expectations out of this.

Just an idea I’ve been playing around with in view of a feature request for an emergency mdm block functionality. This in view of human error or unexpected behaviour of JPRO resulting in mass removal of configuration profiles (or apps).

By lack of dev skills, but within the comfort of good old bash on my on-prem server, it’s easy to build a service which monitors the mobile_device_management_commands table of the JPRO database and triggers certain emergency actions (e.g. closing the APNS ports) when an unexpected high rate of certain MDM commands are being push out or queued up. This to avoid widespread business impact and/or potential data loss when a certain Change Management Protection setting is enabled on the server.

At JPRO code level this could be translated in a server setting to enable Change Management Protection with predefined time interval and configurable threshold for an amount of certain MDM commands. For instance: Remove Profile, Remove Application, etc. In view of emergency actions, a code level interruption of pushing out queued commands could stop the mass removal until an admin goes into JPRO to overwrite the interruption. This after validating the mass removal was desired/expected. If not, it would allow for mitigating actions to cancel the commands and/or work around the root cause of the mass removal without impacting the client devices.

At my bash hacking level, I played around with running a monitor service, checking the mobile_device_management_commands table of the JPRO database in loop at set intervals and shutting down the APNS ports locally (outbound of the server) when a certain rate of removal commands is exceeded during a set time interval. This based on the date_sent_epoch of the commands in the table.

A little gimmick added was the notification via Pushover to my iPhone to alert me something is acting up:

Of course a lot of considerations have to be made, like the interval at which such monitor needs to run, the possible impact on server performance, the time interval for the threshold for the commands to monitor, etc… Also shutting down the ports may or may not be the best idea, hence the alternative of shutting down the mdm controller at code level.

Anyway, as said, just playing around. At least at bash level the above, seems to do the trick. All suggestions, remarks or considerations welcome.

That’s it! As always, if you liked the post, hit the like button, tell your friends about it and leave a comment down below!

Brgds,
TTG