Unix Account unable to rotate password.

[Afrezal Abdul Karim]

Hi all,

I'm currently fixing issue with the accounts for a specific Unix server which are unable to rotate the password. After check-in the account. It will prompt that the password does not meet the minimum requirement for the linux system.

Does this mean its related to the password policy which was set on the Unix endpoint ?.

Any place or settings that i can check on the unix side for the password complexity setting ?.

Does anyone encounter this issue previously in your environment ?.

Thanks in advance for all the reply and responses. Appreciate it.

[Kevin Dedcovich]

Hi,

The default location to set password complexity on Linux is in the /etc/security/pwquality.conf file.
This policy and PAM Password Complexity Policies need to match.

Regards,
Kevin D.

[Afrezal Abdul Karim]

Hey Kevin,

Thank you soo much for the reply. I do not see any file with the name pwquality.conf on /etc/security.

And i've just checked on the working server which is able to rotate the password, the file does not exist either.

So it must be some other settings. Still cracking my head troubleshooting this tho :).

[Kevin Dedcovich]

What flavor of Linux are you running?

[Afrezal Abdul Karim]

Hi Kevin,

It was Redhat Linux 6.9


- Afrezal Karim

[Julian Riano]

Hi

I have a similar problem, for an EndPoint linux it asks me that the keys have exactly 2 uppercase letters, 2 numbers and 2 special characters, since the PCP of CA PAM it is not possible to configure this type of restrictions.

This seems to me a critical failure of CA PAM that I have not found to date how to synchronize the EndPoint.

Any ideas about it?

[Kevin Dedcovich]

Hi,

Unfortunately when you have two solutions trying to be the password complexity endpoint manager conflicts happen.
Everyone offers different combinations on what can be accomplished,  Our PAM Password Composition Policy offers these options:

If you cannot match them, than you can potentially alter/disable your current password composition polices in the various different files Linux offers:

/etc/security/pwquality.conf
/etc/pam.d/system-auth
/etc/pam.d/password-auth
/etc/login.defs

If this still cannot be done, please open an Idea in our communities, which other members can up-vote the idea is they run into this limitation as well.

Regards,
Kevin D.

[Joseph Fry]

Julian,

In your case, you can achieve this by severely limiting the entropy of your password (make it long to compensate)

Essentially you restrict the upper, number, and special characters to just two of each, then use one of each of them in the prefix.  Checking the box to disallow duplicates forces the generator to generate a password that uses the other character of each and a bunch of lower case characters.

Any system that requires a password like that is reducing the entropy already... this just makes it a little worse.  If you change them often enough, and have good protection against brute force attacks, then the reduced entropy shouldn't be an issue.

While this is not ideal, I wouldn't blame PAM... any requirements like those you describe are counter productive as they automatically reduce entropy and make your password less secure... I would change that system if you could; but the above will at least get you working if you can't​

[Joseph Fry]

Be careful with that error... it says "MAY NOT", not "DOES NOT".  There are other things than password complexity that may prevent PAM from updating the account credentials which could result in the same error message... all PAM knows is that the server rejected the password change.

All PAM is doing is logging in via SSH and running passwd.  To troubleshoot, just replicate those steps using the same credentials that PAM is using.

Remember, if your using a master account to change your passwords, you need to SSH with that account and use 'passwd <user>' to change the password.  Your issue could simply be that the master account isn't allowed to change the other account password, or maybe you need to tell it to use elevated privileges when changing the password (eg sudo passwed <user>).

Once you reproduce the failed password change manually, you should have a lot more information about why PAM is failing.

[Afrezal Abdul Karim]

Hi Joseph,kevin

First of all. Happy New year to you. Sorry for the late late reply on this.

I Appreciate all the steps and advice which you have provided me.

Thanks,

Afrezal Karim

[Pedro Fernandez]

Sometimes when I get this error it refers to delays in connections to the target device. It usually works for me extending the Script Timeout variable to 59999. Go to Credentials -> Manage Targets -> Applications. Within the Application under Script Processor try updating the Script Timeout to 59999.

[Afrezal Abdul Karim]

Hey Pedro,

