I have been doing some research into FV2 to see what it would take to encrypt all of my machines, but all of the information seems tailored for use in single user environments. What about multiple user environments?
I have a lot of machines that are "public use," meaning that any faculty, staff, or student affiliated with my university can sit down and login with their AD credentials and get access. Given that many of these are part of a laptop checkout program, I would like to enable FDE in case they wander off.
Is anyone else using FDE in an environment like this? How did you do the setup? Did you face any challenges along the way?
It can work.
Two different situations. First is a lab enviorment, you could have an IT admin account and that would be your account. The thing you dont want is the user to reboot the lab machine. As long as they dont reboot you will be fine. You could put controls in to prevent that too. If they do reboot the machine they can call the helpdesk and you could provide the user with the individual key. I would only recommend this for 10.9 and latter as you can then send the command to change the key after you hand it out.
In the checkout type system. You could also have an admin account and have the user encrypt the machine. When it is returned you could do a few things. If you wanted you could then delete the previous users access in FV2 and then have the new user log into the machine on the network before they leave to check it out again. That user would then be a authorized user.
Just some ideas and look forward to hear how others may tackle this issue too.
Unfortunately, neither of those scenarios will work well for me. I use the term lab environment loosely as they aren't in a classroom, but they are setup as if they were. They are in open spaces where anyone can plop down and login, and they are rarely supervised. It a hard balance trying to keep them locked down so they remain identical while trying to keep the feel as natural as possible so people can "just sit down and get to work". (I'm in a University Library, BTW).
My problem with laptops is that they are only checked out for up to a day. The staff performing the checkouts are non-technical and are about as hands-off as could be. I'm hoping to come up with a solution that wouldn't require any workflow changes for the staff.
Because it's a checkout program, do you "refresh" or reimage the machine between use? I can't even begin to imagine the data privacy issues that you could run into without that process.
If I'm not mistaken, how it should work in theory, if you have AD accounts, if you login as one AD account and enable that in FV2, any subsequent AD login should auto add to the FV2 users login screen.
Enabling FDE will lock down the data, but it doesn't prevent someone from re-using the computer unless you lock down boot options as well (and assuming they don't take the HD out).
No, they are not wiped in between use. The users do not get admin access, they don't leave the building, and it is common knowledge that a restart wipes user data on the laptops. (See my post in https://jamfnation.jamfsoftware.com/discussion.html?id=5042).
Either way, I'm beginning to think that this just isn't going to be possible in this type of environment. I don't want to create extra work for the staff (read not "my" staff) and I don't want to cause my users any extra stress or confusion by not being able to boot these devices.
Ah I see. Hm.
I don't know how it is in WV, but in MA, the penalties for losing an unencrypted device with personally identifiable information is very high. And if these are being used by anyone with medical record access, HIPAA applies and those penalties are pretty stiff as well. Wiping home folders doesn't cover the penalties with those regulations unless it's a secure wipe.
Actually I can't think of any encryption product that actively uses LDAP to decrypt a drive, it's all based on cached credentials. That would be pretty cool though, if you could make the initial boot partition bind to LDAP, and then have that decrypt drives. I smell a $$ making opportunity here.
@Rich, thanks for that info. Wow, that sucks and is really lame on Apple's part. I think enterprise admins all understand the inherent risk of a user's password changing outside of being done in the OS, like in AD, etc. Its been this way for a long time now, so b/c of that, Apple doesn't want to be bothered? And I thought they were starting to come around to the enterprise a little. Guess not. :/