Chef Ideas

I utilized the `mac_user` resource to rotate local admin account password on a portion of my on-prem macOS datacenter fleet. The rotation seems to have worked for local account password auth and SSH auth, but when authenticating via VNC (Apple Remote Desktop), the Macs all authenticate with the old password and reject the new one.

I created a macOS VM in Test Kitchen and ran this recipe as an example (vagrant had the password 'vagrant' on the box to start with):

mac_user 'vagrant' do
username 'vagrant'
password 'newpass'
secure_token true
admin true
end

I then open the VM, open the Sharing pref pane, enable Remote Management. "newpass" works for logging in and out of the user, unlocking System Preferences, and SSH access, but if I try to VNC into the VM from the host, it only accepts the old password "vagrant".

In the current state, I think there's issue with the ShadowHashData being written by mac_user. In the Test Kitchen VM, I tried running "dscl . -delete /Users/vagrant ShadowHashData" to see which auth methods would break. As expected, the "newpass" stopped being accepted via SSH or GUI, but the old password "vagrant" also stops being accepted over VNC.

After deleting the ShadowHashData, I spun up a new VM and started the following test:

1. Reset the vagrant password to "newpass" via mac_user resource.
2. Wrote the contents of the ShadowHashData to a file (newpass_hash_from_chef.txt)
3. Verified non-working VNC behavior
4. Deleted the ShadowHashData for vagrant.
5. Reset vagrant's password via System Preferences to "newpass"
6. Verified VNC now accepts "newpass" for vagrant login
7. Wrote the contents of the ShadowHashData to a file (newpass_hash_from_macos.txt)
8. Ran diff newpass_hash_from_chef.txt newpass_hash_from_macos.txt which showed significant differences in the hash of the same password when written by Chef vs when written by System Preferences.

However, I re-ran a converge with mac_user and "newpass" in the recipe, I get "mac_user[vagrant] action create (up to date)", despite that being a different hash than the one that resource originally wrote to disk for the password "newpass".