Changing Password on SEP Mac Breaks Secure Token

[PicoMitchell]

If pycreateuserpkg is used to change the password of an existing Secure Token holder on a Mac with a Secure Enclave (SEP), things get into not immediately obvious broken state. The user will still appear as if they have a Secure Token (when checked with sysadminctl -secureTokenStatus, but they will not be able to do Secure Token actions, such as enable a Secure Token for another user. Also, they will no longer be able to change their own password via System Preferences. I've attached a picture showing both of these errors. I have not tested what happens if FileVault were enabled. I suspect that the user password may no longer work to unlock FileVault which would be very bad.

I have currently only tested this on a T2 Mac, but I would suspect the same issue would occur on an Apple Silicon Mac. I'm not sure if the Secure Enclave T1 Macs are used for password and Secure Token storage in the same was as T2 or Apple Silicon though.

Unless there is some way to get things back in sync, I think the safest course of action would be to prevent pycreateuserpkg from changing passwords on Secure Token holding accounts on Macs with Secure Enclaves.

I had hoped that maybe running diskutil apfs updatePreboot / could help get things back in sync. And while it did complete successfully, it did not fix the issue.

[gregneagle]

I'd think the somewhat broken state you refer to would really only be a problem if that account was the only Secure Token account on the Mac, something I'd recommend avoiding.

We use this type of package to change the local admin password on all the Macs we manage and have done so for years without encountering any major issues. Changing the functionality as you request would make the package useless for that purpose here, so I don't think I'll be doing that.

I don't know all the rules here and how they vary between OS versions and Intel vs Apple silicon. If they are documented somewhere, I'd love to see it.

Without that documentation from Apple, I'm inclined to leave things as they are and put the responsibility on understanding the trade-offs on the admin(s) choosing to use this tool.

[gregneagle]

"Unless there is some way to get things back in sync": perhaps deleting the account entirely and re-creating it would do that.

[PicoMitchell]

I'd think the somewhat broken state you refer to would really only be a problem if that account was the only Secure Token account on the Mac, something I'd recommend avoiding.

Yeah, the issues of unlocking a FileVault disk could be worked around with other users or recovery keys etc, but I'm not sure how that makes a difference to the way this particular Secure Token Admin would be broken. Such as, no longer being able to change the password by non-pycreateuserpkg means. I also tested dscl . -passwd after changing the password with pycreateuserpkg and it failed to work with an authorization error. I haven't done any tests with diskutil apfs changePassphrase yet which may behave differently.

Changing the functionality as you request would make the package useless for that purpose here, so I don't think I'll be doing that.

I'm not proposing prohibiting all password changes, just for Secure Token holders on SEP Macs. There are many cases where an admin management account does not need to have a Secure Token.

"Unless there is some way to get things back in sync": perhaps deleting the account entirely and re-creating it would do that.

That seems worth testing as well. I am also curious what diskutil apfs syncPatchUsers may do in this scenario.

I don't know all the rules here and how they vary between OS versions and Intel vs Apple silicon. If they are documented somewhere, I'd love to see it.

Agreed. It is very unclear and I'm only figuring these things out by trial-and-error. There may be some information about this in the Apple Platform Security Guide though. I reproduced this same behavior on Catalina as well. I believe it has more to do with how Secure Tokens and password authentication is handled on Macs with Secure Enclaves than with the OS version, but I wouldn't doubt the OS versions changes some things as well.

Without that documentation from Apple, I'm inclined to leave things as they are and put the responsibility on understanding the trade-offs on the admin(s) choosing to use this tool.

I definitely understand putting the responsibility on the end-user to understand what they are doing. I hope this issue would at least serve as some reference or documentation if someone runs into this issue. It also may be good to include information about this issue with Secure Tokens and SEP Macs up front before people start using pycreateuserpkg and get into a situation they were not expecting.