Thanks for the tips. This is a new one. Have tried it but when try to checkin the account..seems like it taking forever. But this time it no longer show "does not meet the unix password requirement". But it still not reset/rotate to a new password and turn to unverified again.

Here are things that i have done.

• Checking and comparing all the password composition in the linux it self eg. /etc/security/pwquality.conf ( suggested by kevin)
  /etc/pam.d/system-auth
  /etc/pam.d/password-auth
  /etc/login.defs  
  
  - I'm comparing with the working ones which are able to rotate. seems like all are having the same setting. which is a default one. So i dont think its the is password composition policies because the existing one is working on the other server. 
• Playing with the composition policies - Tried all the solution provided again i dont think the composition policy is the issue
• Checking on the sudo permission - All are the same with the working ones and i have verified by resetting it manually (login to the server and try to reset the account password and was able to reset it.
• Tried to change the option to "Account can change own password".  - It manages to change the password when check-in back but when it does, the account is no longer working meaning it either does not take the new password or not working and will throw this error below
  
• 

My question, what is the security risk if we were to use the "Account can change own password" for Unix?.

For now i'm currently testing this option since this was the only server that are having the issue. And it was able to checkin but then the account is no longer able to use as if it cant track the newly reset password. So what i need to do, i have to manually reset the account password again in the unix server then update the password in the pam.


Thanks,

Afrezal

[Afrezal Abdul Karim]

I just found out where the logs can be monitored. It is in the /var/log/secure 

This is what i'm getting when trying to check in the account back. By checking in means that it will reset/rotate the account password back. Seems like i'm getting failed as per below. Any ideas ?. 

Fyi pam_unix_admin is the account that will managed the password rotation for other pam account

Jan 22 11:56:18 Winterfell sshd[22177]: Accepted password for pam_unix_admin from ******* port  ssh2
Jan 22 11:56:18 Winterfell sshd[22177]: pam_unix(sshd:session): session opened for user pam_unix_admin by (uid=0)
Jan 22 11:56:18 Winterfell sudo: pam_unix_admin : TTY=pts/1 ; PWD=/home/pam_unix_admin ; USER=root ; COMMAND=/usr/bin/passwd pam_unix5
Jan 22 11:56:20 Winterfell passwd: pam_cracklib(passwd:chauthtok): pam_get_authtok_verify returned error: Failed preliminary check by password service
Jan 22 11:56:26 Winterfell passwd: pam_cracklib(passwd:chauthtok): conversation failed
Jan 22 11:56:26 Winterfell passwd: pam_cracklib(passwd:chauthtok): conversation failed
Jan 22 11:56:26 Winterfell passwd: pam_cracklib(passwd:chauthtok): pam_get_authtok_noverify returned error: Authentication token manipulation error
Jan 22 11:56:26 Winterfell passwd: pam_cracklib(passwd:chauthtok): conversation failed
Jan 22 11:56:26 Winterfell passwd: pam_cracklib(passwd:chauthtok): pam_get_authtok_noverify returned error: Authentication token manipulation error
Jan 22 11:56:26 Winterfell sshd[22177]: pam_unix(sshd:session): session closed for user pam_unix_admin

[Ralf Prigl]

Hi Afrezal, Your pam_unix_admin account may have the wrong privilege elevation settings in PAM so that it either fails to provide its own password when running the sudo command, or it provides its own password when sudo doesn't ask for it. Please check out KB https://ca-broadcom.wolkenservicedesk.com/external/article?articleId=123217 for details. The PAM tomcat log at log level INFO would clarify what problem you have.

[Afrezal Abdul Karim]

Hi Ralf,

Thanks for replying my posting. The one that you are mentioning i believe is only when you are selecting "Account can change own password". Then the Privilege Elevation option is available for you.

For my case, I'm using the pam_unix_admin to change other Pam account password.

[Ralf Prigl]

Hi Afrezal, The privilege elevation setting only plays a role if an account is used to update the password of another account. When an account changes its own password, it just runs the passwd command, no need for the use of sudo. In your case the privilege elevation settings of the pam_unix_admin account are the ones to review. If your pam_unix_admin account doesn't change it's own password either, you have to temporarily change it to manage it's own password, set the privilege elevation to what is correct for this account, save the account, then go back and update the change process again.