Depending upon password policy used, configuration setting and what customization might be already in place, use case scenarios may be observed as:

use case: User has expired password, but is not prompted for password change, just go back to login page.

use case: Locked out account still allows users to try credentials.

use case: During password change process, if new password given does not meet the minimum 8 character limit enforced by AD policy. SMAUTHREASON shows 1 every time in smaccess.log except on initial access of login page (smauthreason 0).

use case: It takes two times (instead one) of changing password process before user can login again.

First time changing password always fails. Some reports seeing siteminder is getting SMAUTHREASON=1.

If you encounter similar problems, please engage with CA support, a dev fix might be provided which includes a few policy server library files replacement.

Is the issue applicable to only AD user store or others as well?

Yes, this is applicable only for AD user store and password policy is enabled at AD. The code that is affected is completely based on the AD error codes received.

Issue applicable from CR5 or CR6 onwards ?

Correct, as explained there was an issue with redirection that affected and addressed with 12.52 SP01 CR06 + Devfix

What are all the possible failing scenarios, any workaround, root cause?

Please refer to the Table#2. These are the scenarios effected.

There has been a new change since1252 SP01 CR05 and CR06 that effecting the AD Password Services as part of code effort to get appropriate smauthreason codes enhancement.