I'm trying to setup a password rotation policy without any directory server or identity manager. My understanding is that setting up a Configuration Profile with a Maximum Passcode Age is the best way to go.
So, I have profile scoped to one machine for testing and here's what I'm seeing:
If the password expires while the user is logged in their password simply stops working in the GUI (although it still seems to work in the terminal). There's no notification of any kind. If you logout then log back in you'll get the notification at login window to update the password.
My concern is that since most users essentially never need to use their password other than to wake from sleep they won't notice their password is been expired. They'll only notice when they have to, say, unlock a preference pane and make a few attempts thinking they must've typed their password in incorrectly, then get frustrated that seemingly for no reason their password has changed.
Had anyone come up with a good solution for reminding a user that their password will expire soon, or even prompting them to change it? I suppose It'd be possible to force them to logout to initiate the process, but that seems like a poor experience.
Check out the below script that grabs the local user's password age and puts it in an extension attribute. You could then create a script or policy that pulls the value from that extension attribute and use jamfhelper or osascript to show an alert or notification to the user about their impending password expiration in X days.
First, I created an Extension Attribute titled "Password Age" with data type "string" and input type "script." Then I just pasted in the password age script a kind soul at Jamf created.
Next, I created a policy set to recurring check-in, and execution "Once Every Day" using the expiration warning script I created. I used 90 days as my pw expiration threshold, but you can adjust this to match whatever your organization needs.
Right now a user will just see the Users & Groups preference pane open so they can change their password. At some point I hope to update the script to use
sysadminctl but I haven't had time to test. I don't use
dscl because that causes some quirks with secureToken.