Posted on 04-11-2023 02:45 PM
Just ran into this for the first time when trying to boot an M1 Pro into Recovery mode-- laptop was just reset using "Erase all content and settings" and has macOS 13.2.1 installed. I was intending to update the macOS to the latest by reinstalling the operating system from the Recovery console-- but alas, I ran into this "Recovery lock" blocker for the first time. So, with a little research, I find that the password should be cached in Jamf Pro, and I look it up-- a freaking 39-character password??? And when you type it in slowly on the computer in question, it doesn't show up as you type. Is this all the default behavior Apple has created? What a fricken pain in the butt.
I don't see the need for this overbearing security roadblock. All my users are local admins and living remote, and in eight years of managing Macs with Jamf, I have not regretted that once. Everyone's remote now, and they need to be able to do some troubleshooting, Jamf Pro helps us keep the drives encrypted, no auto-login, so if a laptop is stolen, the drive can only be wiped, no data can be accessed, what more do most small companies need?
From my searching around, there appears to be some script I can run to disable this computer by computer-- I just want something in the Jamf config profile to forget the whole feature, or at minimum set the password to blank automatically, nothing I need to remember to do each time. Is there any way to do this?
Apologies if I just missed something obvious somewhere. I would not be surprised.
Thanks
Solved! Go to Solution.
04-11-2023 10:09 PM - edited 04-11-2023 10:14 PM
It is in the prestage.
There is a checkbox to Set Recovery Lock and then a drop-down to select if you want the auto-generated code or a single manually enterable code to apply to all computers.
So I would go turn that off there if you don't want it set on Macs you set up in the future.
For the Macs you have already deployed, you will need to use a script to make API calls to remove them.
Here is a really good one https://community.jamf.com/t5/jamf-pro/m1-m2-recovery-lock-management-script/td-p/279965
04-11-2023 10:09 PM - edited 04-11-2023 10:14 PM
It is in the prestage.
There is a checkbox to Set Recovery Lock and then a drop-down to select if you want the auto-generated code or a single manually enterable code to apply to all computers.
So I would go turn that off there if you don't want it set on Macs you set up in the future.
For the Macs you have already deployed, you will need to use a script to make API calls to remove them.
Here is a really good one https://community.jamf.com/t5/jamf-pro/m1-m2-recovery-lock-management-script/td-p/279965
Posted on 04-11-2023 11:20 PM
Oh, wow, I appreciate this so much-- there's the setting in my prestage enrollment as you said. I determined that only computers enrolled in the past few months have the setting enabled, so did I or possibly a former co-worker who was an admin in our Jamf change the setting/check that box? Or did Jamf at some point make it the default?
In any case, it might be tolerable if you could adjust the random password length, as ~40 digits are just too many to type into a different computer (i.e. no copy paste is possible).
Since the options are 1) random ~40 digits, 2) manual pw (same on all computers, not ideal if you have to give it out to a remote worker), or 3) "off," I guess I choose "off." Seems like there's room in there for compromise, dear Jamf?
Again, I appreciate the response. My searches only returned the script/API method (which I have never used much) but no info about this being in the pre-stage (again, probably my fault/poor search).
Thanks!
Posted on 04-12-2023 06:05 AM
@tony_schaps , I looked in my Jamf server and the setting was NOT enabled. I even clicked on "New" in the page showing the pre-stage enrollments and the checkbox to enable it was not checked. Just letting you know. Sometimes that kinda stuff drives me crazy. Good luck.
Posted on 04-12-2023 10:11 AM
Thanks so much-- I don't believe I would have checked that box without doing a lot of research, but I am glad you both responded to set me straight. Cheers!