Questions about FileVault

You are correct here - the primary user would have to unlock the device, logout, and then it would give the user/password fields.  Now a different user can log in, yet if the machine is bound to AD, only local users would be able to login if not within sight of the domain controller.

Yes it should

If they are indeed mobile accounts they do not need to be on the network at all to login(if they are the user encrypted to FV) 

The AD binding workflow works very poorly as Apple is very vocal in expressing this is not how they are designing macOS. Food for thought, if someone forgets their password and the user is given their FV recovery key, it will break their Mobile account as it forces a PW change. MacOS does not have any tools to resync a mobile accounts password once it dysyncs.

What about the mobile accounts and unlocking FileVault. Will it work? 

---

Mobile and Local accounts work the same for the most part.

But let’s say somebody else from AD wants to log into the computer now with their AD credentials. This would not work right? Because the “new” user cannot even unlock Filevault before the boot process

---

When FileVault is enabled, the account that enabled FileVault and all Admin accounts currently on the device get FileVault tokens. After that point, the only way for another user to be given a FileVault token, is manually by someone who has a FileVault token. A new user cannot unlock FileVault until they are given access to do so from within macOS AFTER they log in to macOS for the first time.

need to be on VPN or Onsite to reach ldap ?? 

---

FileVault has no concept of a network. It does not matter if you are on prem or not. The MacOS login screen can behave this way if you do not have it configured to cache mobile accounts offline.

When he tries to login the progression bar loads up about 70% and then it is stuck

---

The 70% statement. Sometimes it can take quite a while for FileVault to decrypt. Let it sit, I have seen it take 20-30 minutes. If it still does not decrypt, it is very possible the OS is corrupted and you need to reinstall.

thanks for your perfect answer. What I also noticed is that when a mobile account is not onsite connected to the network. If he boots the machine up and then enters his username/password it takes around 1-2 minutes to login. When the same user, computer is onsite it takes around 10 seconds.

So my guess is that even though it is a mobile account (where the account password should be stored locally, otherwise you could not login without connection to domain controller) when FileVault is enabled for whatever reason he is trying to reach the domain controller for some time (that explains those 1-2 minutes) and then gives up and logs in?

is that correct? or why is the behaviour like that with mobile accounts and FileVault. Anything else we can do to make it better, faster?

thanks for your perfect answer. What I also noticed is that when a mobile account is not onsite connected to the network. If he boots the machine up and then enters his username/password it takes around 1-2 minutes to login. When the same user, computer is onsite it takes around 10 seconds.

So my guess is that even though it is a mobile account (where the account password should be stored locally, otherwise you could not login without connection to domain controller) when FileVault is enabled for whatever reason he is trying to reach the domain controller for some time (that explains those 1-2 minutes) and then gives up and logs in?

is that correct? or why is the behaviour like that with mobile accounts and FileVault. Anything else we can do to make it better, faster?

You can make a configuration profile that stops FileVault from attempting to auth macOS login. This would separate disk decryption and OS login. You would see your delay issues shift from FileVault to macOS login itself, which would make the issue easier separate from FileVault.

The delay with login is more then likely cause by the mobile account attempting to call home and eventually timing out for all the things it wants to do. There is not a way to make this faster beyond removing the mobile account from the equation. I strongly recommend in to looking for a method to replace Domain binding like JAMF Connect with Okta, or AAD. Domain binding is not the direction Apple is taking macOS, and will only cause lots of issues.

You can make a configuration profile that stops FileVault from attempting to auth macOS login. This would separate disk decryption and OS login. You would see your delay issues shift from FileVault to macOS login itself, which would make the issue easier separate from FileVault.

The delay with login is more then likely cause by the mobile account attempting to call home and eventually timing out for all the things it wants to do. There is not a way to make this faster beyond removing the mobile account from the equation. I strongly recommend in to looking for a method to replace Domain binding like JAMF Connect with Okta, or AAD. Domain binding is not the direction Apple is taking macOS, and will only cause lots of issues.

and how would I make a configuration profile that stops FileVault from attempting to auth macOS login??

yes I understand but what I don't understand is that if a mobile account is used WITHOUT FileVault enabled is working without any delay or issues even from outside the network. But as soon as FileVault is enabled and those accounts. It takes 1-2 minutes to login...

The preference domain is com.apple.loginwindow, and the key is DisableFDEAutoLogin.

 This is what the Configuration Profile will look like.