Automatically adding a local IT Admin account to FileVault without IT having physical access to the Mac

[cainehorr]

NOTE: This is a work in progress. Suggestions and commentary are ALWAYS welcome!

I'm sure most JAMF admins have had such directives before. But I won't be discussing everything here.

This thread's purpose is to discuss how I am adding my local IT admin account to FileVault without IT having physical access to the Mac.

REQUIREMENTS:
1. Create a local IT admin account during JAMF enrollment
2. Enforce FileVault Full Disk Encryption for all local accounts without IT intervention

SCRIPT REMOVED FOR THE OVERALL GOOD OF THE COMMUNITY.

Thanks to a keen observation by Rich Trouton (@rtrouton), I've had to eat some crow. At least it was still warm!

I'll re-post an updated script once I've resolved the issue (assuming I resolve the issue).

Sorry to be such a let down today! :-(

In the mean-time, there seems to be some good info here:

https://jamfnation.jamfsoftware.com/discussion.html?id=14738

[rtrouton]

The main issue I see (aside from the plaintext password security concern) is this one:

6. JAMF will then reset the IT admin account's password back to the baseline via a policy during the scheduled check in process.

In order for the IT admin's password to stay in sync with FileVault, you'll need to provide both the old password along with the new password as part of the password change process. If not, the password that FileVault will likely be using is the randomly generated one; it won't be updated to use the new one which the JSS will be setting.

[cainehorr]

@rtrouton Interesting observation. I haven't seen this behavior (yet).

My testing included the following steps:

1. Run aforementioned script, thereby applying the newly generated random password
2. Manually run the following commands

sudo jamf manage -verbose
sudo jamf policy -verbose
sudo jamf recon -verbose

NOTE: As you can see, I like to be verbose!

1. Reboot
2. Log in to the ITadmin account using the password as set in the JAMF policy

I'll certainly keep my eye on it however.

Thanks for the tip!

[cainehorr]

@rtrouton

You my friend are correct (as always)! Did some more testing and sure enough, the randomized password was required on the FileVault login screen and the default password was required on the default login screen. Seems the keychain was borked a bit too!

Working to resolve the issue now.

So much for being clever! But at least I'm on the right track (I hope)!

[kitzy]

I have a solution to this. I'll write it up in a blog post tonight.

[kitzy]

@cainehorr as promised, here is my solution: http://kitzy.co/1QqjBTY

UPDATE: The link works now.

[dgreening]

That link is not working :(

[cainehorr]

@rtrouton

By the way - I did try the old | new password method - still didn't work as expected. Same results as just resetting the password.

I also decided to cut back the fat and try the following:

employeeSHORTusername="Something grepped up from the system"  # Yeah - There's more code behind this...
EmployeePassword="Something input by the user..."  # Yeah - There's still more code behind this too!
ITadminUser="WhosYourDaddy"  # Yeah, Baby!!!
ITadminPWD="GobbleDgook"  # This is also set in JAMF policy that created the ITadminUser
plistPath="/tmp/fdesetup.plist"  # Seemed appropriate.

I had set my JAMF policy that creates $localITadmin to use $ITadminPWD.

cat > $plistPath << EOF
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Username</key>
<string>$employeeSHORTusername</string>
<key>Password</key>
<string>$EmployeePassword</string>
<key>AdditionalUsers</key>
<array>
    <dict>
        <key>Username</key>
        <string>$ITadminUser</string>
        <key>Password</key>
        <string>$ITadminPWD</string>
    </dict>
</array>
</dict>
</plist>
EOF

Then we call the all knowing, all powerful fdesetup...

sudo fdesetup add -inputplist < $plistPath

Because $employeeSHORTusername is a local admin, they have the rights to add $ITadminUser to FileVault.

So now $ITadminUser is a part of FileVault and we are using the $ITadminPWD that is set in JAMF.

Seems good so far... But it's not so good...

So upon reboot, we log into $ITadminUser using $ITadminPWD and all is well with my soul.

Then JAMF runs a policy to reset the password for $ITadminUser. YAY for IT!

But on reboot...

We can't log into $ITadminUser using the new password. No sir. Nope. Not gonna happen.

We need to use the old $ITadminPWD to get past the FileVault screen then we need to use the new password to get into the OS Login Screen.

So I'm thinking it's something to do with $ITadminUser's keychain...

Perhaps having the script delete the keychain before the reboot would resolve the issue. It's a generic local admin account that serves no other purpose other than allowing IT a back door that doesn't rely upon an escrowed FileVault key that may or may not be accurate (yes, we've seen inaccurate ones).

Any thoughts from you @rtrouton or perhaps you @kitzy or anyone? Bueller? Bueller?

Thank's y'all!

[cainehorr]

@kitzy - Broken link buddy!

[bpavlov]

Yea the link is broken but you could copy and paste the URL into a new tab.

Or just use this:
http://www.johnkitzmiller.com/blog/how-i-deploy-filevault-2/

[stevewood]

@cainehorr I use a method similar to what @kitzy laid out in his blog post. The only real differences are:

1. I use a Self Service policy to enable FV after we walk new users through a password change and do their IT onboard training. Machine restarts, they log in and click enable, machine restarts again and they are at the FV pre-boot screen.

2. I use a fake receipt to scope a Smart Group against to enable our admin user (same user Casper uses) for FV. The fake receipt is laid down as part of the Self Service policy. A second policy enables the admin user the same way Kitzy does, via Casper's integration. This policy does not wait for FV to be completed, just for the machine to check in, and I've had no problems.

3. We use an institutional key, however after reading Kitzy's blog post, I may switch to using personal keys.

[stevewood]

Posted that too soon. I meant to also say that up until 10.10.5, I have had issues with the local admin account having its password changed via policy. Once the password changed, the FV password was out of sync. The only way to fix was to remove the local admin and re-add to FV, which required the password or recovery key.

I have seen this less and less since 10.10.5 was released, and I haven't seen it at all with El Cap.

[kitzy]

@dgreening @cainehorr whoops! Fixed the link.

[cainehorr]

@kitzy

Thanks for the write up!

Interesting approach. Unfortunately, I can't use the JSS service account for this as I've inherited this JSS infrastructure and must keep some things "as is".

I've also noticed that JSS doesn't always work as advertised when it comes to FileVault.

For example... I do have a policy set to automatically add the admin account to FileVault. It does. Sort of. But it still requires the admin account to physically login, open system prefs, go to FileVault and add themselves.

This is not ideal for remote deployments.

So while I can appreciate your write up, the overall workflow doesn't work in my situation.

I'm still studying what you've done in hopes of finding a way to get around this issues I speak of.

Thanks again!

[ooshnoo]

@kitzy Great writeup. Will definitely use for future reference. One question though...once the IT admin account is enabled for FV, does it still show up as a list of users at computer startup / login even though it's a hidden account?

That was one thing management didn't like in our previous FV pilots....simply knowing the IT username was considered a security concern.

[mm2270]

once the IT admin account is enabled for FV, does it still show up as a list of users at computer startup / login even though it's a hidden account?

Yes, it always will. Its the main reason we won't go with this approach. Our users are all admins. Its bad enough some of them will try anything they can to circumvent the system. Putting the management account in plain sight on the login window will just give them fuel to remove that account. No thanks. Until Apple ever figures out some way to change the FV2 login screen to Username and Password fields, we won't enable the management account for FileVault. Unfortunately, it doesn't look like Apple will ever be able to change the FV2 login panel, or at least they aren't interested in dedicating any resources into finding a way.

[kitzy]

@ooshnoo as @mm2270 mentioned, even hidden accounts will show up at the FileVault 2 pre-boot login window. There is no way around this. If having the name of the account visible at the login window is a security issue, then you have to decide if not having an account that can unlock FV2 is worth it. For some, having the recovery key may be enough of a "safety net" to get into the machine.

Personally I file this under "accept the things I cannot change" and get on with my life.

[nvandam]

I followed this this guide, but I'm finding that the Smart Group "partition not encrypted" is looking at other partitions, like backup drives or even a dmg, and then doesn't fall out of that Smart Group. Thoughts?