I have some users in China who are way out of my reach, but their Macs are managed by our JSS. Before we got them into our JSS, these users took it upon themselves to install Windows via Bootcamp. Now, some of them are running out of storage in the Mac partition. Also, these Windows installations were unauthorized. I know we can prevent future Bootcamp installs by blocking the Bootcamp setup assistant from launching, but how can I prevent them from booting into Windows until they each remove the Windows partitions? This is a security issue because while they're booted into Windows, I have no ability to lock those systems down if they're lost or stolen, or if my customer decides to terminate one of these employees. I was not informed about these Macs being purchased until AFTER they were already setup.
If there isn't a firmware password set up already on them, you could, I think, enable a firmware password to block that. If I'm not mistaken to boot into Windows with BootCamp you need to hold down the Option key at boot, correct? If so, a firmware password blocks an option boot until the password is entered. If they don't know it they won't be able to get past that and would need to shut the Mac down and boot back up into OS X.
You can set up a policy in the JSS to deploy to these Macs to enable a Firmware password for them. I believe it would only work if there isn't already one set up though, since its not possible to set a new FW password if one is already set without knowing the existing password.
Hope that helps.
But wouldn't they need the firmware password to boot to the Mac too? It has been a really long time since I have worked on a Mac with a firmware password, so forgive my ignorance on this. I suppose I could grab a spare Mac and test this, but if you could clarify, that would be much easier :)
The one downside of the Firmware pass is that you can't boot up in Safe Mode (among others) either.
Sometimes a good Shift at startup can help someone clear things out and this will disable that.
If you use other means to clear caches, etc. then it's not a worry.
Whenever I travel, I make sure my Macs have this enabled just in case...
@hisaacks if your users are admin users, they can use Startup Disk to choose to boot to the BootCamp partition and the option key and firmware password will not affect their ability to boot the system to Windows. It may not be common that your end users have admin privileges, but I thought I would mention it.
If you use a Profile and lock out Profiles Pref Pane, it's way more difficult. If someone is smart enough they'll bypass anything, but you can't cater to that crowd - just send their management/boss an email. That can have a positive impact. There's a fine line between managing and babysitting.
Thanks for all of the suggestions. This is why I love JAMF Nation and Casper. I think what I'm going to do is reach out to the person in charge of this team and have him tell them all to remove the Windows partition. After they do that, I will setup a restriction to prevent them from using the Bootcamp setup assistant. I'm nervous about setting a firmware password on systems that are thousands of miles outside my reach. I'm trying not to be too heavy handed on this. Doing that could make them want to look for ways around the restrictions. I have the Profiles preference pane locked out to prevent the removal of the MDM profile, and none of them should be aware of the hidden management account, or where the JAMF binary is installed. I could demote their accounts to Standard users if needed as well.
Yes, if they are admins in all honesty they could figure out how to unmanage their Macs entirely. But aren't we getting into extreme cases here? The point is, with a firmware password in place and a configuration profile to deter access to the Startup disk pref pane, it's going to stop the majority of users. If some of them still find a way around it at that point it becomes an HR/Manager/disciplinary issue, not a technical problem.
You could always do something brute force like craft a script to get the BootCamp partition name and wipe it completely. They are, after all, unauthorized Windows OSes and you're trying to prevent a security issue. Right?
@hisaacks personally I think having the person in charge of the team request the removal of the Bootcamp environment is the right call. If it was an unauthorized installation then it should become an HR issue if their supervisor is unable to get them to comply with the request to remove it. All too often these kinds of issues become problems for IT when they really shouldn't be.
@mpermann Agreed! I hate that I have to constantly send out CYA emails when I discover something like this so that I won't get blamed when something goes wrong. I wasn't allowed to get these Macs into the JSS for many months, and now that I have them setup, I'm finding out a lot of things have been going on without my knowledge. One user will not respond to my emails informing him that his SSD is getting full (because he split it in half to install Windows). I guess I could just lock him out to get his attention :) Sometimes, we have to do things like that to get someone's attention when they're ignoring us.
@hisaacks Let me ask you, is there any IT staff out at the location where these Macs are used, or are these users essentially on their own? If its the former, you could give local IT staff the firmware password in the event of any boot issues, with clear instructions to never give it to a user. If they are alone with no local support, then I can completely understand the concern with putting a fw password on them. As mentioned above, it does put a snag in things because it means users can't self resolve issues by booting to Recovery HD and running a disk repair for example.
We're required to have them on all our Macs since they are 99% laptops and our security office is adamant about it, but it does hamper things for those remote workers who run into problems. The problem is that without one in place, it allows someone with enough Mac technical skill to boot the machine from another volume and try to gain access to data stored on the HD among other things. FileVault encryption does prevent that for the most part, which we also use, but the combo of both in place means the machines are well protected, so for now at least, it remains.
As an aside, its unfortunate that Apple hasn't developed a special firmware "mode" where Recovery HD and maybe Safe mode could be used without needing a password, but still prevent removal of the fw password or booting from an external disk unless you knew the firmware password in the first place. That would be ideal, and we actually put in an official request with Apple to look into that, but that was years ago and I don't think they will ever do it.
@mm2270 No. There is no IT staff there. These users are on their own. They're contractors who work for one of my customers. My customer does a lot of manufacturing in China and in Taiwan. I also plan to institute FileVault. I already have that setup in the JSS. It's just a matter of scoping it to these users so that it's available to them in Self Service. I don't want them setting up themselves. I want the recovery key stored in the JSS. I agree with you about Apple needing to develop a special mode that would allow the use of the Recovery HD.
OK, then yes, I do see your concern. If one of them has a boot issue that would necessitate booting to Recovery HD to run a fix, you're in a pickle.
I would go ahead with the plan to get FileVault enabled for them, as that will add some level of security. Sounds like right now these Macs are a security nightmare for you. No firmware pass, no FV2, running an unauthorized and probably unprotected copy of Windows in BootCamp. Yikes. Are they even using any type of directory service based accounts to log in with, or are they local accounts?
As for FileVault, I suggest looking into two things to go along with it
One is Recovery key redirection in the JSS, which helps in those cases where someone decides they want to set up FileVault manually. If done right, the local fdesetup policy applied will pick up the key and redirect it to the JSS for escrow instead of it not being escrowed and presented on screen to the user. So it puts some peace of mind there for you for that.
Second is, look into applying a Config Profile that prevents disabling FileVault from the GUI. If you search around here on JN you'll find some posts on it. A link to a full profile example was posted by Greg Neagle on one of the threads I believe. This grays out the "Turn Off FileVault" button in Security & Privacy > FileVault. It doesn't stop them from using Terminal to turn it off (if they are admins), but nothing's perfect.