Just curious how the rest of you are dealing with this "seemingly" simple task: rolling password changes for security compliance.
OSX was engineered quite well for end users to change their passwords via the GUI. OSX was not engineered so well for sysadmins needing to change passwords via the command line across many hundreds or thousands of Macs. For example, running the dscl command below changes the password of the account in question:
dscl . -passwd /Users/YourLocalUser YourNewPassword
However, upon logging out and logging in, you're presented with a well-known, nifty pop-up window which tells you that you've bugged the login.keychain. At that point, you'll need the OLD account password to unlock the keychain, then head into keychain manager and manually reset the keychain to the NEW password you've just rolled. Meh.
"Wait a minute, you say: just use Casper v9's system to change local account passwords!". Unfortunately, the same problem occurs.
"You should just use the security command!" say all the UNIX geeks. And they'd be right to suggest that. Partially. Adding the following lines of code should also change the password of the login.keychain to match the new user password.
dscl . -passwd /Users/YourLocalUser YourNewPassword security create-keychain -p YourNewPassword /Users/YourLocalUser/Library/Keychains/login.keychain security create-unlock -p YourNewPassword /Users/YourLocalUser/Library/Keychains/login.keychain chown YourLocalUser:staff /Users/YourLocalUser/Library/Keychains/login.keychain
But that doesn't work, either. Because then you get stuck with "local item" pop-up errors.
And, sure, sure, you can take Apple's suggestion of deleting these files and rebooting link here, but at this point, a super-simple task is becoming unruly. Which is why I'm writing:
What elegant solutions are you folks using to change passwords that don't annoy users with any pop-up messages. In our case:
1) we can't have any user interaction or interruption
2) we aren't changing the accounts form local to managed via AD or OD
Open to what you've all been solutioning on this. Long time peave of mine.
@htse yes, keychains will auto create themselves on login. but users will still be prompted to enter a password for them.
However, I think I found an odd solution:
1) I'm running a policy which runs a script. That script deletes old keychains and any "local items" folder in ~/Library/Keychains and then forces a restart.
2) Upon restart, I'm running a second policy that runs a second script which:
(a) changes all local user account passwords via CLI
(b) creates new login keychains and assigns same password as user account via CLI
' (c) unlocks those keychains via CLI
And that seems to work. Miraculously. What a frigging pain in the you know what.
I highly doublet this will work.
1 Using Dscl will brake the keychain.
2 If you do not care about keychain, and probably you enabled Filevault2 because of your security policy.
and if dscl changes the password, it only changes the admin password. and your filevault2 password will not be changed. This will brought chaos. I am sure it is not a good choice doing so.
I suggest you using a policy to pop up a window to remind the end users change the password, if they do not change their password, keep pop up windows to annoy them until they change password by themselves.
BTW, I am looking for a casper suite administrator job or similar in Australia
Please refer this link https://jamfnation.jamfsoftware.com/discussion.html?id=14056
If you have any information, I will be grateful if you can share to me.