|Applies To||ClearTrust Authorization Server 5.5.3|
|Issue||Why does the ctscPasswordExpirationDate attribute appear to be incorrect?|
The ctscPasswordExpirationDate is an internal attribute used by ClearTrust and RSA Support does not recommend that this value be used or modified externally. The behavior for this attribute is well defined within the operation of ClearTrust, but the value of this attribute is not obvious when viewed out of context as it may be when read directly from the datastore.
If the ctscUserKeyword Forced keyword is set then value of the ctscPasswordExpirationDate will always correctly reflect the actual expiration date of the users password. This condition is an exception that only occurs when the password policy for the user has been overridden manually either by pressing the "Expire Now" button or by setting a new "Password Expires" date manually for that user in the Entitlements Manager. This password expiration date will only be in effect until the user changes their password, at which time the users password expiration date will be reset to back to that defined by the password policy.
If the ctscUserKeyword PasswordPolicy keyword is set then ClearTrust will use the password policy to calculate the password expiration date of the user. ClearTrust calculates the expiration date by adding the password expiration period defined in the associated password policy (e.g. 90 days) to the value stored in the ctsPasswordCreationDate. ClearTrust will consider the users password expired if this date has passed. Note that in instances where the cstcUserKeyword attribute is set to PasswordPolicy, the value of the ctscPasswordExpirationDate is ignored.
If the user object is updated using the AdminAPI or Entitlements Manager ClearTrust will update all the ClearTrust users attributes associated with the user including the value of the ctscPasswordExpirationDate. At this time the currently calculated value of the users expiration date will be written to the datastore.
If the password policy is changed, that change comes into affect immediately for all users associated with that administrative group. In the same way, if you move a group of users to a new administrative group they will immediately inherit the password policy of that administrative group. Although the policy is changed immediately the users records associated with each of the users affected by that change are not updated. The value of the ctscPasswordExpirationDate in the user object is only adjusted if some change is made that causes that user object to be written to the datastore.
How can we reset users who have forced password expiration dates back to the password policy?
There is no progarmatic way to do this. Users will revert to the password policy when the password is reset. It is possible to modify the ldap datastore directly to add the ctscUserKeyword attribute of PasswordPolicy and remove the attribute of forced. Modifying the ldap store directly is not recommended and should only be done under direction from RSA Support.
How can we ensure the value of ctscPasswordExpirationDate accurately reflects the password expiration date that will be enforced by the password policy?
For users that have been affected by a change in password policy the value of the ctscPasswordExpirationDate cannot be assumed to be valid. If you need to rely on this value, you need to ensure that anytime a change in password policy is implemented, all users affected by that change are updated using the AdminAPI.
|Workaround||The password lifetime has been changed in the password policy.|
The user has been moved from one administrative group to an administrative group that has a different password lifetime in the password policy.
|Notes||See also How does ClearTrust calculate users' password expiration date?|
|Legacy Article ID||a37928|