Posted on 01-06-2014 07:47 PM
I created a policy that would auto-create/re-create a local "admin" account in the event that an end user decided to delete the original local admin account.
The account gets created but fails to add to FileVault.
When I run the policy, I receive the following output:
MySystemNameHere$ sudo jamf policy
Checking for policies triggered by "recurring check-in"...
Executing Policy Create IT.Admin Account...
Creating user itadmin...
Adding user itadmin to filevault
Error adding user to FileVault: Added users failed error.
Submitting log to https://jss.myjamfjssurl.com:8443/
My policy's "General" options are as follows:
Display Name: Create IT.Admin Account
Enabled: Checked
Category: 02 - Pre-Flight Configurations
Trigger: Recurring Check-in
Execution Frequency: Ongoing
Make Available Offline: Checked
My policy's "Local Accounts" options are as follows:
Action: Create Account
Username: itadmin
Full Name: it.admin
Password: **
Verify Password: **
Home Directory Location: /Users/it.admin
Password Hint: <blank>
Account Picture Location: /Library/User Pictures/Animals/Eagle.tif
Allow user to administer computer: Checked
Enable user for FileVault 2: Checked
Scope:
Targets: All Computers
Additional Notes:
On going policies check in every 30 minutes.
Target systems are running Mountain Lion or Mavericks.
Running JSS 9.22
Any ideas as to why this user is failing to auto-add to FileVault2?
I can manually add the user through System Preferences -> Security & Privacy -> FileVault
Thanks!
Posted on 01-06-2014 07:53 PM
What is it saying in the system log? Has this local user been added to FV2 before?
Posted on 01-06-2014 08:01 PM
Yes - the it.admin account existed prior and was a part of FileVault prior as well.
The idea is to create the user on systems that didn't have the it.admin user prior or to re-create the it.admin user if an end user decided to delete it.
According the "Creat IT.Admin Account" policy log...
Executing Policy Create IT.Admin Account...
Creating user itadmin...
Adding user itadmin to filevault
Error adding user to FileVault: Added users failed error.
Posted on 01-06-2014 08:45 PM
Is this 10.9 or 10.8? Also what does it say in the local machines /var/log/system.log at the time when you try to add the account ?
Posted on 01-07-2014 07:32 AM
How is your FileVault 2 disk encryption config set up? Are you using the management account as the primary FV2 account on the box? I'm not familiar with the "Enable user for FileVault 2" option you mentioned. This must be something new in Casper Suite 9, or perhaps only shows up if using the management account as the first FV2 account added to the system.
I have a suggestion, which is, after the account is created and added to FV2, consider changing the account UID to be below 500 and also setting MCX (or use a Config Profile) on your Macs so sub 500 accounts don't show up in the Users & Groups preference pane. That way users won't feel compelled to delete the IT Admin account and the home directory for the account won't show up under /Users You'll still be able to log into the account locally, use it for ssh (if you need it for that) and authentication, etc. It just won't appear to the end user other than at the FileVaul pre-boot screen (still no way around that) and so they likely won't go searching for it to delete it.
Rich Trouton has a blog entry on exactly how to do this, Take a look:
http://derflounder.wordpress.com/2012/02/22/hiding-an-filevault-2-enabled-admin-user-with-casper/
I know that doesn't solve your immediate issue, but it seems like the sole purpose of your policy is to work around the issue of an IT use account being deleted by end users. Eliminate, or at least greatly reduce the possibility of this happening and the need for such a policy will probably vanish.
Posted on 01-07-2014 10:36 AM
Mike makes a good point about hiding the user to help reduce the likelihood of this scenario in the fist place. However, in the event we run into this scenario, the requirements for enabling a new user, specifically the management account, are a 10.9+ client OS and a valid individual recovery key stored in the JSS. If either of these requirements are not met the policy will fail.
Apple added a few new enterprise friendly features in 10.9 with the fdesetup binary that allow the JSS to better report and interact with FileVault2 encrypted machines.
Posted on 01-14-2014 10:49 AM
@ClassicII - Haven't looked at /var/log/system.log ... yet - On my next round of testing in the lab I will check that out.
@mm2270 - Thanks for the tips - I will look into those - especially adding the user below UID 500.
@Sam.Fortuna - We are 10.9.x - FileVault2 is using an institutional recovery key stored in JSS. We do not use individual keys.
Posted on 01-14-2014 11:03 AM
Since you're not using an individual key it will be impossible to add an additional account via the JSS with built-in functionality. Creating a new local account or simply enabling the management account for FV2 requires that a valid individual key be stored in the JSS. Perhaps you want to consider using both an individual and institutional key in the future.
Posted on 11-19-2014 11:10 AM
Sorry for bumping this but i'm having the same problem here on some machines.
Were you able to fix this and if so, how?
Posted on 01-07-2015 10:20 AM
We have machines exhibiting this behavior too. Haven't found any symptoms. I did find, though, that on one of the machines trying to manually add the account to the FileVault 2 enabled users through System Preferences fails also.
Posted on 08-18-2015 01:37 PM
I'm also curious to see if there's a resolution to this before handing this over to support/support rep. I can add them to the 'enable user for FV' in system preferences manually, but I'd like to be able to do this via jamf when creating the new local admin account.
Posted on 08-18-2015 01:46 PM
From what I've found, this is happening to us because the FV2 key is being stored locally and not being sent to the JSS. So it's not actually getting the FV2 Disk Encryption Configuration you're deploying and instead just turns on FV2 and adds the local user as the FV2 user and that's it. Which means you can't add other users to FV2 on the machine because it's not using the configuration you attempted to push.
Why this happens is still a mystery to me. We have about 9 computers that have this problem. The rest work just fine. No common variables between the machines to cause the encryption configuration to fail on initial setup.
Posted on 08-18-2015 01:57 PM
Ahh makes sense about the FV2 being stored locally. This might turn into a little bigger project, but I guess we can turn off FV2 and then re-enable it via Jamf with individual keys being stored in the JSS. Not sure why only 9 of your machines has this issue but not the rest. Have you spoken to Jamf support to see if there's definitive answer to your issue?
Wondering what they have to say about it. I'm going to email them to get their best plan of action for this task.
Thanks emilykausalik :)
Posted on 08-18-2015 02:01 PM
So far we haven't found a root cause. And it's tricky because since the user is the FV2 user you have to rely on the FV2 user to unlock the disk, then try it again.
Posted on 08-19-2015 02:44 PM
@syunetsy Instead of turning off FV2 and re-enabling, you could try to reissue the FV2 key.
We've implemented the script found here from @elliotjordan & it has worked smoothly and saved us tons of time.
You need to set a config profile to "redirect FV2 keys to JSS" and then run the script. The script will prompt the user for their password and then escrows the key for you.
Posted on 08-19-2015 02:50 PM
@merps I've heard of this magical script but haven't tried it yet… putting it on my list of things to do.
Awesome, thanks for sharing!