Deleting Ghost FileVault Accounts without completely turning off FileVault

[mmazzamuto]

Hi,

We have been migrating macs across the company and after running scripts to reACL local home folders to the new AD account, we noticed that we need to re-enable the FileVault user in System Preferences.

The problem with this now is that the user sees two FileVault enabled accounts (with the same username) on the initial screen at boot.

After a bit more digging (using the fdesetup list and fdesetup list -extended commands) I can see that the old account is still visible with a UUID but no name associated.

For example...

1) Running 'sudo fdesetup list' displays.. (null),EBADDBBC-FB36-4A95-8D74-DACA5FE23281
2) Running 'sudo fdesetup list - extended' displays.. ESCROW UUID TYPE USER EBADDBBC-FB36-4A95-8D74-DACA5FE23281 OS User

So the User field is blank.

I know i can run "sudo fdesetup remove -uuid EBADDBBC-FB36-4A95-8D74-DACA5FE23281" , but to do this for everyone will be time consuming as obviously the UUIDs will be different.

Is there a way i can target the "(null)" account for removal so i can push the script to multiple macs?

I have attached a screenshot from terminal (blanked out usernames for obvious reasons.)

Thanks!

[DBrowning · Accepted solution]

you can run "sudo fdesetup sync" and that removes the UUID with (null) as the username. I too have recently changed domains after a company bought us. Let me ask you this... are you just having an encryption policy run again to add the new AD account added to the filevault users? the encryption policy i have is set to run once per user per computer. Since its the same username in the new domain, the policy doesn't run again.

[mmazzamuto]

Hi ddcdennisb,

Thanks for your response, that worked like a charm!

We are not re-deploying the encryption policy, we are just enabling the user in System Preferences > Security & Privacy > FileVault > 'Enable Users' after our migration scripts have completed.

We are also moving to a new casper environment also so our process is as follows:
1) Remove Management and Delete Object in old environment.
2) Recon onto new.
3) Run migration scripts via self service.
4) Login an check all is fine.
5) Re-enable user for FileVault (as mentioned above).
6) Run the FileVault Reissue script from Jamf. - to generate new recovery key.

Not sure if this is the best way but works well for us.

[DBrowning]

Funny we are doing the same exact thing. New Domain and new jamf server. We aren't doing both at the same time, and our domain change is all scripted/automated. Since we are doing over 1000 users. Was hoping there was an easy way to add in the "new" ad account since I now have 600ish computers that are encrypted but the FV password is out of sync with their login password.

[Yaneev]

@ddcdennisb We have reset the newAD users passwords to random passwords, uploaded them to Jamf as an extention attribute and scripped it to add the user to FV

#!/bin/sh

## This "expect" block will populate answers for the fdesetup prompts that normally occur while hiding them from output
    expect -c "
    log_user 0
    spawn fdesetup add -usertoadd $NEW_AD_USERNAME
    expect "Enter a password*"
    send ${adminPass}
    expect "Enter the password*"
    send ${NEW_AD_USER_PASSWORD}
    log_user 1
    expect eof
    "

[DBrowning]

@Yaneev Thanks. I started looking at using expect this morning and have put together a process that can be run through self service. I was over thinking things earlier. Thanks again