Local Password Policy

DBrowning
Valued Contributor II

so after looking through discussion on here, i found using pwpolicy gets me the password policies i want. But every account I create is auto disabled and any existing local accounts are disabled.

I'm using the following command to set my policy: pwpolicy -nv /Local/Default -setglobalpolicy "usingExpirationDate=0 usingHardExpirationDate=0 usingHistory=5 requiresAlpha=1 requiresNumeric=1 requiresSymbol=1 maxMinutesUntilChangePassword=129600 minChars=8 maxFailedLoginAttempts=4 minutesUntilFailedLoginReset=30"

if anyone can shed some light on to why the accounts are auto disabled that would be great. I've even tried command like this: pwpolicy -u admin -enableuser and pwpolicy -u admin -clearaccountpolicies that when I run them I don't get an errors but the account still doesn't work.

5 REPLIES 5

mm2270
Legendary Contributor III

I don't use pwpolicy, so I only have a general knowledge of it, but I took a quick look at the man page.
Can you try removing these 2 options?

usingExpirationDate=0 usingHardExpirationDate=0

I see in the man page it indicates a "1" will enable the setting and adhere to "expirationDateGMT" and "hardExpireDateGMT" settings respectively, but I didn't see an indication using a "0" disables those settings. I'm wondering if those being set to 0 is messing up the account? Its just a guess. I don't see anything else in your pwpolicy command that would be disabling the accounts.

DBrowning
Valued Contributor II

@mm2270 already tried that. But thanks for looking.

merps
Contributor III

@ddcdennisb We found that the "minutesUntilFailedLoginReset" option doesn't work with local accounts. I can't remember the source (It might have even been Apple Enterprise support) but it's apparently only meant to be used in conjunction with a directory server.

We had to create a script that kicks off based on a changed file in the userdb path (I think it's /var/db/dslocal/nodes/Default/users - don't have the launchdaemon handy). This script runs some logic to see how long it's been since the specific account was locked out and then resets the "failed attempts" counter. I put a few weeks' effort into this process, but it seems to be working out very nicely & it allows us to comply with security requirements.

Here is the pwpolicy we are using, which doesn't include the minutesUntilFailedLoginReset since that's being handled separately with the "Login Watch" script.

pwpolicy -n /Local/Default -setglobalpolicy "minChars=12 requiresAlpha=1 requiresNumeric=1 requiresSymbol=1 passwordCannotBeName=1 maxFailedLoginAttempts=7 usingHistory=5 notGuessablePattern=1 maxMinutesUntilChangePassword=86400

gachowski
Valued Contributor II

Dennis,

parts of pwpolicy are deprecated and there is a new way of managing the setting with Account Policies : ) guessing you know this..... but I want to point it out : )

I tried with X.9 and X.10 to get pwpolicy working but it was a disaster working in X.9.1 and failing in X.9.2.... I opened about 6 ticket with Apple Enterprise support and it was very clear that pwpolicy is on it's way out and profiles are in....

That said in my testing and tickets MaxFailedLoginAttempts and minutesUntilFailedLoginReset didn't work at all, the other thing I found is that some setting were set, but they didn't work like require complex... I had to test the setting in the GUI to be sure that they were enforced.

I just re-read the man page for pwpolicy X.10 and it says "Legacy Global Policies (DEPRECATED)" and I think that is what you are using ...also -"setglobalpolicy Set global policies. DEPRECATED." Not sure as I am the worst at reading and understand apple's man pages.

Sorry and I hope this helps a little!

C

kwatt29
New Contributor

Has there been an update for running a pwpolicy in 10.11.1 for local admins? We don't use a directory service in my environment and the configuration profile locks users out randomly...

On the man page i see i can create an xml plist of policies i want, but after creating a .plist and setting it using "pwpolicy setaccountpolicies 'file path of plist'" the complexity requirements aren't being upheld.

Perhaps i created the plist improperly or it doesn't have proper access, but i have no clue how to remedy this...