Password change after upgrade to Sierra

[AlistairCarr]

Hi Everyone,

We're still testing Sierra with our Corp software before deploying to our users.

One odd thing I have found is that on every machine we've upgraded. At the first boot after installation has completed the user account is prompted to change their local password.

Any ideas on why this is?

Thanks as always in advance.

[psliequ]

I have seen this happen if there is a password policy set via MDM, even if the criteria of the password policy hasn't been broken. Do you have something similar in place?

[AlistairCarr]

We do.....

We have a script that sets the policy and also a script that checks for when the password is due to expire (prompts user)

Any workaround are you aware?

TIA

[ron_bledsoe]

We've seen this too and don't know what's causing it (we set a password policy via mdm).

It's also problematic for us because several (but not all) users are no longer able to log in after the password change, either using their old password or new and can't decrypt file vault with either password. The login thing seems to happen with El Cap or Sierra password changes, so it seems like a coincidence exacerbated by the forced password change with Sierra. I'd love to know why it's happening.

[danny_friedman_]

A colleague of mine pointed me to this posting, and I can confirm this behavior as well. Hopefully I can help.

Here is a minor snapshot of our environment (as it pertains to this issue), what my thoughts are, and how I've attempted to resolve it:

pwpolicy
Instead of using the Apple MDM to control/enforce password policy, we use the built-in Apple binary, pwpolicy. One large reason that I have kept using Apple's pwpolicy, and not started enforcing password policy via Jamf MDM (which I do believe still utilizes pwpolicy at its core) is because I'm under the impression that I have a greater amount of control over password policy on our endpoints. My impression may be incorrect, so I would love to hear more about why I may be wrong about this.

One major issue with pwpolicy is that Apple has been continually deprecating commands, and I am unsure how long it will be supported. I imagine its functionalities will eventually only be accessible when using the password policy MDM.

When we image our laptops, we set password policy using a script at imaging (my colleague @jholland posted a snippet of it here). The script also includes notification functions that warn the user 14 days before expiration via Notification Center, and eventually goes to AppleScript notifications that open System Preferences -> Users & Groups, pushing end users to reset their passwords.

We've also noticed that if a user does not change his/her password prior to expiration, becomes locked out of their account at the login window, and is prompted to change his/her password at the login window, the act of changing the user password at the login window does NOT update the user's FIleVault 2 user password. This has caused so many headaches from a support standpoint to the point where we had to write an internal wiki article about password upkeep and how to prevent login and FileVault 2 passwords from becoming out of sync (we do not use Active Directory either, which may complicate OR remedy the issue).

We use an extension attribute to read a specific string from the logged-in user's password policy to determine if the user's account has our company-specific password policy enforced. If the specific string is not found by the extension attribute, the computer is put into a Smart Group of computers missing our password policy, and our pwpolicy enforcement policy (script) is re-run on that computer at next check-in. This script does not include any of the warning features (launch daemons that trigger scripts to notify based on upcoming time-to-expiration), since the warning functionality should still be working properly (I can only hope).

macOS 10.12 Sierra Upgrade Password Policy Behavior
When I upgraded a VM to 10.12, The first thing that happened upon boot after clicking though the setup screens (iCloud, Siri enablement) was an AppleScript notification associated with our pwpolicy implementation warning me that the password had expired and had to be reset. I knew that this VM had its password set recently, so I was surprised to see this, but reset it anyways and didn't think much of it at the time.

Later that day, I let my VM sleep, then woke it up. I was met by the login window not taking my VM's user account password. I rebooted the VM. At the FileVault 2 unlock screen, I saw account icons for the 2 FileVault 2-enabled users in the VM. I entered the password for the account that previously was not accepting my password and the volume began to unlock. Rather than logging into the proper account, I was met by the standard login window, now showing only a single account, not the account that I had attempted to log into. This was pretty alarming, so I started by logging into the other account (a standard local admin account).

After successfully logging into the local admin account, I went to the fast user switching menu and was able to see the account that I had initially tried to log into. I clicked the account in the fast user switching menu, but it did not take the password. I then opened System Preferences -> Users & Groups and did see the problematic account in the list (which is good because I was getting worried that I might not have). I then opened up Terminal and attempted to clear account policies for the user that I couldn't log into:

sudo pwpolicy -u <username> -clearaccountpolicies

After seeing output and verifying that there were no account polcies for the user using sudo - u <username> -getaccountpolicies, I tried to log into the user via the fast user switching menu and was able to successfully log in! I restarted the computer and was able to unlock FileVault 2 as that user, and the computer logged me into the user environment as it should have. I re-applied our password policy and have not experienced any pwpolicy issues on that VM since.

That said, I have experienced this exact issue now on every machine that I have upgraded to Sierra (3 at this point). One of the machines had to have its password policy cleared twice, which is scary and alarming as an administrator.

