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

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

book

Article ID: 103870

calendar_today

Updated On:

Products

CA Release Automation - Release Operations Center (Nolio) CA Release Automation - DataManagement Server (Nolio)

Issue/Introduction

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. 

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=user.domain
use.active.directory.url=ldap://<<hostname>>:<<port_number>>
[email protected]
use.active.directory.user.password=*******


I have a test user whose sAMAccountName is: mytestuser
This users userPrincipalName is: [email protected]

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: [email protected]
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.