This write up is mostly a problem description, along with a conceptual solution which is working but being tested at the moment. This testing is being done with OS X 10.11.5 El Capitan.

A potential issue with FileVault encryption in an enterprise is that it requires user accounts to be added to FileVault in order to unlock an encrypted Mac at boot time. Unlock BitLocker, there is no way to allow the Mac to boot if hardware hasn't changed, or to set a universal pin for users to use. A potential solution to this is to create a generic account on each Mac that is added to FileVault, which would have its details shared with all Mac Users in your enterprise - this would be almost the same as an unlock pin or password, except that users would then be able to use that shared account to actually log in, which may or may not be kosher in your environment.

I have been working with Parallels Mac Management for SCCM and believe I have a solution that is, while not perfect, at least more enterprise-friendly.

Utilizing Parallels Mac Management, we can enforce FileVault encryption on Macs. This will cause users of the Mac to be notified that an administrator has forced FileVault to be set and that all users must neter their password to encrypt the Mac. This is confusing, and slightly misleading, as all users are not actually required to enter their passwords to continue, only one person needs to. The problem is, if Jane Smith is the only user that user enters their credentials at the time and continues through the process, only Jane Smith will be able to unlock the Mac the next time it boots up - so if Bob Ross were to come to work the next day and the Mac was off, he would be out of luck if Jane Smith wasn't working that day. This is further complicated when you bring in the additional factor of a Mac being bound to an active directory domain, where user accounts may not already be present on the Mac, which is also required to add them to FileVault on the machine. The last complication, is that the user being added must enter their password, or an administrator must know the users password to add it to a plist file which is can be used to add accounts to FileVault (it's almost as if Apple doesn't realize admins have no reason to (and shouldn't) know users' passwords). We can correct this using a standard SCCM Mac OS X configuration item, which utilizes a couple shell scripts to correct this problem for us. The concept is simple in theory: Check to see if all user accounts present on the Mac are accounted for in the FileVault allow list, if one is found that is not, and if that user is logged in, initiate the process of adding that user to FileVault.

The first script, which checks for compliance, first checks to see if FileVault is enabled, then collects a list of user names by gathering the names of all directories in the /Users/ directory. It then filters out root, etc. before running a loop that check for the presence of each user name in the list of users returned by the fdesetup -list command. If all users are accounted for in the FileVault list, or if FileVault is off, the configuration item returns a "true" value, indicating compliance with the fact that all users present on the Mac can currently boot the Mac. If not, then a value of "false" is returned, and the configuration item would then run the remediation script.

The second script, the remediation script, runs the check above again in order to determine which users are not present on the FileVault list. It then checks to see if those users are logged into the Mac, and if they are pops up a message informing them that the current Mac computer is encrypted, and that they need to enter their password to be added to the list of users allowed to boot the Mac. Once they enter their password and click the Okay button, a directory is created with 700 permission, and a plist file with a randomly generated name is created inside of it containing the user account name and password, which is then used with the fdesetup -add command to supply the users information and add them to the FileVault list, and the entire directory is immediately deleted afterwards.

The configuration item will then run again, verifying compliance. This configuration item can be ran as often as desired to ensure all of the users of the Mac are able to unlock it if it reboots, is shutdown, etc.

Once this solution is tested a little more, I will post the two scripts here.

Credit goes to the folks at JAMF nation, as well as Der Flounder, who's posts were key information in adapting a hybrid approach to work for Parallels Mac Management for SCCM.