Knowing that this is the likely outcome for any users that would upgrade to 10.12 in my environment, we have expressly warned about upgrading, and have kept out environment running El Capitan.

I have been building a script to automate the Sierra upgrade process and here is what I've been working with to avoid the issue:

• The whole upgrade is being scripted for greater control

• The script writes an additional script that is triggered by a launch daemon on first reboot after the Sierra upgrade that performs these steps in this order:

• Sets a variables for the currently logged-in user and current time (in epoch)

• Clears existing account policies for that user (which is not a big deal, since the user will eventually have the password policy re-scoped to their computer)
• Resets the last password set time using: dscl . createpl /Users/$LOGGEDINUSER accountPolicyData passwordLastSetTime $currentEpochTime
• Compares $currentEpochTime to dscl . read /Users/$LOGGEDINUSER accountPolicyData | grep passwordLastSetTime -A1 |tail -1| cut -d '>' -f 2 | cut -d '<' -f 1 | cut -d . -f 1, to make sure that their last password set time has in fact been reset properly by the script
• Deletes the launch daemon .plist file
• Deletes this script that the daemon triggered
• Then finally removes the launch daemon from launchctl

In the 10 or so upgrades from El Capitan to Sierra I have tested in the last 2 days, this has resulted in no password-related account issues. One thing to note is that it is extremely important to set a launch daemon to handle this task on first boot after upgrade. My tests where I set passwordLastSetTime to the current time prior to reboot for Sierra upgrade still resulted in password policy expiration notifications.

Ok, sorry for the super long post that covers a variety of info, but I think it's important to understand all of the moving parts in trying to resolve this. As you can imagine, this has been quite a process to diagnose and resolve. Hope this helps!

[AlistairCarr]

Thank you for the post very helpful, I'm going to look at this in our environment and see if it can help.

Many thanks again !!

[danny_friedman_]

@AlistairCarr – No problem! I hope it helps. Let me know if you have any specific questions, as I can probably answer them (I've been wrestling scripting this upgrade process for the last two weeks).

I would just post my script but it is loaded with items that are environment-specific, and I just don't have the time to go through the script and generalize it.

[dleininger]

@dfriedman - Is there any chance you could share your extension attribute for verifying the logged-in users password? I for the life of me cannot figure out how to get it to work with Sierra!

Thanks!

[danny_friedman_]

@DanielLeininger – are you asking about how I verify that the logged-in user has password policy being enforced on his/her account, or as you asking something else?

[dleininger]

@dfriedman - Sorry, should have been more specific! Yes, we are looking at scripting a basic extension attribute to verify that the logged-in user has the password policy being enforced on their account. We started with the built in "OS - Local Password Policy" and noticed several of the attributes have been depreciated since El Capitan (example: getaccountpolicies).

I was curious if you could share your process of verification.

Thanks!

[danny_friedman_]

@DanielLeininger Ah, got it. That makes sense!

All we do is verify that specific strings exist in the pwpolicy XML. For example, if this was your password policy (I have removed some fields as I do not want to post our password requirements):

You could determine if this particular policy were enforced on an account by using grep on the output of pwpolicy -u <logged_in_user> -getaccountpolicies and looking for strings that were set by the admin who created the password policy. Specifically, the strings that are descriptions of what the requirements are happen to be specific to a particular password policy, and had to have been set by the admin who created it. This will work consistently UNLESS you set a similar password policy that uses the same specific description strings, but has other modifications, and you are attempting to check for the newest version of the password policy. This extension attribute will only be reliable if you are consistently careful to avoid this.

If the requirements in the screenshot were part of the password policy, this extension attribute could confirm that a user's account was enforced by this specific policy:

#!/bin/bash

# get logged-in user and assign it to a variable
LOGGEDINUSER=$(ls -l /dev/console | awk '{print $3}')

# check for first specific string
CURRENTPWPOLICY=$(pwpolicy -u $LOGGEDINUSER -getaccountpolicies | grep 'Does not match any of last 5 passwords' | sed -e 's/^[^<]*</</g')
CORPPWPOLICY="<string>Does not match any of last 5 passwords</string>"

# check for second specific string
CURRENTPWPOLICY12CHAR=$(pwpolicy -u $LOGGEDINUSER -getaccountpolicies | grep 'Has at least 12 characters' | sed -e 's/^[^<]*</</g')
CORPPWPOLICY12CHAR="<string>Has at least 12 characters</string>"

if [[ "$CURRENTPWPOLICY" == "$CORPPWPOLICY" ]] && [[ "$CURRENTPWPOLICY12CHAR" == "$CORPPWPOLICY12CHAR" ]]; then
  echo "<result>$LOGGEDINUSER has the company password policy</result>"
else
  echo "<result>$LOGGEDINUSER DOES NOT have the company password policy</result>"
fi
exit 0

I have not tested this with the Apple/Jamf's password policy MDM, but I'd love to know if it works, so please let us know!