Catalina 19A536g changes authentication_authority edit access

[poundbangbash]

On Catalina beta 19A536g with a pycreateuserpkg that's been working for 10.12-10.15b4

2019-08-19 18:11:31-05 C07SM11DG1J2 installd[437]: ./postinstall: Error Domain=com.apple.OpenDirectory Code=4001 "Failed to modify AuthenticationAuthority: would cause removal of last unlock record" UserInfo={NSLocalizedDescription=Failed to modify AuthenticationAuthority: would cause removal of last unlock record, NSLocalizedFailureReason=Operation was denied because the current credentials do not have the appropriate privileges.}

In create_user.py I edited line 163 (attrs_to_skip = ['uid', 'home', 'authentication_authority']) to add the authentication_authority value, repackaged it, and now it appears to work since the authentication_authority value is not being edited. I don't know if that impacts the functionality of this tool or not. I haven't run this package to create an account, only to update an existing account.

A side note, pycreateuserpkg is changing the default shell back to /bin/bash since that's in the account source plist. Catalina's default shell is now zsh.

-Eric

[gregneagle]

"A side note, pycreateuserpkg is changing the default shell back to /bin/bash since that's in the account source plist." Seems to me that's the expected behavior. If you want to set the shell to zsh, set it to zsh using the --shell option.

[gregneagle]

As for the AuthenticationAuthority issue; I suspect this has to do with SecureToken and I'm betting we don't yet have enough information to handle it properly...

[poundbangbash]

It is tied to the account having a SecureToken.

One change I made recently to my workflow is having the account enable its SecureToken early in the munki bootstrap before the pycreateuserpkg comes down. The new Catalina Bootstrap Token feature needs an admin account with a SecureToken to kick off the escrow process. Removing the routine to enable SecureToken allows pycreateuserpkg to update the password without issue.

Regardless of my workflow, if the account ever becomes the only account with a SecureToken this issue will arise.

Examining the MDM created admin account data in /var/db/dslocal/nodes/Default/users/username.plist shows that the authentication_authority array has 3 entries:

    0 => ";ShadowHash;HASHLIST:<SALTED-SHA512-PBKDF2,SRP-RFC5054-4096-SHA512-PBKDF2>"
    1 => ";Kerberosv5;;username@LKDC:SHA1.E6C8223BD0A5401210A4105D2DB94FFFC2312219;LKDC:SHA1.E6C8223BD0A5401210A4105D2DB94FFFC2312219;"
    2 => ";SecureToken;"
  ]

the pycreateuserpkg user plist only contains

    <key>authentication_authority</key>
    <array>
        <string>;ShadowHash;HASHLIST:&lt;SALTED-SHA512-PBKDF2&gt;</string>
    </array>

Could a possible workaround would be to detect if this is an upgrade to an existing account or if it is creating a new account and act accordingly; e.g. don't attempt to change authentication_authority if the account already exists?

[gregneagle]

Isn't that what your suggested change does? It's not a perfect solution, though. If the ShadowHash algorithm is ever changed by Apple (as it has been several times in the past) the pkg could install a new ShadowHash attribute encoded with a different algorithm than that listed in authentication_authority.

I'd think a better solution might be one that alters the ;ShadowHash; array element of the authentication_authority while leaving any other entries alone. Not sure if that's actually possible, though.

[poundbangbash]

I see, my suggested change ignored the authentication_authority but that's only in the update routine, a new account will still have it added. I didn't see that the first look thru.

I agree the workaround isn't great. From the documentation at https://developer.apple.com/documentation/opendirectory/odrecord/1427911-setvalue?language=objc there looks to be ways to determine values present. These may be leveraged to evaluate whether to act or not.

valuesForAttribute:error:
Returns the values of an attribute of the record.

and

addValue:toAttribute:error:
Adds a value to an attribute of the record.

[gregneagle]

Yes, this looks at least possible, though not trivial, especially with my weak Objective-C skills.

[gregneagle]

Addressed in latest code.