Skip to main content

Happy Monday all (🤣)

 

So last week after successfully making a script on the classic api to change a site for mac using bearer tokens and properly salted/hashed api creds, i'm now on to my next challenge of using the preview api to set the recovery lock ready for all these MBP M1 pro's that are arriving shortly :- 

https://developer.jamf.com/jamf-pro/reference/post_preview-mdm-commands

so after getting to grips and trying to utilise the nice example generator, i send this to it in a script but all i get back is " [ ] " so not even a proper rejection.

can I assume first that the "managementid" is the UDID of the device and the clienttype is correct for a macOS device??  code below.. 

 

NB. its worth noting in actually passing the managementid as a "'"$UDID"'" as i am running this script locally grabbing the udid via the MBP's serial number from the classic api.  I still get the same response..

 

 

 

curl --location --request POST "$jamfpro_url/api/preview/mdm/commands" --header "Authorization: Bearer ${api_token}" --header 'Accept: application/json' --header 'Content-Type: application/json' --data ' { "clientData": [ { "managementId": "aaaaaaaa-3f1e-4b3a-a5b3-ca0cd7430937", "clientType": "COMPUTER" } ], "commandData": { "commandType": "SET_RECOVERY_LOCK", "newPassword": "banana01" } }'

 

 

 

 

 

i deliberately send a bad command though to make sure it was responding properly, but the SET_RECOVERY_LOCK is right despite the documentation thinking it was "SetRecoveryLockCommand" :-

 

 

{ "httpStatus" : 400, "errors" : [ { "code" : "INVALID_FIELD", "description" : "Could not resolve type id 'test' as a subtype of `com.jamfsoftware.mdm.web.dto.command.CommandDto`: known type ids = [DELETE_USER, ENABLE_LOST_MODE, LOG_OUT_USER, RESTART_DEVICE, SETTINGS, SET_RECOVERY_LOCK] (for POJO property 'commandData')", "id" : "0", "field" : "commandData" } ] }

 

 

 

@L-plateAdmin I just verified with my own system, and the management ID is not the same as the hardware UDID. I recently was working on this same problem last week, and was able to create a script based on the following article:

Recovery Lock Enablement in macOS Using the Jamf Pro API - Technical Articles | Jamf

 

That said, I was only doing this for (5) systems, so I didn't bother creating a script that could handle systems in bulk. I just reran it with the updated ID and passcode for each system. Any new systems that we provision will get this enforced via the pre-stage enrollment, which is preferred since the passcode can be set to automatically rotate after anyone views it. The only reason why these initial (5) systems didn't get set at pre-stage was because there was a bug with the version of macOS 12 that was shipping on some devices that could result in no volume owners being set if recovery lock was set during pre-stage enrollment.

@L-plateAdmin I just verified with my own system, and the management ID is not the same as the hardware UDID. I recently was working on this same problem last week, and was able to create a script based on the following article:

Recovery Lock Enablement in macOS Using the Jamf Pro API - Technical Articles | Jamf

 

That said, I was only doing this for (5) systems, so I didn't bother creating a script that could handle systems in bulk. I just reran it with the updated ID and passcode for each system. Any new systems that we provision will get this enforced via the pre-stage enrollment, which is preferred since the passcode can be set to automatically rotate after anyone views it. The only reason why these initial (5) systems didn't get set at pre-stage was because there was a bug with the version of macOS 12 that was shipping on some devices that could result in no volume owners being set if recovery lock was set during pre-stage enrollment.


Watching this as it's on my list. have either of you looked at jamf-recovery-lock ?

@L-plateAdmin I just verified with my own system, and the management ID is not the same as the hardware UDID. I recently was working on this same problem last week, and was able to create a script based on the following article:

Recovery Lock Enablement in macOS Using the Jamf Pro API - Technical Articles | Jamf

 

That said, I was only doing this for (5) systems, so I didn't bother creating a script that could handle systems in bulk. I just reran it with the updated ID and passcode for each system. Any new systems that we provision will get this enforced via the pre-stage enrollment, which is preferred since the passcode can be set to automatically rotate after anyone views it. The only reason why these initial (5) systems didn't get set at pre-stage was because there was a bug with the version of macOS 12 that was shipping on some devices that could result in no volume owners being set if recovery lock was set during pre-stage enrollment.


@Cranappras 

thanks for finding this, gah went through the API reference as much as i could i can only find this url that gives out the 'managementid'.  Its like a dog wanting his favourite toy  and the owner just saying here you go boy and throws a box of all 50 in the garden for him to fetch.....  I only managed to figure out how to phase one set of xmls on my old script to get the UUID and that wasnt doing a search and select function, just being able to return just one record.

 

i will have to look at what can. be done, at least i can limit the returns via selecting one page with maybe 20 records of the most recent IDs (im trying to make this into an non-prestage enrolment item). at least that will limit the data drawdown..

@Cranappras 

thanks for finding this, gah went through the API reference as much as i could i can only find this url that gives out the 'managementid'.  Its like a dog wanting his favourite toy  and the owner just saying here you go boy and throws a box of all 50 in the garden for him to fetch.....  I only managed to figure out how to phase one set of xmls on my old script to get the UUID and that wasnt doing a search and select function, just being able to return just one record.

 

i will have to look at what can. be done, at least i can limit the returns via selecting one page with maybe 20 records of the most recent IDs (im trying to make this into an non-prestage enrolment item). at least that will limit the data drawdown..


@L-plateAdmin 

 

Just curious, if you are doing this during enrollment, then why not just use the pre-stage enrollment settings for enforcing RecoveryLock? Seems like that would be a much simpler route to go. I only messed with this via the API because I had a handful of systems that were already provisioned that needed to have the setting enabled.

we are still not using DEP/ADM in our company so user-enrolled workflow is what we got. if we go cloud im sure ADM will be used.  although the PI is gone there was an issue with that as well, i have my script working now so its good, may post extracts tomorrow for anyone going down our route...

If you like bash - here our script https://gist.github.com/ExperimentalHeaven/09eeafa1122dd4bbac30cb9b91309b52

thanks, ours is working fine, i have to admit i have been lazy getting something redacted up for others

@L-plateAdmin I just verified with my own system, and the management ID is not the same as the hardware UDID. I recently was working on this same problem last week, and was able to create a script based on the following article:

Recovery Lock Enablement in macOS Using the Jamf Pro API - Technical Articles | Jamf

 

That said, I was only doing this for (5) systems, so I didn't bother creating a script that could handle systems in bulk. I just reran it with the updated ID and passcode for each system. Any new systems that we provision will get this enforced via the pre-stage enrollment, which is preferred since the passcode can be set to automatically rotate after anyone views it. The only reason why these initial (5) systems didn't get set at pre-stage was because there was a bug with the version of macOS 12 that was shipping on some devices that could result in no volume owners being set if recovery lock was set during pre-stage enrollment.


@Cranappras I was referencing this same article to implement Recovery Locks on some of our devices as well, and kept getting met with this error message upon trial: 

"httpStatus" : 400,
"errors" : [ {
"code" : "INVALID_FIELD",
"description" : "Invalid UTF-8 start byte 0x80",
"id" : "0",
"field" : "commandData

Were you able to bypass this easily? I feel as if there is something simple that I am missing, but can't quite put my finger on it. 

Thanks in advance

Terms & ConditionsCookie settingsAccessibility statement