Additional Information

Helpful Tips

• Tenable One Vulnerability Management or Tenable Security Center passes the policy and credential values down to Tenable Nessus. These values include the Delinea Secret Server host, port, object identifier, and authentication information.

• The Tenable Nessus scanner communicates with the Delinea Secret Server API, and the API returns the username, password, or SSH key required for target authentication.

• The scanner uses these values for target authentication.

Auto-Discovery Process

The Delinea Secret Server Auto-Discovery integration begins by performing an initial collection of bulk host target details and object identifiers, guided by the criteria specified in the scan credentials. The process then populates the discovered hosts into the targets list and saves the object identifiers as Knowledge Base (KB) items.

Once the compilation of hosts and KBs finishes, authentication starts on each targeted host. For every host, the integration pulls the necessary target credentials, such as the username, password, and the privilege elevation credentials when applicable.

Testing Integration Connectivity

About Secret Server custom URLs

Some users may host Delinea Secret Server on custom URLs, whereas others do not. An example of a Delinea Secret Server custom URL is:

https://IP_ADDRESS:PORT/SecretServer

In this example, the custom part is "SecretServer," and, for example, a login request would be sent to:

https://IP_ADDRESS:PORT/SecretServer/oauth2/token

Without a custom URL, it would be just:

https://IP_ADDRESS:PORT/oauth2/token

Note: Generally, cloud instances do not use any sort of custom URL, but on-premises instances may or may not.

You can use curl commands to verify connectivity between the scanner host and the Delinea Secret Server API before running a scan.

Test Delinea Secret Server API login:

Cloud:

$ curl -X POST --data-urlencode 'username=USERNAME' --data-urlencode 'password=PASSWORD' --data-urlencode 'grant_type=password' https://CUSTOMER.secretservercloud.com/oauth2/token

Internal with custom URL:

$ curl -k -X POST --data-urlencode 'username=USERNAME' --data-urlencode 'password=PASSWORD' --data-urlencode 'grant_type=password' https://IP_ADDRESS:PORT/SecretServer/oauth2/token

A successful response returns a 200 response code and lists the details of a new access_token. A 401 response indicates the authentication method does not have an Access Role granting read access to that path.

Expected output:

{"access_token":"TOKEN","token_type":"...","expires_in":"","refresh_token":"..."}

Test searching for secret name:

Cloud:

$ curl -X GET -H 'Authorization: Bearer TOKEN' 'https://CUSTOMER.secretservercloud.com/api/v1/secrets/SECRET_ID'

On-prem with custom URL:

$ curl -k -X GET -H 'Authorization: Bearer TOKEN' 'https://IP_ADDRESS:PORT/SecretServer/api/v1/secrets/SECRET_ID'

A successful response returns a 200 response code and the full details of the secret ID, including the username and password. A 401 response indicates the authentication method does not have an access role granting read access to that path. This may indicate the wrong access_token.