Chef Ideas

We believe that the best way to build software is to do it in close collaboration with the people who use it. We invite you to submit your ideas using the form below. Please be sure to include the problem for which you are solving and the benefits of implementing the idea.

We do our best to implement as many Ideas as we can. Our Product team will evaluate all submitted ideas in a timely manner and will disposition each into one of the following categories: will integrate into the product roadmap, further research is needed, unlikely to implement.

Thanks for collaborating with us!

mac_user resource should rotate VNC password

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

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".

  • Jacob Zaval
  • Mar 29 2022
  • New
  • Attach files