Access Manager 6.1 - aserver reports passwords are expired when password policy shows them as valid.
2 years ago
Originally Published: 2010-08-24
Article Number
000054181
Applies To
RSA Access Manager 6.1
Access Manager 6.0.4
Issue
Access Manager 6.1 - aserver reports passwords are expired when the password policy shows them as valid.
The aserver is indicating that a user password has expired, even though the Entitlement Manger shows the password expiration date has not yet been reached.

The aserver standard output in DEBUG mode shows that the default password policy is being enacted upon, even though the user belongs to a specific admin group with leveraging a different password policy:

13:44:18:834 [*] [MuxWorker-7] - Entity: Calculating passwordExpirationDate based on policy lifetime of: 31104000000
13:44:18:834 [*] [MuxWorker-7] - Entity: passwordExpirationState = Use Password Policy
13:44:18:834 [*] [MuxWorker-7] - Entity: passwordExpirationDate = Fri Aug 19 11:05:12 PDT 2011


Cause

The parameter cleartrust.data.ldap.user.add_to_default_admin_group=false allows users to implicitly belong to the Default Administrative Group without actually having a ctscPrivateMemberList object created for them in the ctscAdminRepository. 

Practical limitations of LDAP datastores prevent use of administrative groups when there are very large numbers (millions) of users in an admin group. 

The way that the aserver runtimeAPI calculates administrative group membership is through the ldap.conf file setting

cleartrust.data.ldap.user.add_to_default_admin_group=false

This behavior changed in hotfix 5.5.3.161 for ClearTrust 5.5.3.  The change was propagated into the release versions for both 6.0 and 6.1 and this  disables all administrative group lookups when this parameter is set to false.  This increases the efficiency of the aserver for sites who are not using administrative groups. 

The change when released did not anticipate sites that do not use the default administrative group in its intended fashion, but who still wish to leverage limited administrative group functionality for other specifically defined administrative groups. 

To support sites that wish to leverage the default admin group to exist without using group member objects, a new parameter was added in hotfix 6.0.4.52 for Access Manager 6.0.x and 6.1.2.03 for Access Manager 6.1.  This parameter adds back in the ability of the aserver to search for administrative groups when add_to_default_admin_group is disabled.


Contact RSA Customer Support and request hotfix 6.0.4.52 or the latest cumulative hotfix for RSA Access Manager 6.0.x or hotfix 6.1.2.03 (or the latest cumulative hotfix for RSA Access Manager 6.1)  NOTE: you must apply 6.1 Service Pack 2 before applying this hotfix in AxM 6.1. 

In addition, in order to use this functionality, you must manually add the following parameter to the ldap.conf file and set it to true:

# This optional parameter enables the users in non 'Default Administrative
# Group' administrative groups when
# cleartrust.data.ldap.user.add_to_default_admin_group is set to false.
#
# Allowed Values:
#   true | false
#
# Default Value:
#   false
#
# Dependencies:
#   This parameter will have effect only if
#   cleartrust.data.ldap.user.add_to_default_admin_group value is set to false.
#
cleartrust.data.ldap.user.search_all_admin_groups  :true


Workaround
ClearTrust hotfix 5.5.3.161 or greater is in place, or a 5.5.X Cleartrust server has been upgraded to Access Manager 6.0 or 6.1 or later.  In this particular instance, the use case also shows that cleartrust.data.ldap.user.add_to_default_admin_group is set to false, but the correct behavior would be to use some admin groups and password policies beyond those in the Default Administrative Group.
Don't see what you're looking for?