Open Radar

 
Summary:
There is a support article titled HT208171: "If you see authentication server errors when turning FileVault on in macOS High Sierra"

That support article details a problem that Active Directory environments can experience with the upgrade to 10.13 where Active Directory mobile accounts are unable to be added to FileVault users.

This radar contains a different problem and is unrelated to HT208171.

In this particular situation, the user is already a FileVault user under 10.12 and after the upgrade to 10.13, they can unlock the disk with their password.

They cannot, however, continue the login and get to their desktop.


Steps to Reproduce:
- Install 10.12.6
- Create local user ("testuser") with admin
- Important: Put 10.13.0 installer app on disk for future use
- Bind the Mac to Active Directory - enable "create mobile account at login" and disable/uncheck "require confirmation before creating a mobile account"
- Reboot
- Log in as AD user, creating a mobile account
- Log out, then log back in with local account ("testuser"), go to Users & Groups and enable admin for the AD user
- Important: Disconnect all network access (ethernet, wifi, etc.)
- Reboot
- Log in as same AD user and confirm admin rights
- As AD user, enable FileVault: sudo fdesetup enable
- Confirm AD user account can login+unlock Mac, reboot & confirm a second time (proof 10.12.6+HFS+FileVault did not require domain net access for AD user and user could login after).
- With AD user, delete local "testuser"
- Important: While network is *still off*, run 10.13 installer as the AD user
- Reboot when prompted
- Wait for OS installation to complete

Expected Results:
- Should able unlock the Mac using the Active Directory credentials and eventually log back in, seeing the desktop of the AD user.

Actual Results:
- The AD user credentials successfully unlock the FileVault disk
- However, the login process stops and goes to the real/actual login window (after disk unlock) and prompts for the user password again
- At this point, the user password does _not_ successfully log into the machine.

The only remediation steps possible at this point are bringing the laptop into an office environment where Active Directory is available at the login window or going through a complicated recovery environment process of re-creating a local user account by removing .AppleSetupDone and additional steps - none of which is appropriate to walk end users through over the phone/via chat.

Version:
10.13.0 17a365

Notes:
Number of affected devices: 32000+ 

The AD mobile user cached password should be valid to get into the machine at this point. There is no reason for it to be invalidated.

Instead, a user who attempted to upgrade to 10.13 while they didn't have access to their AD environment - ie. a user with a laptop who took it home, is at a cafe, etc. - is now no longer able to log into their machine until they get back to a work network.

If you do not delete the "testuser" account, it's still possible to log in as this local user account. However, this account does not have FileVault rights, so it can't be used to unlock the disk.

This scenario simulates a not uncommon Active Directory environment:
- 1-to-1 laptop deployment
- Primary user is Active Directory mobile account
- Primary user has admin rights on machine
- May be zero or more local admin accounts on machine, but none of them have FileVault unlock capability.
- User may attempt to upgrade to 10.13 when Active Directory is unavailable