Palo Alto Networks Idira (CyberArk) Setup

From V8.4.2, rConfig can retrieve device credentials from Palo Alto Networks Idira, formerly CyberArk, at connection time through the Central Credential Provider (CCP). rConfig asks CCP for an account, uses the returned username and password to log in to the device, and discards them when the operation ends. Passwords stay in your Safes and rotate there.

CyberArk is now part of Palo Alto Networks and is sold as Idira. The Central Credential Provider kept its name and API, so this guide applies to existing CyberArk PAM deployments, Privilege Cloud and Idira alike, as long as rConfig can reach a CCP web service.

Early access

This integration is built from Palo Alto Networks’ published Central Credential Provider documentation and follows its documented request and response formats. As with any new integration, environments vary, so we’d welcome your feedback as you roll it out. If anything behaves differently in your deployment, contact rConfig support and we’ll work through it with you.

When to Use This Page

Use this page when your network device passwords already live in Idira (CyberArk) and you want rConfig to fetch them on demand instead of storing them. Set up the connection once per rConfig instance, then create a vault credential set for each group of devices that share an account.

Caution

You need working knowledge of your Idira (CyberArk) environment, or help from its administrator, to register the application and grant Safe access. rConfig support for vault-side configuration is limited.

Prerequisites

• A Central Credential Provider web service (/AIMWebService) that the rConfig server can reach over HTTPS
• Rights in PVWA to add an application and change Safe membership, or an administrator who can
• The network device accounts stored in a Safe
• An rConfig V8 user with permission to update integrations

Prepare Idira (CyberArk)

Step 1: Add an application for rConfig

In PVWA, go to Applications → Add Application and create an application with an ID such as rConfig. rConfig sends this as the AppID on every request.

On the application’s authentication settings, add at least one way for CCP to recognise rConfig:

• Allowed machines: the IP address or hostname of the rConfig server.
• Client certificate: optional but recommended. rConfig presents the certificate you paste in Step 2 below.

Step 2: Give the application access to the Safe

Add the rConfig application and the Credential Provider user (usually Prov_<ccp-host>) as members of the Safe that holds the device accounts, with Retrieve accounts and List accounts permissions.

Step 3: Note how to find each account

rConfig looks up an account with the same query parameters CCP accepts: usually Safe and Object (the account name), or Safe, UserName and Address. Write down the values for each credential set you plan to create.

Account Structure

CCP returns the account as JSON. The fields rConfig maps by default are:

{
  "Content": "the_device_password",
  "UserName": "netadmin",
  "Address": "10.1.1.1",
  "Safe": "Network",
  "Name": "core-switches"
}

Content is the password. If the account’s platform defines a property for the enable password (for example EnablePassword), CCP returns it alongside the other properties and you can map it. If your devices have no enable password, leave the default in place: a missing key resolves to an empty enable password.

Configure rConfig V8

Step 1: Open the Idira (CyberArk) page

Navigate to Platform → Integrations. In the Device Credentials section, click Configure next to Palo Alto Networks Idira (CyberArk).

Step 2: Enter the connection settings

Field	Required	Notes
CCP address	Yes	Base URL of the CCP server, without /AIMWebService, for example https://ccp.example.com.
Application ID	Yes	The application ID from Step 1, for example rConfig.
Test query	No	A query for a test account, for example Safe=Network&Object=rconfig-test. Without it, Test Connection only checks that CCP answers.
Timeout (seconds)	No	How long to wait for CCP. Defaults to 30.
Verify TLS certificate	No	On by default. Turn off only for a lab server with a self-signed certificate.
CA bundle (PEM)	No	Paste the CA chain if CCP’s certificate is signed by an internal CA.
Client certificate (PEM)	No	The certificate registered on the application, pasted as PEM text.
Client private key (PEM)	No	The certificate’s private key, pasted as PEM text.
Private key passphrase	No	Only if the private key is encrypted.

Certificates and keys are pasted as text, so there are no files to copy to the server. The certificate, private key and passphrase are stored encrypted. Once saved they show Saved. Leave blank to keep it. and are never sent back to the browser. Use Remove saved value under a field to clear it.

Turn on Use this vault for credential sets. rConfig won’t save it switched on until the CCP address and Application ID are filled in.

Step 3: Test, then save

Click Test Connection. rConfig uses the values in the form, including any you haven’t saved yet. With a test query, rConfig looks up that account and shows the Safe, the account name and the list of returned keys. It never shows the password. Use the key list to check the names you’ll map in the next step.

Click Save.

Upgrading from .env settings

If you set up this integration in .env (VAULT_SERVICE_NAME=cyberark and the VAULT_CYBERARK_* settings) on an early V8.4.2 build, it keeps working. The page shows a notice that its settings are read from .env. When you click Save, rConfig copies the settings into the database, including the contents of the certificate, key and CA bundle files the paths point to. After that, the VAULT_CYBERARK_* lines are ignored.

Create a Vault Credential Set

1. Navigate to System Settings → Security & Access → Device Credentials.
2. Click Add Vault Credential Set. If more than one vault is switched on, pick Palo Alto Networks Idira (CyberArk) in the Vault dropdown.
3. Fill in the form:
   • Credential Name: for example Core switches - Idira.
   • Vault Endpoint: the CCP query for the account, for example Safe=Network&Object=core-switches. Leave out AppID: rConfig always adds the Application ID from the integration page. URL-encode values that contain &, = or +.
   • Field Mapping: defaults to UserName, Content and EnablePassword. Change the enable password key to match your platform’s property name.
4. Click Add.

Then edit a device, choose the new set in the Credential Set dropdown and save. Run a backup or the debug command to confirm rConfig can log in.

Troubleshooting

Errors are written to Settings → Application Logs with the ErrorCode and ErrorMsg that CCP returned. rConfig never logs the password.

Test Connection says it can’t connect. Check DNS, firewalls and the certificate chain from the rConfig server:

curl -v "https://ccp.example.com/AIMWebService/api/Accounts?AppID=rConfig&Safe=Network&Object=rconfig-test"

If the certificate is signed by an internal CA, paste the CA chain into CA bundle (PEM).

The account isn’t found. The query doesn’t match exactly one account. Check the Safe name, the account name (Object is the account name in PVWA, not the username), and that the application can list the Safe.

The application isn’t authorised. The request didn’t match the application’s allowed machines or certificate. Confirm the rConfig server’s address as CCP sees it (NAT and proxies change it), and that the pasted certificate is the one registered on the application.

Device login fails after a successful lookup. Check the Field Mapping matches the keys shown by Test Connection. A username or password key that isn’t in the response stops the backup with a mapping error.

Backups say the vault is turned off. Use this vault for credential sets is off on the integration page, or a required setting is missing.

Common Gotchas

Common gotchas

• CCP address is the server URL only. rConfig adds /AIMWebService/api/Accounts itself.
• The vault endpoint is a query string, not a path. Network/core-switches won’t work; use Safe=Network&Object=core-switches.
• One Application ID and certificate serve every Idira (CyberArk) credential set in the instance.
• The internal name is still cyberark (for example in VAULT_CYBERARK_* and this page’s address), so existing installs and bookmarks keep working.

Related Documentation

• Vault Credentials Overview - how vault credentials fit with other credential sets
• Delinea Secret Server Setup and HashiCorp Vault Setup - the other supported vaults