We didnt at first due to the pain in the rear that it can cause. But quickly found out we had to because children booted up and gave themselves root access, removed software, or reformatted their computers.
So everyone has firmware passwords.
Thanks for the quick responses.
I think when we attempt to image things remotely, I will simply run a command to remove the firmware password so the remote user can image their systems. We have someone who used to be in our IT department wanting to re-image a laptop and it has a firmware password. It occurred to me this summer we will be doing more and more imaging. It would be great if we can grant a few users the ability to netboot so they can image. As it is, no one outside of a couple of us know the firmware password.
I was trying to create a workflow for this. Without the firmware password things are relatively easy. With it, this just adds a level of complexity. Removing it for those we are touching is easy enough, I was just thinking it through.
@boberito I didn't know you could use the option key, then at the boot loader screen use the Command R or Command S keys. We have been trying to get around this for a while and I was under the understanding the firmware password had to be removed first. I need to test this one as it could be a life saver.
I'll have to experiment on that some more. I can net boot and do recovery with no issues, but I had trouble with target mode and just sort of worked around it and haven't revisited. Maybe I have a dud cable or bad thunderbolt port on the Macbook I typically use in those cases.
At any rate, the reasons you list are pretty much exactly why we too put firmware passwords on everything.
We have firmware passwords and I do just that to get around it. It's an extra step which is only obnoxious when mass re-imaging.
So it SHOULD work.
We also decided that if a machine is stolen it's a layer of protection. The thieves won't know the login so they are potentially locked out. They won't know the firmware password so they can't reset it. On the important people (not students) we do FileVault so at that point it's so locked down that if stolen, it's a legit paperweight. They wouldn't be able to remove the HD and steal info and they wouldn't be able to install a new HD and boot.
@boberito Thanks for the reminder on the other modifiers being selectable on the boot picker screen. A question though, have you actually tried putting an EFI locked machine into TDM this way and then re-imaging without problems booting afterwards? It's been over a year since I tried it, but I have a recollection that this would result in an imaged machine without a blessed boot volume.
I do it all the time.
Maybe just throw the bless command into a script that runs at FirstBoot? I think at one time I did that, I cant remember if the culprit was the Mac OS version or the casper imaging version at the time. But I don't have that in our current image (just looked in fact)
Looking now it looks like the systemsetup -setstartupdisk "/Volumes/Macintosh HD" would be how you do that. Maybe give that a shot in the FirstBoot.
@boberito That round of imaging I did with DeployStudio, so it may well have been an OS issue. The
systemsetup command would select the boot volume, but I think you'd have to bless the volume separately with a
bless --mount "/Volumes/Macintosh HD" --setBoot (I don't recall for sure, but I still have that command in my EFI enforcement policy)
@boberito I just remove the recovery partition during the imaging process. While they can still mount and format the drive, I'll know they did because the machine will no longer check in. Only have had one student savvy enough to do this. We have our equipment on lease so this makes the return process easier.
We did the same thing originally back in 2012 but there's still Internet Recovery mode they can boot into and get root access or reformat. The ones that reformatted I caught pretty quickly. But the root level ones took a while. Legit, it took until a teacher mentioned that a student wasn't able to be monitored in class. So I used Apple Remote Desktop to watch the student and saw him uninstalling it. It was set to reinstall at Log Out if it detected it wasn't installed. So everyday he was uninstalling it.
Prior to locking things down with an EFI password I created a Smart Group triggered by an EA that lists any local admin accounts that aren't one of the usual ones. If a student "promoted" themselves to an admin account I'd get an email that there's a new member of the Smart Group and the student gets a call to visit with school administrators about violating their computer usage agreement. Not 100% foolproof since they might change one of the usual ones, but that wasn't a problem the few times it happened before turning on EFI passwords.
This is another piece to the EFI Firmware process we use in the School District of Milton. We use an extension attribute to report which devices have an EFI password set.
if [[ "$FWPassCheck" =~ "Yes" ]]; then
elif [[ "$FWPassCheck" =~ "No" ]]; then echo "<result>Not Set</result>"