HTTP Status 500 - Incorrect result size: expected 1, actual 0

Document ID : KB000103870
Last Modified Date : 29/06/2018
Show Technical Document Details
Issue:
Logging into Release Operations Center (ROC) with an Active Directory user redirects to the following page: http://mgmtServer:8080/datamanagement/j_spring_security_check

The result page shows the following errors:
HTTP Status 500 - Incorrect result size: expected 1, actual 0

 
Environment:
CA Release Automation 6.5.0.10007 and above.
Cause:
This is related to how the distributed.properties file is configured which serves as a basis for how subsequent searches are done when trying to authenticate active directory users.


 
Resolution:
1. Login with the user's UPN (userPrincipalName).
2. Change the user's UPN (userPrincipalName) so that it a search for the name (as described in additional info) would be found.
3. If your distributed.properties file is configured to point to a global catalog (usually indicated by the directory.url property pointing to either port 3268 for non-ssl or 3269 for ssl) then another option would be to define an additional domain controller for the domain that this user's userPrincipalName is associated with. For more information on how to add multiple active directory domain controllers see the following KB: https://comm.support.ca.com/kb/how-to-implement-multiple-active-directory-andor-ldap-domains-on-a-single-management-server-directly/kb000014106
Additional Information:
Example of problematic configuration and login IDs.

Distributed.properties file configured with an Active Directory domain controller:

use.active.directory.authentication=true
use.active.directory.domain=east.tsqa.support
use.active.directory.url=ldap://myaddc:389
use.active.directory.user.username=administrator@tsqa.support
use.active.directory.user.password=*******


I have a test user whose sAMAccountName is: myeastuser
This users userPrincipalName is: myeastuser@tsqa.support

If I try to login to the ROC with myeastuser then it generates the error above. This is because we attempt to search for the user using the userPrincipalName attribute. If a login id is supplied without the userPrincipalName value then we attempt to search for it by appending "@<user.active.directory.domain>". In this case it was looking for: myeastuser@east.tsqa.support
But this user is not valid, although in my active directory environment it is a menu option for me to change the usersPrincipalName. This is another option if your active directory admin, the user, and whoever else is okay with making this change.