This one has us scratching our heads, wondering if anyone would be able to better explain what is going on here. We're running v6.2.3 and seeing bad credential requests to vCO from our default tenant. This is causing account lockout issues. Furthermore, we don't use the default tenant, all of our customers are using a second tenant so it's a little perplexing why this would be happening at all. My guess so far has been that all ASD oriented tasks go through the default tenant regardless of which tenant the request was placed in, but on top of not making a lot of sense, that also doesn't help me figure out where the bad creds are actually stored at.
Logging in as the default tenant with administrator@vsphere.local and going to the "Event Logs" I see what appears to be attempts from the com.vmware.csp.core.designer.service.api "Service Name" to connect to the orchestrator API at https://myorchestrator:8281/vco/api. The first thing that seems a little weird to me (after the default tenant performing this work) is that the url it is attempting to hit is not correct. If I try to get there in my browser it does not work unless I add an extra '/' to the end. Not sure if that is actually a problem or not.
So here are my questions if anybody can assist with answers:
- Why is the default tenant attempting to connect with my orchestrator at all for this service when nobody uses that tenant?
- Why is the orchestrator 'Target ID' it is attempting to hit not formatted correctly?
- How can I figure out where these incorrect credentials are stored and get them updated?
Aside from this issue and the eventual account lockout caused by the bad credentials, vRA is working fine otherwise. Thanks for any help that you can provide!
