Onboard Discovery prerequisites

Similar to the Adaptable Application used for provisioning, the Adaptable application type requires that you first create a PowerShell script that implements the Discover-Certificates function and save it in the <Venafi_Home>\Scripts\AdaptableApp directory of the Trust Protection Foundation server.

After creating and saving your script to the correct directory, you must assign it by policy to the folder containing the device objects to be scanned by selecting it from the policy's PowerShell Script list (policy > Applications > Adaptable sub-tab). For more information, see Assigning the PowerShell script to a policy.

For more information about the Discover-Certificates function, see Discover-Certificates function. For more information about the Adaptable Framework and PowerShell scripting, see PowerShell script reference for Adaptable Application.

If you're using Amazon Web Services (AWS) as your installation type, do the following before you create your onboard discovery job:

• Review AWS permission requirements.

  See AWS permission requirements.

• Create an Amazon credential.

  When configuring your onboard discovery job, you'll need to select your Amazon credential.

  See About Amazon credentials.

• Create a policy folder that where discovered AWS certificates and installations can be placed.

  See Creating policies.

If you're using Microsoft Azure Key Vault as your installation type, do the following before you create your onboard discovery job:

• Review Azure permission requirements.

  See Azure permission requirements.

• Create a certificate credential.

  When configuring your onboard discovery job, you'll need to select a certificate credential.

  See About credential objects.

• Create a policy folder where discovered Azure Key Vault certificates can be placed.

  See Creating policies.

Use this application type to specifically discover Internet Information Service (IIS) bindings only (available websites and corresponding certificates). All other certificates in CAPI are excluded.

Each binding that is discovered is represented in Trust Protection Foundation by a new CAPI application object and an associated certificate.

For prerequisite information, refer to the CAPI driver topic, CAPI driver prerequisite configuration.

Onboard Discovery interfaces with Citrix NetScaler devices using their Nitro API, which is supported by Citrix NetScaler 10.5 (or higher).

For prerequisite information, refer to the NetScaler driver topic, NetScaler prerequisite configuration.

Onboard discovery interfaces with F5 LTM Advanced devices using their iControl REST API, which is fully supported by versions 11.5 (or higher) of the F5 Networks product.

F5 LTM Advanced Permissions: At minimum, the user account used by Trust Protection Foundation to access your F5 device must have the Administrator role, which can be assigned to a local user or a Remote Role Group for a non-local user. This is because the Administrator role is the least privilege required for interfacing with the iControl REST API.

Onboard Discovery interfaces with DataPower devices, versions 7.2 (or higher), because those are the versions that support a REST API.

For prerequisite information, refer to the DataPower driver topic, IBM WebSphere DataPower prerequisite configuration.

If you're using Palo Alto Networks as your installation type, do the following before you create your onboard discovery job:

• Review Palo Alto Networks permission requirements.

  See Palo Alto Networks Firewall permission requirements.

• Create a certificate credential.

  When configuring your onboard discovery job, you'll need to select a certificate credential.

  See About credential objects.

• Create a policy folder where discovered Palo Alto Networks certificates can be placed.

  See Creating policies.

• Renew any Palo Alto Networks application that was created before 26.2, or record its settings.

  Onboard discovery matches the bindings it finds on a firewall against the applications Trust Protection Foundation already has, and part of what it matches on is recorded only when an application provisions on 26.2 or later. An application that hasn't provisioned since the upgrade doesn't match, so the first discovery run against its device disables it, renames it with an - obsolete suffix, and creates a replacement application that has only the discovered binding and default settings. Per-application settings such as Lock Config and Replace Certificate are not carried over, and anything that refers to the application by name or DN then points at a disabled object.

  Renewing each application once on 26.2 before you run the job avoids this. If you can't renew first, record the settings of every existing Palo Alto Networks application, reapply them to the replacements after the job runs, and delete the disabled originals once the replacements provision correctly.

If you're using Panorama as your installation type, do the following before you create your onboard discovery job:

• Give the discovery account enough Panorama XML API access to read the configuration.

  Discovery reads the Panorama configuration, the templates and template stacks you choose to import from, and the device groups that hold decryption policy rules. If you also want private keys, the account needs to be able to export certificates. Discovery makes no configuration change and issues no commit, so it does not need rights to commit.

• Assign a user name and password credential to the Panorama device object.

  Discovery reads the credential from the device, not from the job, so every job that scans that device signs in the same way.

  See About credential objects.

• Create a policy folder where discovered Panorama certificates can be placed.

  See Creating policies.

• Provision any Panorama application you created by hand, or record its settings.

  Onboard discovery matches the bindings it finds on Panorama against the applications Trust Protection Foundation already has, and part of what it matches on is recorded only when an application provisions. An application that you created by hand, linked a certificate to, and have not yet provisioned does not match, so the first discovery run against its device disables it, renames it with an - obsolete suffix, and creates a replacement that has only the discovered binding and default settings. Per-application settings such as Lock Config, Replace Certificate and Push to Devices are not carried over, and anything that refers to the application by name or DN then points at a disabled object.

  Provisioning each hand-created application once before you run the job avoids this. An application that has no certificate linked to it yet is adopted rather than replaced, and keeps its name, its settings and its history.

  If you cannot provision first, record the settings of every hand-created Panorama application, reapply them to the replacements after the job runs, and delete the disabled originals once the replacements provision correctly.

• Expect certificates that share a common name and an issuer to arrive as a single certificate object.

  Trust Protection Foundation groups discovered certificates by common name and issuer. Where Panorama holds several certificates that match on both, the most recent becomes the current version of one certificate object and the others become its previous versions, even though each has its own serial number and key pair. Every application that discovery creates for those certificates links to that one object.

  An application can therefore reference a certificate object whose current version is not the certificate installed at that location, and renewal and monitoring act on the object rather than on the individual certificate. Where you need the certificates managed separately, provision them from Trust Protection Foundation with distinct common names.