Hi,
I'm receiving an error when trying to validate to the vCAC portal with credentials that are from a trusted domain to the domain my vCAC solution is on. I am able to add the account to the vCAC Administrators group and have even tried adding the trusted domain user accounts to a security group within the domain the vCAC servers are on and adding that for permission but i keep receiving the attached error. The trust is working and validated. Has anyone experienced this problem before? I am using vCAC 5.2 FP2
Hi,
Problem comes down to the insane requirement for a two way trust between the two domains for vCAC 5.2 to work. For security reasons a two way trust isn't possible but VMware engineering have confirmed it is due to the requirement for a two way trust
Gregg
Hey,
what i feel like you have domain trust established among two different forests?
Is that is the case, do you have both way trust established or one way also wanted to know if the other trusted account is used as the service account to run services of the vCAC server?
this error generally occurs when there is issue with the authentication of the vCAC server service account or it is not able to reach either to Model Manager URI or Repository URI
Br,
MG
Hi,
Problem comes down to the insane requirement for a two way trust between the two domains for vCAC 5.2 to work. For security reasons a two way trust isn't possible but VMware engineering have confirmed it is due to the requirement for a two way trust
Gregg
strange, I knew about the two way trust but usually it doesn't result in the repo404 error which is a service not found where as you would get a 401 access denied. not saying it's not because of the two way trust, but i would have expected different behavior.
Hi,
I recently came across this same issue in vRA 6.2.1. The problem was resolved by implementing fix mentioned in this KB article # 2095768. Remember to take a snapshot beforehand and to only apply this fix on the IaaS Web server or servers if you have a distributed environment. As I understand it, this issue is caused by if the user ID is part of multiple AD groups.
Cheers,
Tony