Cybervaults are not working from one of the tenants in the orchestrator.
It was working fine, before dns migrations. even after migrations 7 tenants are working fine out of 8.
any suggestions, how can we fix this?
Since CyberArk was working before the DNS migration and 7 out of 8 tenants are still working, I would first compare the affected tenant with one of the working tenants.
I’d check it step by step:
1. Check DNS
From the affected Robot/Orchestrator machine, check whether the CyberArk hostname is resolving correctly after the DNS migration.
2. Check connectivity
Verify that the affected machine can reach the CyberArk server and required port. Also check whether any firewall/proxy rule is blocking it.
3. Compare CyberArk configuration
Compare the CyberArk Credential Store configuration of the affected tenant with a working tenant and make sure the settings are the same.
4. Check certificate/trust
If CyberArk is accessed over HTTPS, verify that the required certificate and trust chain are valid on the affected machine.
5. Check logs
Finally, check the Orchestrator/Robot logs for the exact error — especially DNS, timeout, SSL/certificate, or authentication errors.
Since only one tenant is affected, the comparison with a working tenant should help narrow down where the issue is.
If you share the exact error message from the logs, we can troubleshoot it further.
Hope this helps!
i have verified, settings and authentications everything seems correct. only issue with Tenant.
Error says: could not connect with asset ,code 2304 error
Hi @rajasekhar_openrpa , thanks for confirming.
Since the settings and authentication are correct and only one tenant is affected, I would focus on the tenant-specific connectivity/configuration.
- Check whether the CyberArk hostname resolves correctly from the affected machine after the DNS migration.
- Verify that the affected machine can connect to the CyberArk endpoint/required port.
- Double-check the CyberArk Credential Store / CCP Web Service Name for this tenant.
- Also verify that the asset’s External Name matches the CyberArk account/object.
- If everything looks correct, check the Orchestrator and CyberArk logs at the time of the failure.
Since the error is 2304, the logs should help confirm whether the request is reaching CyberArk or failing before that.
If you can share the full 2304 error message (without sensitive information), we can narrow it down further.
Hope this helps!
Hi @rajasekhar_openrpa ,
Since 7 tenants work and only 1 fails after the DNS migration, focus on the affected tenant configuration:
- Compare the CyberArk Credential Store settings with a working tenant. Credential stores are configured at tenant level in Orchestrator.
- Verify the CyberArk hostname/DNS resolution and connectivity from the Orchestrator machine.
- Check the CyberArk Allowed Machines/Application configuration, as UiPath supports IP/hostname/DNS restrictions there.
- Recheck the affected tenant’s asset mapping and CyberArk Safe permissions.
- Check Orchestrator logs for the exact DNS, authentication, SSL, or connection error.
Thanks
Hi @rajasekhar_openrpa ,
If this Error 2304 comes up (Failed to read Credential from Credential Store type CyberArk Error code: 2304), it means Orchestrator reached out to the integration layer, but the CyberArk SDK / CCP call failed to pull the object.
Just check three specific tenant areas
CyberArk App ID “Allowed Machines”: In CyberArk PVWA, open the App ID used by this tenant. Under the Authentication tab, verify that allowed IPs/hostnames aren’t stuck on the pre-migration network details.
Credential Store Endpoint: In Orchestrator, open Tenant > Credential Stores and compare this tenant’s setup with a working one. Ensure the URL/FQDN or Web Service Name hasn’t been hardcoded to an old address.
Look for the error timestamp: it will show the underlying CyberArk response (e.g., `APPAP004E Invalid Application ID`, `APPAP133E Safe does not exist`, or `Could not find password!`). That exact line will tell you if it’s a safe permission, app ID, or endpoint issue.
And please go through these links also.
Please mark it as a solution if it helped for you.
Thanks,
Ankit
Raise it with the UiPath support team on customerportal.
No changes in Cyberark vaults in Orchestrator , only New SSL certificate updated with password. to making sure we have uploaded the certificate multiple times . also created new vault with Same configration.
1.i dont see any miss in the configurations
2. safes are working , same safes and external names are working from other tenants
3. Issues with specific tenant VMS, it is failing all the VMs related to specific Tenant.
4. is there any specific settings i need to check it from tenant.
As Ashok suggested, just Raise a ticket with the UiPath support team.
Hi @rajasekhar_openrpa, since the only change on that tenant was the new cert, check it matches what Orchestrator expects for CyberArk CCP. The Client Certificate has to be a PKCS12 .pfx with both private and public key, with its password, and installed on the CCP AIMWebService host. In PVWA, update that tenant’s App ID authentication with the new certificate serial number. If CCP uses a new self-signed root, upload it as the Server Root Certificate. The other tenants working against the same Safe points to cert auth for this tenant, not the Safe. Managing credential stores