pwpolicy documentation

[bernstei]

Does anyone know where there is documentation on the list of quantities that you can put into the logical tests in the pwpolicy xml file? For example, the password minimum lifetime uses

policyAttributeLastPasswordChangeTime < policyAttributeCurrentTime - (policyAttributeMinimumLifetimeHours * 60 * 60)

policyAttributeMinimumLifetimeHours comes from the policyParameters dict in the rule, but where do the other two come from, and what other attributes are available? In particular, is there an attribute the indicates if the account is paired with a smartcard?

Web searches on these strings bring up essentially nothing except STIG rules, auditing discussions (mainly STIG) and related questions.

[bernstei]

I did eventually find https://www.manpagez.com/man/8/pwpolicy/osx-10.10.php, but it's quite old. I guess that info is also in the current man page, but does anyone know if it's really the definitive list?

[brodjieski]

I would just review the man page itself... man pwpolicy.

[brodjieski]

As for pairing with a smartcard, pwpolicy doesn't really have any direct tie to that, so no attribute exists that offers that information. If you are using pairing for smartcards, you can query the status of an account using sc_auth. If you are using attribute mapping, you can look for the amidentity values in AuthenticationAuthority of the user's record.

[bernstei]

The problem is that I'd like to exempt paired users from the password expiration policy, otherwise (from our experimentation) they are still required to change their password even though the smartcard allows them to log in (although I haven't tested with required smartcard login). I was hoping I could do it in the global pwpolicy by modifying the logical test that the expiration rule applies so it's only used for unpaired accounts.

[brodjieski]

If you have a requirement to change passwords, even smartcard enforced accounts have a password(s) associated with them. The volume owner password and keychain passwords are still in play. Do you not have a requirement to change those?

I do wish the STIG would get up to speed with modern password policies... things like forced arbitrary rotation should not be a thing these days... sigh.

[bernstei]

Following up on this thread, does anyone happen to know (whether because it's documented or by experimenting) how pwpolicy entries set by a mobileconfig, those set by a global pwpolicy, and by a per-user pwpolicy interact? Which ones override which other ones? E.g. does the mobilecofig override what's set via pwpolicy when they're the same check? Can you set a looser (or tighter) limit on some check for one user than is applied in general?

[brodjieski]

Best I can tell, because there isn't documentation that I could find on this, this is what I observed.

Applying a .mobileconfig with passcode settings will set the global password policies. You can view them using pwpolicy getaccountpolicies

You can set user specific policies using pwpolicy setaccountpolicies -u <user>. It will concatenate both global and user policies. So if you had a setting for minLength 15 in the global and minLength 5 in the user, you will see both requirements when you go to change the password. However, if the policyIdentifier value is the same in the user policy as the global, it appears to override the global policy. I only did limited testing, but it does look like you can override global policies if you pay attention to the policyIdentifier.

If you modify the global policy with pwpolicy setaccountpolicies /path/to/xml, it will get reset to the .mobileconfig defined settings the next time MCX refreshes (either a reboot, forced mcxrefresh, or whatever the regular interval is that the OS does that). The settings applied from the mobileconfig appear only in the global policy, and don't appear to affect defined user policies. Note that if a new mobileconfig is pushed with a new UUID, then you may see the concatenated policies. Also, if you added custom global policies using pwpolicy setaccountpolicies /path/to/xml that have unique policyIdentifier values, those appear to stay as well.

Again, this is all based on limited observation and my understanding of pwpolicy... happy to test other scenarios as well.

[bernstei]

Thanks, that all sounds consistent with what I assumed / observed. The one weird thing I found is that there are some settings that, if you have a mobileconfig, you apparently cannot set with a pwpolicy. For example, if you have a mobileconfig with maxPINAge, it will create a pwpolicy item to enforce that. However, if you remove that key from the mobileconfig and try to set it "manually" with pwpolicy -setaccountpolicies policy.xml that item will disappear when you log out and back in (which must also trigger an MCX refresh). Maybe that can be affected by a correct choice of policyIdentifier? I'll have to check.

[bernstei]

Yes - setting a distinct policyIdentifier allows the mobileconfig settings and the pwpolicy settings to coexist for items that the mobileconfig can set (like maxPINAge) even if they aren't explicitly specified in a particular mobileconfig.