Self Service 10.10 Upgrade Disables Admin Accounts

[DraconicBlue]

I used Rich Trouton's wonderful article on using Self Service to upgrade an OS:

https://derflounder.wordpress.com/2015/11/23/providing-os-x-upgrades-via-caspers-self-service

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.

[merps]

@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

pwpolicy -clearaccountpolicies

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"

[bradtchapman]

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.

[DraconicBlue]

@merps

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.

[merps]

@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'])