Cached Mobile Account Fails After an Off-Network Password Change
140 MacBook Airs are bound to Active Directory at corp.example.edu, and a configuration profile enforces mobile account creation at login. Twenty-two users work remotely for four to six weeks at a time and change their AD password through a web self-service portal that enforces a 60-day age, 12-character minimum, and a history of 10 passwords. Domain controllers are reachable only over VPN, and the VPN client cannot start until after login. After a password change, the new password is rejected at the login window; the old password unlocks FileVault but the session then reports 'network accounts unavailable'. A local admin account still logs in. FileVault is on with institutional key escrow. Several users later see repeated keychain password prompts. The help desk has been rebooting, which changes nothing. The branch office Wi-Fi uses a captive portal, so a USB Ethernet adapter is the only reliable path to the VPN.
1. At the login window the new password is rejected and the old password only gets as far as a 'network accounts unavailable' message. Explain what is happening, and identify the step that was missed before the user left the network.
Read the worked answer
The Mac holds a mobile account with a cached credential hash. FileVault unlocks with the credential that was current when the account was last synced, so the old password can still release the disk. Once macOS hands off to loginwindow, the account's authentication authority is the directory; with no route to a domain controller it cannot validate the new password, and the cached hash does not contain the new password. The missed step is an on-network authentication after the AD change: either change the password from a Mac that can reach a DC, or connect to VPN/Ethernet and lock and unlock or sign in so the mobile account and keychain receive the new credential. The self-service portal changed only the directory object. Rebooting cannot fix a cache that was never updated.
2. Give an ordered recovery workflow that preserves the home folder and keychain, and say where it can go wrong.
Read the worked answer
Preserve first: do not delete the mobile account or login keychain; take a Time Machine or offline backup if possible. Establish a route to a DC; USB Ethernet is more reliable than captive-portal Wi-Fi. Authenticate as the user with the new AD password so the directory validates it and rewrites the cached credential. If loginwindow still evaluates only the cache, use the local admin to confirm directory reachability and repair the mobile account's cached credential rather than converting it to a local account. Then update the login keychain to the same password; otherwise every saved item prompts. Verify FileVault by restarting and unlocking with the new password; if the secure-token user was not updated, re-add the user's FileVault access from the admin account. Finally test VPN, mail, and a saved Wi-Fi password. The common failure is resetting the local password first, which desynchronizes keychain and FileVault without fixing the directory credential.
3. Which policy or workflow changes would you make for the 22 remote users, and what trade-off does each carry?
Read the worked answer
Make the password change happen where the Mac can see a DC: require VPN before using the portal, or give remote users a documented connect-Ethernet-or-VPN-then-change workflow. A menu-bar password-expiry tool that authenticates to AD and updates the local account reduces tickets but adds a dependency that must itself be monitored. Lengthening password age from 60 to 90 days reduces exposure but weakens the policy and does not eliminate the cache problem. Pre-staging a local admin-assisted sync is reliable but costly. The best combination is usually: portal change blocked unless the user certifies the Mac is on-network, reminders at 14, 7, and 1 days, and a help-desk runbook that starts with network reachability, not reboots. Measure success by tickets per password cycle and by the percentage of remote users who complete an on-network sync within 24 hours.