Hello,
I've noticed some unexpected behavior when updating a user's FileVault password.
The set up:
All actions are performed in virtualized macOS 14 and 15.5 guests on a 15.5 Apple Silicon host.
FileVault is enabled.
sjsp is a standard user with a Secure Token.
The Mac is bound to AD, and the domain is reachable.
Reproduction:
systemctl -secureTokenStatus sjsp shows it's ENABLED.
fdesetup remove -user sjsp
fdesetup add -usertoadd sjsp
systemctl -secureTokenStatus sjsp shows it's DISABLED.
Surprisingly, sjsp is still able to unlock FileVault.
Looking at unified logs for opendirectoryd and fdesetup, I see that a password change is being attempted in response to fdesetup add, which is unexpected.
default 13:34:41.320883+0100 opendirectoryd Changing password for <private> (E5CC46D7-0C1F-4009-8421-9AA8217CB784)
info 13:34:41.321317+0100 opendirectoryd No unlock record exists for E5CC46D7-0C1F-4009-8421-9AA8217CB784
info 13:34:41.321331+0100 opendirectoryd <private> (E5CC46D7-0C1F-4009-8421-9AA8217CB784) is not a SecureToken user: no unlock record
default 13:34:41.321341+0100 opendirectoryd Changing password for <private> (E5CC46D7-0C1F-4009-8421-9AA8217CB784): user <private> SecureToken, only new password provided, credential <private>
default 13:34:41.321454+0100 opendirectoryd Changing password for <private> (E5CC46D7-0C1F-4009-8421-9AA8217CB784) with no existing unlock record
info 13:34:41.321857+0100 opendirectoryd No unlock record exists for E5CC46D7-0C1F-4009-8421-9AA8217CB784
default 13:34:41.321873+0100 opendirectoryd Record <private> (E5CC46D7-0C1F-4009-8421-9AA8217CB784) is eligible for SecureToken
default 13:34:41.322637+0100 fdesetup DMAPFS cryptoUserForMacOSUserForVolume DMErr=-69594 retErr=-69594 outAPFSCryptoUser=(null)
default 13:34:41.322699+0100 opendirectoryd While changing password for <private> (E5CC46D7-0C1F-4009-8421-9AA8217CB784): Not adding SecureToken; other unlock records exist, but no existing unlock record provided
If I disconnect the network and follow the reproduction steps then the Secure Token is retained. Reconnecting and waiting a while doesn't cause the Secure Token to be lost. There are no log entries about attempting to change the password.
Any help or explanation would be appreciated, thanks in advance.