Migrating to new JSS instance - FileVault 2 keys

vinny83
New Contributor III

Hi All,

I'm in the process of setting up a new JSS instance in our environment to migrate to (from Server 2012 R2 to CentOS 6.8). We only have 150 clients and after reading many of the threads here, moving to a new instance doesn't appear to be a big deal. Especially as it lets me tidy up policies, groups, clients, etc that have become stale.

However, as we use individual FileVault 2 keys per Mac, its now occurred to me that we have stored all the keys in the old server's DB. What is the best way to migrate these out (if possible)? Or would we have to generate new keys for every encrypted Mac? We are running about 35 percent El Cap and and rest are Yosemite.

Thanks
V

1 ACCEPTED SOLUTION

dgreening
Valued Contributor II

There is no way to export FV2 keys as this would be seen as a serious security risk.

In order for the JSS to be able to generate a new FV2 key the management user MUST be enabled for FV2. We use this functionality in production and it works great as long as the management user is added.

View solution in original post

12 REPLIES 12

sgorney
New Contributor III

If you migrate the mySQL database as well, the individual keys will come with it.

vinny83
New Contributor III

Unfortunately, we're trying to avoid doing that. We're trying to start from a clean install and import things that we need from the old server. The clients will all enrol to the new instance via a policy from the old server.

I know that 9.92 introduced an option to generate a new FileVault key, which will work for some clients - but not all. My questions I guess is asking more if there is a way to export the FileVault keys and the machine associations.

mm2270
Legendary Contributor II

No, there's no way to export FV2 Recovery keys, either in a static list/csv form or in a database format that you can import back into the JSS. If you're starting over with a new database, you're going to need to re-issue all your Recovery keys because it won't be possible to migrate them into the new one, without doing a wholesale db migration.

dgreening
Valued Contributor II

There is no way to export FV2 keys as this would be seen as a serious security risk.

In order for the JSS to be able to generate a new FV2 key the management user MUST be enabled for FV2. We use this functionality in production and it works great as long as the management user is added.

View solution in original post

vinny83
New Contributor III

I had a feeling it wouldn't be and the security reasoning makes sense. I'll snapshot the VM and then import the DB to test against. Although we don't have a huge number of clients - our users, like many others, are very difficult to get their Macs back for something as simple as generating a new key.

@dgreening, I thought of that too but like our Windows clients, we don't allow the management user in FileVault 2 for security reasons. We can't have a local account (where the password doesn't change often) to have access to unlock a drive that leaves the building.

Thanks all

mm2270
Legendary Contributor II
We can't have a local account (where the password doesn't change often) to have access to unlock a drive that leaves the building.

Same reason we don't enable the management account for FV2, and since Apple doesn't allow accounts enabled for FV2 to be hidden on the login screen…

iJake
Valued Contributor

What are you trying to avoid by NOT migrating the DB? There are plenty of tables that could be purged while maintaining computer records and associated keys if you want to reduce bloat.

vinny83
New Contributor III

We've seen odd behaviour from the old server and the DB - a few tickets have been raised in the last 6months with JAMF support. Performance recently dropped right down and we found the Tomcat instance was running but not accessible - full server reboots fixed this.

I had suggested to my manager that maybe we could start a fresh and migrate clients over slowly. I've now migrated the old DB into the new server and will just go through it thoroughly and purge all the guff we don't want or need.

iJake
Valued Contributor

If you're not running MySQL 5.6 I highly recommend upgrading to it. We were having sever performance issues until we upgraded. Aside from the JSS being optimized for it it is a very noticeable upgrade from 5.5 and lower

bmarks
Contributor II

Here is a guide for how to proceed. We purposely migrated our database due to a forced URL changed, and this worked for 15,000 Macs:

MacBrained Reissuing FileVault Keys

Your TAM may directly provide you with this link and its associated script as well.

merps
Contributor III

Here's another vote for the MacBrained solutions suggested by @bmarks .

We used it to transition machines from being manually encrypted to escrowed in our JSS.

vinny83
New Contributor III

@bmarks, thanks so much. We have a similar but much more basic version of that process that we used to originally enrol encrypted Macs to the original Casper instance. This looks much cleaner and nicer from a user point of view. I'll give this a go too - we're still a few weeks away from migrating the new server to production.

Thank you again all for your suggestions.