000021113 - Are bad passwords updated with Read-Only Entitlement data stores in RSA ClearTrust 5.5?

Document created by RSA Customer Support Employee on Jun 14, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000021113
Applies ToRSA ClearTrust 5.5
RSA ClearTrust Authorization Server (AServer)
RSA ClearTrust Data Adapter
Microsoft Windows
UNIX (AIX, HP-UX, Solaris)
IssueAre bad passwords updated with Read-Only Entitlement data stores in RSA ClearTrust 5.5?
Bad password count
The ClearTrust Entitlements datastore has been set up so that replica databases are used by the Authorization Servers and the Entitlement Server has access to the primary datastore. In this configuration, only the primary datastore allows Read/Write access.

That said, when a user fails to authenticate due to a bad password, how is this updated in the Entitlements database?
ResolutionFor the majority of datastore types (SQL or LDAP), when a user authenticates, the password is hashed and compared against the value stored in the ClearTrust User password field of the database. Although the value of the field may already be cached by the Auth server, if the hash does not match, the bad password count is always updated directly in the datastore by the Auth Server. If there is no write permission to the datastore, the bad password count will not be updated.

The only exception to this rule is when user authentication uses an LDAP bind to the LDAP user account; this is done with Active Directory servers. To confirm this, check if validate_with_connect=true in the ldap.conf file. If the bind fails, the datastore?s own internal failed login count mechanism is used. In this instance, the Auth Server does not need to have write access to the datastore at all, as it only submits the logon details and awaits a success or fail condition from the LDAP bind operation.

It is possible to proxy Admin API updates (used by the Auth Servers to update passwords) through the Entitlements servers, if your security policy allows it. For more details, see the solution titled "AServer has read-only access to the datastore; user would like to enable Password Lockout functionality."
Legacy Article IDa21138