Defining The Password Policy Process with Multiple Policy Servers/Stores

Document ID : KB000023781
Last Modified Date : 14/02/2018
Show Technical Document Details

Issue: 

The Password Policy on Single Sign On Policy server is defined to restrict an account from reusing the previous 12 passwords. 
However, a user is able to re-use his previous passwords if there is more than one Policy store configured.

Issue Re-Production Steps:

  1. Open a new browser 

  2. Login using an account with its current password 

  3. Use change password functionality to change the password to a new_password 

  4. Logout from the browser, and close the browser 

  5. Open a new browser 

  6. Login using the account with the new password 

  7. Use the change password functionality to change the password to new_password_2 

  8. Logout from the browser, and close the browser 

  9. Open a new browser 

  10. Login using the account with new_password_2 

  11. Use the change password functionality to change the password to new_password. 

    The System will accept this password even though this is a previously used password!

Note: If you change the password multiple times without logging out of the browser, the system will not allow the user to reuse a previous password!

Environment:  

This issue occurs if there are multiple policy server configured and pointed to by Identity Manager. 

Two separate SM Policy Servers with their own policy stores.

SSO (Previously SiteMinder) Policy Server#1 is the Gate Keeper (Global server) 
SSO (Previously SiteMinder) Policy Server#2 has it's own Policy Store being used for solely for Identity Manager (Internal SSO Server) 
...........

User logs into SM#1.. 
Then Session is generated with SM#1 info and passes it over to SM#2 (IM) 
......... 
The Web Agent is being accessed via SM#1.. 
Then Identity Manager uses the Tunnel Agent to communicate to SM#2.. 
.........

Cause: 

Authenticating against the first Policy Server (which has it's own password policy defined) and then the session is handed off to the second Policy Server which has its own (different) password policy data.


The result is that the Identity Manager user is authenticating through the first SM Server, then it is attempting to change it's password against the second SM Server, which is a completely different Policy Server, with it's own password policies and password history. 

Resolution/Workaround:

When using two separate SSO (Previously SiteMinder) Policy Servers with their own policy stores, the user is authenticating against first Policy Server (which has it's own password policy defined) and then the session is handed off to the second Policy Server which has it's own different password policy data.

Identity Manager cannot have password policies that point to any Policy Store that isn't using the Primary Policy Store. Only policy stores which are directly connected to the Primary Policy Store are to be used by Identity Manager. The reason being is that password changes may not be replicated timely and if they are done on the Policy Store that isn't the primary they might not take effect quickly enough, and users may think their requests weren't implemented, etc..

Update the configuration to have authentication and subsequent password policy checks to occur on the same Policy Server and ensure that policy data across the two machines is identical.

Additional Information:

N/A