Things have changed considerably. Current best practices are below:
- First user created on macOS receives a SecureToken. Only accounts that have a SecureToken can boot macOS. All subsequent accounts created by the 1st initial admin account will inherit a SecureToken. When creating accounts in System Settings -> Users & Groups this is handled automatically. Any command line / script based account creation has to be performed by the local 1st admin user account using sudo. The command line fdesetup command can list the accounts authorized to boot macOS and you can add existing accounts to be allowed to boot providing they have the SecureToken.
- Mobile accounts (Active Directory cached accounts) are problematic with keeping the FileVault pre-boot authentication password in sync. It is best to not bind to Active Directory and to instead use a Kerberos App to handle authentication and password sync for the local account. The most popular tool is called NoMAD.
- If you have an MDM (Mobile Device Management) server you can use Apple's Kerberos SSO tool (formerly Enterprise Connect) as you can push the configurations via the MDM server. NoMAD can also be pushed but the MDM is not required for it to work like the Apple Kerberos SSO tool.
- Most MDM solutions include the ability to redirect the FileVault Recovery Key to be escrowed by the MDM server and there are options to rotate the recovery key after it's been used, etc.
The most popular MDM for macOS is https://jamf.com and they bought out the company behind NoMAD and still offer the open source NoMAD tool. But they also offer JAMF Connect which adds many features and can work with SAML, cloud authentication, Identity Providers, AzureAD, etc., etc., etc.
https://github.com/jamf/NoMAD
You can actually convert the mobile AD accounts on the Mac to being a local account and maintain all data, etc.
https://derflounder.wordpress.com/2016/12/21/migrating-ad-mobile-accounts-to-local-user-accounts/
You can keep the macOS AD binding intact and it will still work. But since it's only really used for Kerberos and DFS mappings it's now optional.
Apple Intel w/T2 or Silicon Mac's are always encrypted from the factory. When you turn on FileVault you are merely generating a public / private key pair and the private key is written to the SecureEnclave in the CPU System on Chip and the public key is used to create the recovery key. Turning on FileVault merely gives you an additional way to recover the Mac if the user forgets their password. Even if FileVault is OFF, the disk is still encrypted and you still see the pre-boot authentication login screen. This is confusing because that login screen will appear visually just like the real login screen but it's OFFLINE, not connected to the network yet. After login, you see a progress bar indicating the operating system is booting. If the account used to boot the system has the same login password it will single-sign-on at the second login after the boot. If the passwords were out of sync it might boot past the pre-boot authentication but stop at the macOS login so you can enter the correct password or choose another account that isn't authorized to boot the Mac.
In order to remotely access an Apple Silicon Mac you need to ensure it has been logged on past the pre-boot authentication. Or you need some sort of remote KVM computer. Another computer, like a RaspberryPI or other small form-factor computer that is networked and connected to the Mac's KB/Mouse and Display so you can remotely login to the KVM computer and remotely control the offline Mac sign on.
If you need to reboot one of these Mac's and remotely reconnect you'll need to open Terminal and issue this command 'sudo fdesetup authrestart'. It will prompt for the username and password to auto-login past the pre-boot authentication so the Mac comes back online. You need to do that every time it reboots or you will be stuck unable to login to the Mac remotely as it will be offline waiting at the pre-boot authentication login screen. This is like what Apple uses after installing an update that might require additional reboots.
Yes this is painful but without some sort of KVM solution you will at some point have a Mac that needs to manually log on at the physical console. If you need to have Macs remotely accessible, may I suggest going to MacStadium and leasing some hardware or virtual machines in their data center / cloud. They have implemented all the magic to make it work successfully.
