users created by puppet on OS X Lion cannot change their own password and jpegphoto
|Assignee:||Gary Larizza||% Done:|
|Affected Puppet version:||2.7.6||Branch:|
Allow me to explain our situation: we have puppet manage all our laptops, and, with a few exceptions, every laptop is used by a single user. When Lion was released, I setup a migration scenario where every laptop was wiped clean, and then reinstalled using puppet as bootstrap mechanism (as aside, this was to migrate from FileVault 1 to FileVault 2). Puppet would also create the user account of the user using the laptop (without password, we would set that when we handed the laptop over to the user again). After a while I discovered that users were not able to change their own password and picture, while users created using System Preferences had no problem doing that (all without admin privileges, our users don’t have admin rights).
At that time I could not figure out what was causing this, but with Mountain Lion almost released, I decided to look a second time (because users not able to change their own password doesn’t really sit well with me). After comparing two user plists from /var/db/dslocal/nodes/Default/users/ (one created with puppet, and one using system Preferences), I discovered that the puppet-created one was missing the ‘dsAttrTypeNative’ fields (to be precise: writers_LinkedIdentity, writers_UserCertificate, writers_hint, writers_jpegphoto, writers_passwd and writers_realname). I guess these fields control who can write the mentioned field (in the System Preferences generated user, these fields were set to the actual username). After adding these fields to my puppet-generated user with dscl, I can now change the password and the picture of that user.
Although it’s possible to set the various attributes using dscl in a few execs, I suppose it’s cleaner to add it to the directoryservice provider.
We installed Lion using puppet 2.7.6, but the same behavior is present in 2.7.18.
#2 Updated by Gary Larizza over 1 year ago
The reason this is happening is because changing/creating a password in 10.7 in the directoryservice provider requires opening up the user’s plist on disk, injecting our keys, and serializing it back to disk. It’s not ideal. A better way is to call dscl to directly change just the password attribute (which is what I’m working on at the moment). My changes to the provider should accomodate this. I’ll add myself as a watcher.