000034726 - RSA Identity Governance & Lifecycle authentication fails if the authentication sources uses Aveksa Data Collector (ADC) and the AccountSearchAttribute is different than the distinguishedName

Document created by RSA Customer Support Employee on Aug 28, 2018
Version 1Show Document
  • View in full screen mode

Article Content

Article Number000034726
Applies ToRSA Product Set: RSA Identity Governance and Lifecycle
RSA Version/Condition: 6.9.1 P16, 6.9.1 P17, 7.0.0 P04, 7.0.1
IssueAfter upgrading to 6.9.1 P16, 6.9.1 P17, 7.0.0 P04 or 7.0.1, authentication fails with the following error, although the username and password used are correct:
Invalid Login credentials

This issue occurs if the authentication sources use Aveksa Data Collector (ADC) and the AccountSearchAttribute is different than the distinguishedName.
User-added image

User-added image


User-added image


 User-added image

The error in the aveksaServer.log always says that the account is orphaned, even though the account is not orphaned and there are no duplicate accounts in the system.

09/23/2016 15:19:52.569 WARN (default task-56) [com.aveksa.gui.core.ACMLoginLogout] name is not in dn format 
javax.naming.InvalidNameException: Invalid name: jsmith
    at javax.naming.ldap.Rfc2253Parser.doParse(Rfc2253Parser.java:111) 
    at javax.naming.ldap.Rfc2253Parser.parseDn(Rfc2253Parser.java:70) 
    at javax.naming.ldap.LdapName.parse(LdapName.java:789) 
    at javax.naming.ldap.LdapName.<init>(LdapName.java:125) 
    at com.aveksa.gui.core.ACMLoginLogout.getLoginUserIdForAccount(ACMLoginLogout.java:745) 
09/23/2016 15:19:52.585 WARN  (default task-29) [com.aveksa.gui.core.ACMLoginLogout]
No User mapped to this account. Its an Orphaned Account

A defect introduced in the product in the affected versions causes the authentication to incorrectly attempt to map the Identity Governance & Lifecycle user to the AD account using the distinguishedName attribute.  The distinguishedName collected for the ADC will not map with the authentication source's user account and will always fail. The Test Authentication does a simple bind with the AD server and searches for the user with the UserSearchAttribute.  The user account mapping does not play a role here, hence it passes.
ResolutionThis is a bug fixed in 6.9.1 P19 and 7.0.1 P02. Deploy the patches to resolve the issue.
WorkaroundAs a workaround, having the associated collector attribute AccountId configured with samAccountName and not configuring the authentication source parameter AuthAccountAttribute, will result in a successful authentication.  This will cause the authentication source to accept the default value for AuthAccountAttribute as it is not mandatory, which is the NameInNamespace (DN) and will evaluate the user to be authenticated against the collected accounts successfully.