Enable Local Admin created during prestage for FileVault on user login

[QSLogan]

I have done my due diligence to find an answer to this across this forum and the internet as a whole and I am stumped. Basically, I want an out-of-box experience for the end user, and that's all working great. The problem is, since the user enables FileVault when they sign in, the local admin account is not FileVault enabled, meaning if a machine is powered off, I can't log in without the user being there to sign in. I know I could use the recovery key to get in, but I'd rather avoid that if possible.

I considered using fdesetup, but given that it will be a different user setting up FileVault every time, there's no way to automate adding our local admin account as a FileVault approved user since fdesetup requires the password of an account that already has FileVault access.

Basically, my end goal is 

1. User logs in for the first time

2. User is prompted to enable FileVault, and does so.

3. Using current logged in user, add local admin as a FV2 enabled user

Is this possible in any capacity? 

[Hugonaut · Accepted solution]

In Short, what you need to do in order to achieve this is you need to prompt the end user for their password credentials & pass that information via a script to automate the enablement of filevault for your local admin account.

This is because the End User is the first Filevault enabled user, they are the Secure Token Holder. The End Users creds are dynamic so they would need to be pulled per user per login (Once Per Computer) & the local admin accounts creds being static could be easily scripted into the equation. Thus allowing the automated enablement of the local account to be fv2 encrypted. Given the sensitive nature of passwords, its advised that the end users password is encrypted or passed to the script with a form of encryption.

[Hugonaut · Accepted solution]

In Short, what you need to do in order to achieve this is you need to prompt the end user for their password credentials & pass that information via a script to automate the enablement of filevault for your local admin account.

This is because the End User is the first Filevault enabled user, they are the Secure Token Holder. The End Users creds are dynamic so they would need to be pulled per user per login (Once Per Computer) & the local admin accounts creds being static could be easily scripted into the equation. Thus allowing the automated enablement of the local account to be fv2 encrypted. Given the sensitive nature of passwords, its advised that the end users password is encrypted or passed to the script with a form of encryption.

[Tribruin]

Just my $0.02 worth, but I do NOT recommend enabling an admin user that is on every computer for FileVault. This is a huge security risk. Unless you have a built in LAPS solution that creates unique passwords for each computer (and rotates them), every computer will have a single password that gives a user with the password full unrestricted access to every computer in your fleet even if the computer was turned off or restarted.  This is especially important for remote users. If they lock themselves out, you would be giving the user the master password for every computer. 

Honestly, I don't find using the PRK very difficult. I wrote up a simple one page document and have walked a few of my support team through the process. And, for techs used to "just change the password in AD", they picked up really quick. 

[mm2270 · Accepted solution]

It's possible to do this, as @Hugonaut outlined above, but I would seriously ask yourself if this is best practice.

The main issue I have with adding that local admin account into FileVault is that you have now potentially created a master "unlock key" for every encrypted Mac in your organization, especially if that username/password combo is static across all the systems. This actually lessens the effectiveness of FileVault encryption in my opinion. If that password ever gets revealed or compromised, it opens up all those devices to being compromised until the password is changed.

This can be mitigated a bit if using something like a LAPS solution, but introducing LAPS when FileVault is in the mix adds other complications, since you can't script updating those local admin passwords and expect FileVault to know about the new password. It just won't know. There are some advanced Mac centric LAPS solutions out there that can account for this, but you are adding a lot of layers of complexity to your environment by doing this.

Anyway, the above is all just my personal opinion on things. I just think the best practice is, in a 1 to 1 scenario, single user enabled for FV2. And end it at that. If they forget their password, that's what the Recovery key is for. And under some circumstances it can be effectively used by an admin to get into a machine that's just been booted up.

[Hugonaut]

---

@mm2270 wrote:

 I just think the best practice is, in a 1 to 1 scenario, single user enabled for FV2. And end it at that.

---

Agreed

[QSLogan]

Fair enough. We have LAPS on our windows machines, and it's an unbelievable pain even without the complexity of FileVault. I'll take your advice on it and just use the recovery keys to unlock devices. I guess in fairness, most of the cases we needed to sign into the admin account were removed by having jamf anyways, so it's probably going to be less common that we even need to get into a powered off machine. Thanks for the input!