[nycbug-talk] Change password at next login?

[Tim A.]

Tim A. wrote:
> George Rosamond wrote:
>   
>> Tim A. wrote:
>>     
>>> Brian A. Seklecki wrote:
>>>       
>>>> On Fri, 25 Apr 2008, Tim A. wrote:
>>>>
>>>>         
>>>>> Internal FreeBSD server, no outside access.
>>>>>           
>>>> pw(8) and login.conf(8).  You can expire passwords and accounts 
>>>> after X-days.
>>>>         
>>> Thanks. I got it. Just expire a password:
>>> $ pw moduser theuser -p `date`
>>>
>>>       
>>>>> Is there anything else that does this?
>>>>>
>>>>> Also, is there someway to require a certain level of password 
>>>>> complexity?
>>>>>           
>>>> For LDAP (nss_ldap+pam_ldap), you could enforce strong passwords 
>>>> using a custom filter, but I have found that 2-factor authentication 
>>>> is much more successful than strong passwords (which just encourage 
>>>> people to write them down)
>>>>
>>>> For this, you can use something like Entrust IdentityGuard, in 
>>>> combination with pam_radius (with fallback to pam_ldap), for 
>>>> two-factor authentication (grid cards, FOBs), OTP password lists, 
>>>> etc...
>>>>
>>>> ~BAS
>>>>         
>>> Again, thanks. I'll check that out. 2-factor authentication sounds 
>>> like a good idea.
>>>
>>> In login.conf man page I found minpasswordlen, which unfortunately 
>>> didn't work. Then I noticed a reference to pam_passwdqc superseding 
>>> minpasswordlen option.
>>>
>>> I added this line to /etc/pam.d/passwd
>>> password        requisite        pam_passwdqc.so         
>>> min=disabled,6 match=4 similar=deny enforce=users
>>>
>>> Under the impression that it would disallow passwords of  a single 
>>> character class (like, all letters or all numbers), require at least 
>>> 6 characters from at least 2 character classes, and match up to 4 of 
>>> those in comparing for similarity to the previous password and deny 
>>> if found, and enforce this policy for users.
>>>
>>> As a user, it does prompt and warn, but it's not enforcing. If I 
>>> persist in attempting to set a password that violates that policy, it 
>>> prompts a second time but then gives up and allows it.
>>>
>>> Is this normal? Have I done something wrong?
>>>
>>>       
>> cap_mkdb /etc/login.conf ?
>>
>> g
>>     
> Yes. I did that after trying the minpasswordlen. Didn't work, and that's
> when I found pam_passwdqc.
> It was not mentioned as required after pam_passwdqc change, is it?
>   
Done. Works. Thanks.
Still gives back
passwd: pam_chauthtok(): authentication token failure

Is there a way to shut that up?

But it does enforce now.

So, making changes to /etc/pam.d/passwd  also requires cap_mkdb 
/etc/login.conf
You'd think they would have mentioned that in the man page.