Login with domain users into Aria automation fails with "You have not been assigned access to any service. Please, contact your administrator"

Products

• VMware Aria Suite

Issue/Introduction

• This is not a 403 error: users successfully get through to Automation after authentication, but then see incorrect services or no services at all.
• Users may also see unfamiliar services available, or getting "An Error Occurred" "Please try again later" and not seeing any services on the VMware Aria Automation Cloud Services Console

An Error Occurred

Please try again later... [OK]

• The identity service app logs may display the below error.
  Path: /services-logs/prelude/identity-service-app/file-logs/identity-service-app.log
  
  
  • "GET /csp/gateway/am/api/userinfo HTTP/1.1" 500 169 8080 161 ms
Date_Time INFO identity-service [host='identity-service-app-123456789' thread='reactor-http-epoll-2' user='username (11111-2222-3333-4444-5555555555)' org='11111-2222-3333-4444-5555555555' trace='
11111-2222-3333-4444-5555555555' parent='123456789' span='123456789'] com.vmware.identity.rest.RestClient.lambda$logRequest$1:86 - GET https://FQDN/SAAS/jersey/manager/api/scim/Users?filter=(userName%)
Date_Time ERROR identity-service [host='identity-service-app-123456789' thread='reactor-http-epoll-2' user='username (11111-2222-3333-4444-5555555555)' org='11111-2222-3333-4444-5555555555' trace='11111-2222-3333-4444-5555555555' parent='123456789123456789' span='123456789123456789'] c.v.i.c.RestResponseEntityExceptionHandler.logError:225 - Handling generic exception: There is more than 1 user found.
        java.lang.IllegalStateException: There is more than 1 user found.
                at com.vmware.identity.common.util.IdmUserUtil.getUserResource(IdmUserUtil.java:33) ~[classes!/:na]
                Suppressed: reactor.core.publisher.FluxOnAssembly$OnAssemblyException:


• API-based login attempts (e.g. in Orchestrator) may face a 500 Internal Server error as follows:
  • Failed to authenticate with vRA. Status: 500 - {"timestamp":<unix-timestamp>),"path":"/iaas/api/cloud-accounts","status":500,"error":"Internal Server Error","message":"ClientResponse has erroneous status code: 500 Internal Server Error. WebClientServiceResponseException.ErrorDetails(timestamp=<human-timestamp>, path=/rbac-service/api/auth-context, type=com.vmware.automation.spring.webflux.platform.client.service.exception.WebClientServiceResponseException, errorCode=0, messageKey=null, messageArguments=null, message=ClientResponse has erroneous status code: 500 Internal Server Error. 

Environment

• VMware Aria Automation 8.x
• VMware Identity Manager 3.3.x

Cause

• This issue occurs when the same Directory Search Attribute such as SAMAccountName is being used in multiple domains in VMware Identity Manager (vIDM).
• If this is the case, then the attribute must be unique across all domains available to Aria Automation from the Identity Manager

Resolution

For now, this is working as designed: since Automation uses this Search Attribute to distinguish between accounts, these users are getting mixed up.

Please see this docs page for some discussion:
Active Directory sync and authentication with multiple domains

Workaround 1:

If the particular users which exist on multiple domains are not needed on all of these domains:

• One approach is to find the user in Identity Manager on the domain where it is not needed.
  • Click on Delete User to remove it from this domain and solve the conflict
• If an entire domain is not needed and is causing conflicts, the domain itself can be deleted on vIDM.

 

Workaround 2:

If it is necessary to continue using domains which contain conflicting usernames, the vIDM settings can be changed to distinguish users via the domain name:

1. Please take a snapshot of the vIDM node(s)
2. Delete one of the domains (e.g. AD domains) from vIDM
3. Re-add domain but this time with Directory Search Attribute set to "UserPrincipalName" instead of SAMAccountName
4. Reassign roles associated with this domain's users in Automation

Additional Information

Impact/Risks:

• The second workaround above will cause a break in assigned roles on the removed domain.
• These will need to be reassigned to users in Automation