Defer not working...El Capitan Upgrade issue

roiegat
Contributor III

So I've recently started testing the upgrade path for El Capitan and ran into and issue I can't really explain or fix with my knowledge...so figured I'd reach out to the borg collective here for assistance.

So in our current Yosemite build process we activate FileVault 2 using an input list. There are several account on there. When a user boots up there machine, they choose the one based on their role, and provide the password. Then they get to the login in window which they provide their username and password (AD credentials). In 10.10 This works great and had no issues.

So I created a El Capitan upgrade package like I did before for Yosemite. The test machines I've upgraded worked well as for as installing the new OS, but something changed with the FileVault 2. When the machine boots up we see the FV2 users list like normal, but when we select and put in the password - it logs us in as that account instead of taking us to the login window like before. The way I work around that currently is by logging off that account, which bring up login window and then logging in with AD credentials. But this can't be used when we deploy this to the masses.

So I put my thinking hat on and figured - why not add the user to the FV2 users. That way they log in once, and they get in with there account. So I started looking at the man page for the fdesetup command. I noticed that if I added a user, I needed their credentials. But if I use the defer method, it will prompt the user at logoff. I figured great, we set that up before everyone upgrades to El Captian and we'll be all good....until I tried it.

So the command I tried on two different machines was:
sudo fdesetup enable -defer /MyKeyInfo.plist

I also tried:
sudo fdesetup enable -user XXXX -defer /MyKeyInfo.plist (Where XXX is the username)

No matter how hard I tried, it never prompted the user for their credentials and never turned of FV2 for them. It just acted like nothing ever happen. I tried this both on Yosemite and El Capitan, so I suspect something from Casper might be not allowing it to happen.

So question time:
1) Why did the El Capitan create the accounts for the FV2 users when they didn't exist before? Is there a way to kill those account from allowing login and make it go to the login window like before?
2) Why isn't defer command working?

Anyone else have similar issues in upgrading to El Capitan?

8 REPLIES 8

rtrouton
Release Candidate Programs Tester

It sounds like you have FileVault 2's automatic login process disabled on Yosemite, but you don't have it disabled on El Capitan. Here's Apple's KBase on how you can disable automatic login for FileVault-enabled accounts:

https://support.apple.com/HT202842

Also, are these Macs already encrypted? If they are, that's why fdesetup's -defer option is not working like you expect it to. An important thing to keep in mind about the -defer option is that it enables one single user account at the time of turning on FileVault 2 encryption. The -defer option does not enable multiple user accounts and cannot be used to enable accounts once FileVault 2 encryption has been turned on.

jhalvorson
Valued Contributor

If I follow you correctly, you want FV2 to wait for a user to input a password. Once the fv2 password is correctly enter, continue with the OS bootup, but stop short of loading the desktop to allow a different user account and password. If that is the case, you want to set the FDEAuotLogin value to be YES.

Here's is a script from @rtrouton that can be used to set the value.

#!/bin/bash

# REF:  https://github.com/rtrouton/rtrouton_scripts/blob/master/rtrouton_scripts/Casper_Scripts/self_service_os_install/elcapitan/self_service_elcapitan_os_install.sh

osvers=$(sw_vers -productVersion | awk -F. '{print $2}')

   # Checking for FileVault 2 encryption. If found, set FileVault 2's automatic login to
   # be disabled. 
   #
   # The reason to do this is that when upgrading a FileVault2 enabled Mac to 10.10, 
   # automatic login should  be disabled  when installing additional packages at first boot. 
   # If automatic login is not disabled, the additional packages will be skipped over.

   if [[ ${osvers} -eq 7 ]]; then
    ENCRYPTION=`diskutil cs list | grep -E "Encryption Type" | sed -e's/|//' | awk '{print $3}'`
       if [ "$ENCRYPTION" = "AES-XTS" ]; then
           echo "FileVault 2 is enabled. Enabling FDEAutoLogin."
           defaults write /Library/Preferences/com.apple.loginwindow DisableFDEAutoLogin -bool YES
       else
           echo "FileVault 2 is not enabled."
       fi
   fi

   if [[ ${osvers} -ge 8 ]]; then
       FDE=`fdesetup status | grep "Off"`
       if [ "$FDE" = "" ]; then
           echo "FileVault 2 is enabled. Enabling FDEAutoLogin."
           defaults write /Library/Preferences/com.apple.loginwindow DisableFDEAutoLogin -bool YES
       else
           echo "FileVault 2 is not enabled."
       fi
   fi

exit 0

roiegat
Contributor III

@rtrouton I'll check the settings. But I don't think we have automatic login in with El Capitan, since it still required the user to provide the password for the initial account. But I'll double check it. Would be odd that got turned on for some reason.

And yes, all these machines are already encrypted. Figured I could just add the user account to the FV2 users so they would see that at the boot up window and login with that. Is there a way to add FV2 users after the machine is encrpyted?

roiegat
Contributor III

Just ran a little test on El Capitan machine. I did a:
defaults read /Library/Preferences/com.apple.loginwindow DisableFDEAutoLogin

And it wasn't able to find the variables. So I did the following command:
defaults write /Library/Preferences/com.apple.loginwindow DisableFDEAutoLogin -bool YES

Then I did the defaults read /Library/Preferences/com.apple.loginwindow DisableFDEAutoLogin again and got: 1

So then I rebooted. Boot window came up with the roles. I selected my role and provided it password. And it still logged me into that account instead of the login window.

rtrouton
Release Candidate Programs Tester

@roiegat,

FileVault 2's automatic login process is the default behavior. By default, a FileVault 2-enabled account logs in at the pre-boot login screen and is then taken straight into their account. There is not a second login at the OS login window unless a setting is put in place to disable the FileVault automatic login process.

You can add users to a FileVault 2-encrypted Mac, but it's a more involved process. I have it detailed here at the link below:

https://derflounder.wordpress.com/2015/12/20/managing-el-capitans-filevault-2-with-fdesetup/ (see the "Adding Additional Users After Filevault 2 Has Been Enabled" section)

roiegat
Contributor III

@rtrouton

It makes sense that it's the FV2 default behavior, but I wonder why it worked on Yosemite. Will keep looking into it.

I checked out the link which is amazing amount of information. Quick question though, is there defer method for -usertoadd?

You guys have given me a lot to think about. I appreciate it.

rtrouton
Release Candidate Programs Tester

@roiegat, there is not a -defer option for fdesetup's add function. The -defer option cannot be used to enable accounts once FileVault 2 encryption has been turned on.

roiegat
Contributor III

So did a lot of digging around to figure out why it worked in Yosemite and no El Capitan and found some stuff. Since I wasn't working here when the original method was created, wasn't sure why it worked.

So I started looking at all the FV2 scripts and packages and found something that is interesting. When the accounts were set up for the roles during the initial build, they omitted one part - the PrimaryGroupID. Becuase it was lacking this, it pretty much got past the FV, and then provided the login window.

Looking at the El Capitan machines, seems like the upgrade package didn't like that and added the PrimaryGroupID of 0 to both accounts. So that's why they were able to log in. Deleting the PrimaryGroupID account fixes the issue. At least for now....would like to redo the whole thing to make it a little more effiecient...but at least figured out the problem for now.