Touch ID for sudo permanently disabled on one user account after password recovery

## Summary

On macOS 26.5 (build 25F71), Touch ID is never offered for `sudo` (nor for the

`system.privilege.admin` GUI authorization panel) on my primary user account,

even though Touch ID works perfectly for screen unlock, System Settings,

password autofill, and Apple Pay. A brand-new admin account on the same Mac

gets the Touch ID prompt for `sudo` on first try. The broken state appears to

have started after a forgotten-password recovery flow in March 2025.

## Hardware / OS

- MacBook Pro, Apple M4 Pro (Mac16,8)

- macOS 26.5 (25F71)

- Intune-managed, Microsoft Defender for Endpoint system extensions present

(colleagues with the same management profile are unaffected)

## Steps to Reproduce

1. Use the affected user account on this Mac.

2. Open Terminal.app (or any terminal).

3. Run `sudo whoami`.

**Expected:** GUI authorization panel with a Touch ID button (as documented and

as observed for other users on the same Mac / same OS build / same MDM).

**Actual:** GUI authorization panel appears with password field only. No Touch

ID button. `pam_tid.so` in `/etc/pam.d/sudo_local` never triggers a biometric

prompt.

## Diagnostic signals

- `LAContext.evaluatePolicy(DeviceOwnerAuthenticationWithBiometrics)` returns

`-1004 LAErrorNotInteractive` in unified log when sudo runs.

- `canEvaluatePolicy` returns YES on the same account, but the policy

evaluation never produces a UI.

- `bioutil -c` / `bioutil -r` show templates correctly enrolled, ApplePay +

unlock both effective.

- `diskutil apfs listUsers /` shows user is a Volume Owner with SecureToken.

- `dscl . -read /Users/<me> AuthenticationAuthority` is vanilla (ShadowHash +

SecureToken + Kerberos LKDC), no smart card.

- `sc_auth list`, `security list-smartcards`, `profiles show -type configuration`

confirm no smart-card pairing, no Platform SSO, no enforceSmartCard policy.

- `/etc/pam.d/sudo` and `/etc/pam.d/sudo_local` are canonical (sudo_local

contains `auth sufficient pam_tid.so`).

## What I tried (none of which fixed it)

- Multiple reboots

- `bioutil -p` to purge templates, re-enroll

- Tested in Terminal.app, alacritty, Ghostty, and `env -i HOME=... /bin/zsh -f`

- Swapped `~/Library/Keychains/login.keychain-db` aside, logged out/in

- Signed out of iCloud (incl. iCloud Keychain), rebooted, signed back in

- Deleted `com.apple.LocalAuthentication` and `com.apple.security.ctkd-db.plist`

user prefs, killed cfprefsd, retested

- Verified `/etc/pam.d/sudo_local` matches a working colleague's bit-for-bit

## Bisect

A brand-new admin user created on the same Mac, with a fingerprint enrolled,

immediately gets the Touch ID prompt for `sudo whoami` in Terminal.app on

first try. This proves:

- The Mac, OS, sudo binary, PAM config, MDM profile, and Defender are not at fault.

- The broken state is local to my user account.

## Suspected root cause

A forgotten-password recovery performed in March 2025 (which renamed my login

keychain to `login_renamed_1.keychain-db` and issued a new SecureToken) appears

to have left the per-user Secure Enclave biometric-policy binding in a state

where the `system.privilege.admin` authorization rule no longer offers Touch

ID for this account. Replacing the login keychain does not fix it. Resetting

iCloud Keychain does not fix it. Re-enrolling fingerprints does not fix it.

There is no documented user-space way to reset this binding.

## Impact

Touch ID for `sudo` is a quality-of-life feature, but the bigger issue is

that there is no user-facing tool to diagnose or reset whatever per-user SEP

state was corrupted by the password-recovery flow. The only known fix is to

migrate to a new user account.

## Request

Please provide a way to reset the per-user biometric-authorization policy

binding without recreating the user account — or fix the

forgotten-password-recovery flow so it doesn't leave biometric authorization

for sudo permanently broken.