Posted on 04-04-2016 01:31 PM
I used Rich Trouton's wonderful article on using Self Service to upgrade an OS:
The process itself is working fine, but with the side effect that it somehow has disabled all of the admin accounts on the system.
I have tried creating a new admin by deleting the AppleSetupDone file and registering the account (it becomes disabled immediately).
I have tried resetting the password vis resetpassword in the RecoveryHD and Terminal. That fails to allow me to do it as well.
Thankfully, this is currently on a test box and not live yet, but it will be an issue if I can't figure it out.
The source system is a STIG version of 10.9 so it already does have some processes in place for it.
Any insight would be appreciated.
Posted on 04-08-2016 02:10 PM
@JRossA A bit of Googling found this discussion on the Apple forums in regards to password policies that work fine with 10.9 but bomb on 10.10
You might want to run a
as part of the preinstall steps and then re-implement passwords after the upgrade has completed.
Are you controlling pw policies with Config Profile or with pwpolicy? We found a couple of flags that don't work properly on Yosemite when we were going through the STIG process. Config profiles didn't match AD closely enough, so we had to go with pwpolicy.
In case you're in the same boat, this is what we ended up with:
pwpolicy -n /Local/Default -setglobalpolicy "minChars=12 requiresAlpha=1 requiresNumeric=1 requiresSymbol=1 passwordCannotBeName=1 maxFailedLoginAttempts=7 usingHistory=10 notGuessablePattern=1 maxMinutesUntilChangePassword=86400"
Posted on 04-09-2016 10:01 AM
I have done Self Service upgrades from Mavericks to Yosemite at work and didn't have this problem. Then again, we use Active Directory for password policy. Our local management accounts did not lose admin rights after the upgrade.
Posted on 04-11-2016 07:07 AM
I have attempted the pwpolicy clean out as the first task after running the installer.
I don't have any config profiles on the system at all.
The only thing I can think of would be Centrify being the issue. That, I guess, will be my next test.
Posted on 04-11-2016 07:36 AM
@JRossA I was thinking that you might need to clean pwpolicy before the upgrade, as the lock is probably being enforced immediately as Yosemite evaluates policy. If doing it after the upgrade, you'll probably have to enable the account.
Here's what we got back from Apple Enterprise Support when we first started asking about this:
What follows is how I reset the counts. —snip ########### Mountain Lion dscl . readpl /Users/user PasswordPolicyOptions failedLoginCount failedLoginCount: 4 dscl . deletepl /Users/user PasswordPolicyOptions failedLoginCount dscl . createpl /Users/user PasswordPolicyOptions failedLoginCount 0 Changing a dictionary dscl . readpl /Users/user PasswordPolicyOptions failedLoginCount failedLoginCount: 0 ########### Yosemite dscl . readpl /Users/user accountPolicyData failedLoginCount dscl . deletepl /Users/user accountPolicyData failedLoginCount dscl . createpl /Users/user accountPolicyData failedLoginCount 0 —endsnip
Here's a python snippet from the password utility I had to create in order to solve this issue:
def unlock_account(): logging.debug('Attempting to unlock account.') subprocess.call(['/usr/bin/dscl', '.', '-deletepl', '/Users/' + locked_user, 'accountPolicyData', 'failedLoginCount']) subprocess.call(['/usr/bin/dscl', '.', '-createpl', '/Users/' + locked_user, 'accountPolicyData', 'failedLoginCount', '0'])