Windows
The Windows credentials menu item has settings to provide Nessus with information such as SMB account name, password, and domain name. By default, you can specify a username, password, and domain with which to log in to Windows hosts. Also, Nessus supports several different types of authentication methods for Windows-based systems.
Regarding the authentication methods:
- The Lanman authentication method was prevalent on Windows NT and early Windows 2000 server deployments. It is retained for backward compatibility.
- The NTLM authentication method, introduced with Windows NT, provided improved security over Lanman authentication. The enhanced version, NTLMv2, is cryptographically more secure than NTLM and is the default authentication method chosen by Nessus when attempting to log into a Windows server. NTLMv2 can use SMB Signing.
- SMB signing is a cryptographic checksum applied to all SMB traffic to and from a Windows server. Many system administrators enable this feature on their servers to ensure that remote users are 100% authenticated and part of a domain. In addition, make sure you enforce a policy that mandates the use of strong passwords that cannot be easily broken via dictionary attacks from tools like John the Ripper and L0phtCrack. It is automatically used by Nessus if the remote Windows server requires it. There have been many different types of attacks against Windows security to illicit hashes from computers for re-use in attacking servers. SMB Signing adds a layer of security to prevent these man-in-the-middle attacks.
- The SPNEGO (Simple and Protected Negotiate) protocol provides Single Sign On (SSO) capability from a Windows client to various protected resources via the users’ Windows login credentials. Nessus supports use of SPNEGO Scans and Policies: Scans 54 of 151 with either NTLMSSP with LMv2 authentication or Kerberos and RC4 encryption. SPNEGO authentication happens through NTLM or Kerberos authentication; nothing needs to be configured in the Nessus policy.
- If an extended security scheme (such as Kerberos or SPNEGO) is not supported or fails, Nessus attempts to log in via NTLMSSP/LMv2 authentication. If that fails, Nessus then attempts to log in using NTLM authentication.
- Nessus also supports the use of Kerberos authentication in a Windows domain. To configure this, the IP address of the Kerberos Domain Controller (actually, the IP address of the Windows Active Directory Server) must be provided.
Server Message Block (SMB) is a file-sharing protocol that allows computers to share information across the network. Providing this information to Nessus allows it to find local information from a remote Windows host. For example, using credentials enables Nessus to determine if important security patches have been applied. It is not necessary to modify other SMB parameters from default settings.
The SMB domain setting is optional and Nessus is able to log on with domain credentials without this setting. The username, password, and optional domain refer to an account that the target machine is aware of. For example, given a username of joesmith and a password of my4x4mpl3, a Windows server first looks for this username in the local system’s list of users, and then determines if it is part of a domain.
Regardless of credentials used, Nessus always attempts to log into a Windows server with the following combinations:
- Administrator without a password
- A random username and password to test Guest accounts
- No username or password to test null sessions
The actual domain name is only required if an account name is different on the domain from that on the computer. It is entirely possible to have an Administrator account on a Windows server and within the domain. In this case, to log on to the local server, use the username of Administrator with the password of that account. To log on to the domain, use the Administrator username with the domain password and the name of the domain.
When multiple SMB accounts are configured, Nessus tries to log in with the supplied credentials sequentially. Once Nessus is able to authenticate with a set of credentials, it checks subsequent credentials supplied, but only use them if administrative privileges are granted when previous accounts provided user access.
Some versions of Windows allow you to create a new account and designate it as an administrator. These accounts are not always suitable for performing credentialed scans. Tenable recommends that the original administrative account, named Administrator be used for credentialed scanning to ensure full access is permitted. On some versions of Windows, this account may be hidden. The real administrator account can be unhidden by running a DOS prompt with administrative privileges and typing the following command:
C:\> net user administrator /active:yes
If an SMB account is created with limited administrator privileges, Nessus can easily and securely scan multiple domains. Tenable recommends that network administrators consider creating specific domain accounts to facilitate testing. Nessus includes various security checks for Windows 10, 11, Windows Server 2012, Server 2012 R2, Server 2016, Server 2019, and Server 2022 that are more accurate if you provide a domain account. Nessus attempts to try several checks if no account is provided.
Note: The Windows Remote Registry service allows remote computers with credentials to access the registry of the computer being audited. If the service is not running, reading keys and values from the registry is not possible, even with full credentials. This service must be started for a Nessus credentialed scan to fully audit a system using credentials.
For more information, see the Tenable blog post.
Credentialed scans on Windows systems require that you use a full administrator level account. Several bulletins and software updates by Microsoft have made reading the registry to determine software patch level unreliable without administrator privileges, but not all of them. Nessus plugins check that the provided credentials have full administrative access to ensure they execute properly. For example, full administrative access is required to perform direct reading of the file system. This allows Nessus to attach to a computer and perform direct file analysis to determine the true patch level of the systems being evaluated.
Authentication Methods
Option | Default | Description |
---|---|---|
Never send credentials in the clear |
Enabled |
For security reasons, Windows credentials are not sent in the clear by default. |
Do not use NTLMv1 authentication |
Enabled |
If this option is disabled, then it is theoretically possible to trick Nessus into attempting to log into a Windows server with domain credentials via the NTLM version 1 protocol. This provides the remote attacker with the ability to use a hash obtained from Nessus. This hash can be potentially cracked to reveal a username or password. It may also be used to log into other servers directly. Force Nessus to use NTLMv2 by enabling the Only use NTLMv2 setting at scan time. This prevents a hostile Windows server from using NTLM and receiving a hash. Because NTLMv1 is an insecure protocol this option is enabled by default. |
Start the Remote Registry service during the scan |
Disabled |
This option tells Nessus to start the Remote Registry service on computers being scanned if it is not running. This service must be running for Nessus to execute some Windows local check plugins. |
Enable administrative shares during the scan |
Disabled |
This option allows Nessus to access the ADMIN$ and C$ administrative shares, which can be read with administrator privileges. Caution: The administrative shares have to be enabled for this setting to work properly. For most operating systems, ADMIN$ and C$ are enabled by default. However, Windows 10, Windows 11, and later Windows versions disable ADMIN$ by default. Therefore, you need to manually enable ADMIN$ in Windows environments in addition to using this setting for full access to the registry entries. For more information, see https://support.microsoft.com/kb/842715/en-us. |
Start the Server service during the scan | Disabled |
When enabled, the scanner temporarily enables the Windows Server service, which allows the computer to share files and other devices on a network. The service is disabled after the scan completes. By default, Windows systems have the Windows Server service enabled, which means you do not need to enable this setting. However, if you disable the Windows Server service in your environment, and want to scan using SMB credentials, you must enable this setting so that the scanner can access files remotely. |
Tip: To view whether your CyberArk credentials were successfully authenticated, view the plugin output of the integration_status.nasl plugin once the scan is complete. For more information, see Plugins.
CyberArk is a popular enterprise password vault that helps you manage privileged credentials. Nessus Manager can get credentials from CyberArk to use in a scan.
Option | Description | Required |
---|---|---|
CyberArk Host |
The IP address or FQDN name for the CyberArk AIM Web Service. This can be the host, or the host with a custom URL added on in a single string. |
yes |
Port |
The port on which the CyberArk API communicates. By default, Tenable uses 443. |
yes |
AppID |
The Application ID associated with the CyberArk API connection. |
yes |
Client Certificate | The file that contains the PEM certificate used to communicate with the CyberArk host. |
no |
Client Certificate Private Key | The file that contains the PEM private key for the client certificate. |
yes, if private key is applied |
Client Certificate Private Key Passphrase | The passphrase for the private key, if required. |
yes, if private key is applied |
Kerberos Target Authentication |
If enabled, Kerberos authentication is used to log in to the specified Linux or Unix target. |
no |
Key Distribution Center (KDC) |
(Required if Kerberos Target Authentication is enabled) This host supplies the session tickets for the user. |
yes |
KDC Port |
The port on which the Kerberos authentication API communicates. By default, Tenable uses 88. |
|
KDC Transport |
The KDC uses TCP by default in Linux implementations. For UDP, change this option. If you need to change the KDC Transport value, you may also need to change the port as the KDC UDP uses either port 88 or 750 by default, depending on the implementation. |
|
Domain |
(Required if Kerberos Target Authentication is enabled) The domain to which Kerberos Target Authentication belongs, if applicable. |
yes |
Get credential by |
The method with which your CyberArk API credentials are retrieved. Can be Address, Identifier, Parameters, or Username. Note: For more information about the Parameters option, refer to the Parameters Options table. Note: The frequency of queries for Username is one query per target. The frequency of queries for Identifier is one query per chunk. This feature requires all targets have the same identifier. Note: The Username option also adds the Address parameter of the API query and assigns the target IP of the resolved host to the Address parameter. This may lead to failure to fetch credentials if the CyberArk Account Details Address field contains a value other than the target IP address. |
yes |
Username |
(If Get credential by is set to Username) The username of the CyberArk user to request a password from. |
no |
Safe |
The CyberArk safe the credential should be retrieved from. |
no |
Address | The option should only be used if the Address value is unique to a single CyberArk account credential. | no |
Account Name | (If Get credential by is Identifier) The unique account name or identifier assigned to the CyberArk API credential. | no |
Use SSL |
If enabled, the scanner uses SSL through IIS for secure communications. Enable this option if CyberArk is configured to support SSL through IIS. |
no |
Verify SSL Certificate |
If enabled, the scanner validates the SSL certificate. Enable this option if CyberArk is configured to support SSL through IIS and you want to validate the certificate. |
no |
Tip: To view whether your CyberArk credentials were successfully authenticated, view the plugin output of the integration_status.nasl plugin once the scan is complete. For more information, see Plugins.
You can now take advantage of a significant improvement to Tenable’s CyberArk Integration which gathers bulk account information for specific target groups without entering multiple targets.
Option |
Description |
Required |
---|---|---|
CyberArk Host |
The IP address or FQDN name for the user’s CyberArk Instance. |
yes |
Port |
The port on which the CyberArk API communicates. By default, Tenable uses 443. |
yes |
AppID |
The Application ID associated with the CyberArk API connection. |
yes |
Safe |
Users may optionally specify a Safe to gather account information and request passwords. |
no |
AIM Web Service Authentication Type |
There are two authentication methods established in the feature. IIS Basic Authentication and Certificate Authentication. Certificate Authentication can be either encrypted or unencrypted. |
yes |
CyberArk PVWA Web UI Login Name |
Username to log in to CyberArk web console. This is used to authenticate to the PVWA REST API and gather bulk account information. |
yes |
CyberArk PVWA Web UI Login Password |
Password for the username to log in to CyberArk web console. This is used to authenticate to the PVWA REST API and gather bulk account information. |
yes |
CyberArk Platform Search String |
String used in the PVWA REST API query parameters to gather bulk account information. For example, the user can enter UnixSSH Admin TestSafe, to gather all Windows platform accounts containing a username Admin in a Safe called TestSafe. Note: This is a non-exact keyword search. A best practice would be to create a custom platform name in CyberArk and enter that value in this field to improve accuracy. |
yes |
Use SSL |
If enabled, the scanner uses SSL through IIS for secure communications. Enable this option if CyberArk is configured to support SSL through IIS. |
yes |
Verify SSL Certificate |
If enabled, the scanner validates the SSL certificate. Enable this option if CyberArk is configured to support SSL through IIS and you want to validate the certificate. |
no |
Tip: To view whether your CyberArk credentials were successfully authenticated, view the plugin output of the integration_status.nasl plugin once the scan is complete. For more information, see Plugins.
CyberArk is a popular enterprise password vault that helps you manage privileged credentials. Nessus Manager can get credentials from CyberArk to use in a scan.
Option | Description |
---|---|
Username |
The target system’s username. |
CyberArk AIM Service URL |
The URL of the AIM service. By default, this setting uses |
Central Credential Provider Host |
The CyberArk Central Credential Provider IP/DNS address. |
Central Credential Provider Port |
The port on which the CyberArk Central Credential Provider is listening. |
Central Credential Provider Username |
If the CyberArk Central Credential Provider is configured to use basic authentication, you can fill in this setting for authentication. |
Central Credential Provider Password |
If the CyberArk Central Credential Provider is configured to use basic authentication, you can fill in this setting for authentication. |
Safe |
The safe on the CyberArk Central Credential Provider server that contained the authentication information you would like to retrieve. |
CyberArk Client Certificate | The file that contains the PEM certificate used to communicate with the CyberArk host. |
CyberArk Client Certificate Private Key | The file that contains the PEM private key for the client certificate. |
CyberArk Client Certificate Private Key Passphrase | The passphrase for the private key, if required. |
AppId | The AppId that has been allocated permissions on the CyberArk Central Credential Provider to retrieve the target password. |
Folder | The folder on the CyberArk Central Credential Provider server that contains the authentication information you would like to retrieve. |
PolicyId |
The PolicyID assigned to the credentials you would like to retrieve from the CyberArk Central Credential Provider. |
Use SSL |
If CyberArk Central Credential Provider is configured to support SSL through IIS check for secure communication. |
Verify SSL Certificate |
If CyberArk Central Credential Provider is configured to support SSL through IIS and you want to validate the certificate check this. Refer to custom_CA.inc documentation for how to use self-signed certificates. |
CyberArk Account Details Name |
The unique name of the credential you want to retrieve from CyberArk. |
Tip: To view whether your Delinea credentials were successfully authenticated, view the plugin output of the integration_status.nasl plugin once the scan is complete. For more information, see Plugins.
Option | Description | Required |
---|---|---|
Delinea Authentication Method | Indicates whether to use credentials or an API key for authentication. By default, Credentials is selected. | yes |
Delinea Login Name |
The username to authenticate to the Delinea server. |
yes |
Delinea Password |
The password to authenticate to the Delinea server. This is associated with the Delinea Login Name you provided. |
yes |
Delinea API Key | The API key generated in the Secret Server user interface. This setting is required if the API Key authentication method is selected. | yes |
Delinea Secret |
The value of the secret on the Delinea server. The secret is labeled Secret Name on the Delinea server. |
yes |
Delinea Host |
The Delinea Secret Server IP address for API requests. |
yes |
Delinea Port |
The Delinea Secret Server Port for API requests. By default, Tenable uses 443. |
yes |
Checkout Duration |
The duration Tenable should check out the password from Delinea. Duration time is in hours and should be longer than the scan time. |
yes |
Use SSL |
Enable if the Delinea Secret Server is configured to support SSL. |
no |
Verify SSL Certificate |
If enabled. verifies the SSL Certificate on the Delinea server. |
no |
Tip: To view whether your QiAnXin credentials were successfully authenticated, view the plugin output of the integration_status.nasl plugin once the scan is complete. For more information, see Plugins.
Option | Description | Required |
---|---|---|
QiAnXin Host |
The IP address or URL for the QiAnXin host. |
yes |
QiAnXin Port |
The port on which the QiAnXin API communicates. By default, Tenable uses 443. |
yes |
QiAnXin API Client ID |
The Client ID for the embedded account application created in QiAnXin PAM. |
yes |
QiAnXin API Secret ID |
The Secret ID for the embedded account application created in QiAnXin PAM. |
yes |
Domain | The domain to which the username belongs. |
no |
Username |
The username to log in to the hosts you want to scan. |
yes |
Host IP |
Specify the host IP of the asset containing the account to use. If not specified, the scan target IP is used. |
no |
Platform |
Specify the platform (based on asset type) of the asset containing the account to use. If not specified, a default target is used based on credential type (for example, for Windows credentials, the default is WINDOWS). Possible values:
|
no |
Region ID |
Specify the region ID of the asset containing the account to use. |
Only if using multiple regions. |
Use SSL | When enabled, Tenable uses SSL for secure communication. This is enabled by default. |
no |
Verify SSL Certificate |
When enabled, Tenable verifies that the SSL Certificate on the server is signed by a trusted CA. |
no |
Tip: To view whether your Senhasegura credentials were successfully authenticated, view the plugin output of the integration_status.nasl plugin once the scan is complete. For more information, see Plugins.
Option | Description | Required |
---|---|---|
Senhasegura Host |
The IP address or URL for the Senhasegura host. |
yes |
Senhasegura Port |
The port on which the Senhasegura API communicates. By default, Tenable uses 443. |
yes |
Senhasegura API Client ID |
The Client ID for the applicable Senhasegura A2A Application for Oauth 2.0 API authentication. |
yes |
Senhasegura API Secret ID | The Secret ID for the applicable Senhasegura A2A Application for Oauth 2.0 API authentication. |
yes |
Domain | The domain to which the username belongs. |
no |
Senhasegura Credential ID or Identifier | The credential ID or identifier for the credential the you are requesting to retrieve. |
yes |
Private Key File |
The Private Key used to decrypt encrypted sensitive data from A2A. Note: You can enable encryption of sensitive data in the A2A Application Authorizations. If enabled, the user must provide a private key file in the scan credentials. This can be downloaded from the applicable A2A application in Senhasegura. |
Required if you have enabled encryption of sensitive data in A2A Application Authorizations. |
HTTPS |
This is enabled by default. |
yes |
Verify SSL Certificate |
This is disabled by default. |
no |
Option | Default Value |
---|---|
Username |
(Required) The username for a user on the target system. |
Domain |
The domain of the username, if set on the Thycotic server. |
Thycotic Secret Name |
(Required) The Secret Name value on the Thycotic server. |
Thycotic Secret Server URL |
(Required) The value you want Tenable Nessus to use when setting the transfer method, target, and target directory for the scanner. Find the value on the Thycotic server, in Admin > Configuration > Application Settings > Secret Server URL. For example, if you type https://pw.mydomain.com/SecretServer, Tenable Nessus determines it is an SSL connection, that pw.mydomain.com is the target address, and that /SecretServer is the root directory. |
Thycotic Login Name |
(Required) The username for a user on the Thycotic server. |
Thycotic Password |
(Required) The password associated with the Thycotic Login Name you provided. |
Thycotic Organization |
In cloud instances of Thycotic, the value that identifies which organization the Tenable Nessus query should target. |
Thycotic Domain |
The domain, if set for the Thycotic server. |
Private Key |
If enabled, Tenable Nessus uses key-based authentication for SSH connections instead of password authentication. |
Verify SSL Certificate |
If enabled, Tenable Nessus verifies the SSL Certificate on the Thycotic server. For more information about using self-signed certificates, see Custom SSL Server Certificates. |
Tip: To view whether your BeyondTrust credentials were successfully authenticated, view the plugin output of the integration_status.nasl plugin once the scan is complete. For more information, see Plugins.
Option | Description | Required |
---|---|---|
Username | The target system’s username. |
yes |
Domain | The domain, if the username is part of a domain. |
no |
Lieberman host |
The Lieberman IP/DNS address. Note: If your Lieberman installation is in a subdirectory, you must include the subdirectory path. For example, type IP address or hostname / subdirectory path. |
yes |
Lieberman port | The port on which Lieberman listens. |
yes |
Lieberman API URL | The URL Tenable Nessus uses to access Lieberman. | no |
Lieberman user | The Lieberman explicit user for authenticating to the Lieberman RED API. |
yes |
Lieberman password | The password for the Lieberman explicit user. |
yes |
Lieberman Authenticator |
The alias used for the authenticator in Lieberman. The name should match the name used in Lieberman. Note: If you use this option, append a domain to the Lieberman user option, i.e., domain\user. |
no |
Lieberman Client Certificate |
The file that contains the PEM certificate used to communicate with the Lieberman host. Note: If you use this option, you do not have to enter information in the Lieberman user, Lieberman password, and Lieberman Authenticator fields. |
no |
Lieberman Client Certificate Private Key | The file that contains the PEM private key for the client certificate. | no |
Lieberman Client Certificate Private Key Passphrase | The passphrase for the private key, if required. | no |
Use SSL |
If Lieberman is configured to support SSL through IIS, check for secure communication. |
no |
Verify SSL Certificate |
If Lieberman is configured to support SSL through IIS and you want to validate the certificate, check this. Refer to custom_CA.inc documentation for how to use self-signed certificates. |
no |
System Name | In the rare case your organization uses one default Lieberman entry for all managed systems, enter the default entry name. |
no |
Tip: To view whether your Wallix Bastion credentials were successfully authenticated, view the plugin output of the integration_status.nasl plugin once the scan is complete. For more information, see Plugins.
Option | Description | Required |
---|---|---|
WALLIX Host |
The IP address for the WALLIX Bastion host. |
yes |
WALLIX Port |
The port on which the WALLIX Bastion API communicates. By default, Tenable uses 443. |
yes |
Authentication Type |
Basic authentication (with WALLIX Bastion user interface username and Password requirements) or API Key authentication (with username and WALLIX Bastion-generated API key requirements). |
no |
WALLIX User |
Your WALLIX Bastion user interface login username. |
yes |
WALLIX Password | Your WALLIX Bastion user interface login password. Used for Basic authentication to the API. | yes |
WALLIX API Key | The API key generated in the WALLIX Bastion user interface. Used for API Key authentication to the API. | yes |
Get Credential by Device Account Name |
The account name associated with a Device you want to log in to the target systems with. Note: If your device has more than one account you must enter the specific device name for the account you want to retrieve credentials for. Failure to do this may result in credentials for the wrong account returned by the system. |
Required only if you have a target and/or device with multiple accounts. |
HTTPS |
This is enabled by default. Caution: The integration fails if you disable HTTPS. |
yes |
Verify SSL Certificate |
This is disabled by default and is not supported in WALLIX Bastion PAM integrations. |
no |
Elevate privileges with |
This enables WALLIX Bastion Privileged Access Management (PAM). Use the drop-down menu to select the privilege elevation method. To bypass this function, leave this field set to Nothing. Caution: In your WALLIX Bastion account, the WALLIX Bastion super admin must have enabled "credential recovery" on your account for PAM to be enabled. Otherwise, your scan may not return any results. For more information, see your WALLIX Bastion documentation. Note: Multiple options for privilege escalation are supported, including su, su+sudo and sudo. For example, if you select sudo, more fields for sudo user, Escalation Account Name, and Location of su and sudo (directory) are provided and can be completed to support authentication and privilege escalation through WALLIX Bastion PAM. The Escalation Account Name field is then required to complete your privilege escalation. Note: For more information about supported privilege escalation types and their accompanying fields, see |
Required if you wish to escalate privileges. |
Database Port |
The TCP port that the Oracle database instance listens on for communications from. The default is port 1521. |
no |
Auth Type |
The type of account you want Tenable to use to access the database instance:
|
no |
Service Type | The Oracle parameter you want to use to specify the database instance: SID or SERVICE_NAME. |
no |
Service |
The SID value or SERVICE_NAME value for your database instance. The Service value you enter must match your parameter selection for the Service Type option. |
yes |
Targets to Prioritize Credentials |
Specify IPs or CIDR blocks on which this credential is attempted before any other credential. To specify multiple IPs or CIDR blocks, use a comma or space-separated list. Using this setting can decrease scan times by prioritizing a credential that you know works against your selected targets. For example, if your scan specifies 100 credentials, and the successful credential is the 59th credential out of 100, the first 58 credentials have to fail before the 59th credential succeeds. If you use Targets To Prioritize Credentials, you configure the scan to use the successful credential first, which allows the scan to access the target faster. |
no |
Tip: To view whether your HashiCorp credentials were successfully authenticated, view the plugin output of the integration_status.nasl plugin once the scan is complete. For more information, see Plugins.
Windows and SSH Credentials | ||
---|---|---|
Option | Description |
Required |
Hashicorp Vault host |
The Hashicorp Vault IP address or DNS address. Note: If your Hashicorp Vault installation is in a subdirectory, you must include the subdirectory path. For example, type IP address or hostname / subdirectory path. |
yes |
Hashicorp Vault port | The port on which Hashicorp Vault listens. | yes |
Authentication Type |
Specifies the authentication type for connecting to the instance: App Role or Certificates. If you select Certificates, additional options for Hashicorp Client Certificate(Required) and Hashicorp Client Certificate Private Key (Required) appear. Select the appropriate files for the client certificate and private key. |
yes |
Role ID | The GUID provided by Hashicorp Vault when you configured your App Role. | yes |
Role Secret ID |
The GUID generated by Hashicorp Vault when you configured your App Role. |
yes |
Authentication URL |
The path/subdirectory to the authentication endpoint. This is not the full URL. For example: /v1/auth/approle/login |
yes |
Namespace | The name of a specified team in a multi-team environment. | no |
Vault Type |
The Tenable Nessus version: KV1, KV2, AD, or LDAP. For additional information about Tenable Nessus versions, see the Tenable Nessus documentation. |
yes |
KV1 Engine URL |
(KV1) The URL Tenable Nessus uses to access the KV1 engine. Example: /v1/path_to_secret. No trailing / |
yes, if you select the KV1 Vault Type |
KV2 Engine URL |
(KV2) The URL Tenable Nessus uses to access the KV2 engine. Example: /v1/path_to_secret. No trailing / |
yes, if you select the KV2 Vault Type |
AD Engine URL |
(AD) The URL Tenable Nessus uses to access the Active Directory engine. Example: /v1/path_to_secret. No trailing / |
yes, if you select the AD Vault Type |
LDAP Engine URL |
(LDAP) The URL Tenable Nessus uses to access the LDAP engine. Example: /v1/path_to_secret. No trailing / |
yes, if you select the LDAP Vault Type |
Username Source | (KV1 and KV2) A drop-down box to specify if the username is input manually or pulled from Hashicorp Vault. | yes |
Username Key | (KV1 and KV2) The name in Hashicorp Vault that usernames are stored under. | yes |
Password Key | (KV1 and KV2) The key in Hashicorp Vault that passwords are stored under. | yes |
Domain Key (Windows) |
(Required if Kerberos Target Authentication is enabled.) The key name that the domain is stored under in the secret. |
yes |
Secret Name | (KV1, KV2, and AD) The key secret you want to retrieve values for. | yes |
Kerberos Target Authentication |
If enabled, Kerberos authentication is used to log in to the specified Linux or Unix target. |
no |
Key Distribution Center (KDC) |
(Required if Kerberos Target Authentication is enabled.) This host supplies the session tickets for the user. |
yes |
KDC Port |
The port on which the Kerberos authentication API communicates. By default, Tenable uses 88. |
no |
KDC Transport |
The KDC uses TCP by default in Linux implementations. For UDP, change this option. If you need to change the KDC Transport value, you may also need to change the port as the KDC UDP uses either port 88 or 750 by default, depending on the implementation. |
no |
Domain (Windows) |
(Required if Kerberos Target Authentication is enabled.) The domain to which Kerberos Target Authentication belongs, if applicable. |
yes |
Realm (SSH) |
(Required if Kerberos Target Authentication is enabled.) The Realm is the authentication domain, usually noted as the domain name of the target (for example, example.com). |
yes |
Use SSL | If enabled, Tenable Nessus Manager uses SSL for secure communications. Configure SSL in Hashicorp Vault before enabling this option. | no |
Verify SSL Certificate | If enabled, Tenable Nessus Manager validates the SSL certificate. Configure SSL in Hashicorp Vault before enabling this option. | no |
Enable for Tenable Nessus | Enables/disables IBM DataPower Gateway use with Tenable Nessus. | yes |
Elevate privileges with (SSH) |
Use a privilege escalation method such as su or sudo to use extra privileges when scanning. Note: Tenable supports multiple options for privilege escalation, including su, su+sudo and sudo. For example, if you select sudo, more fields for sudo user, Escalation account secret name, and Location of sudo (directory) are provided and can be completed to support authentication and privilege escalation through Tenable Nessus. Note: For more information about supported privilege escalation types and their accompanying fields, see the Nessus User Guide and the Tenable Vulnerability Management User Guide. |
Required if you wish to escalate privileges. |
Escalation account secret name (SSH) | If the escalation account has a different username or password from the least privileged user, enter the credential ID or identifier for the escalation account credential here. | no |
Targets to Prioritize Credentials |
Specify IPs or CIDR blocks on which this credential is attempted before any other credential. To specify multiple IPs or CIDR blocks, use a comma or space-separated list. Using this setting can decrease scan times by prioritizing a credential that you know works against your selected targets. For example, if your scan specifies 100 credentials, and the successful credential is the 59th credential out of 100, the first 58 credentials have to fail before the 59th credential succeeds. If you use Targets To Prioritize Credentials, you configure the scan to use the successful credential first, which allows the scan to access the target faster. |
no |
Option | Default Value |
---|---|
Centrify Host |
(Required) The Centrify IP address or DNS address. Note: If your Centrify installation is in a subdirectory, you must include the subdirectory path. For example, type IP address or hostname/subdirectory path. |
Centrify Port |
The port on which Centrify listens. |
API User | (Required) The API user provided by Centrify |
API Key |
(Required) The API key provided by Centrify. |
Tenant | The name of a specified team in a multi-team environment. |
Authentication URL |
The URL Tenable Nessus Manager uses to access Centrify. |
Password Engine URL | The name of a specified team in a multi-team environment. |
Username | (Required) The username to log in to the hosts you want to scan. |
Checkout Duration |
The length of time, in minutes, that you want to keep credentials checked out in Centrify. Configure the Checkout Duration to exceed the typical duration of your Tenable Nessus Manager scans. If a password from a previous scan is still checked out when a new scan begins, the new scan fails. Note: Configure the password change interval in Centrify so that password changes do not disrupt your Tenable Nessus Manager scans. If Centrify changes a password during a scan, the scan fails. |
Use SSL | When enabled, Tenable Nessus Manager uses SSL through IIS for secure communications. You must configure SSL through IIS in Centrify before enabling this option. |
Verify SSL | When enabled, Tenable Nessus Manager validates the SSL certificate. You must configure SSL through IIS in Centrify before enabling this option. |
Targets to Prioritize Credentials |
Specify IPs or CIDR blocks on which this credential is attempted before any other credential. To specify multiple IPs or CIDR blocks, use a comma or space-separated list. Using this setting can decrease scan times by prioritizing a credential that you know works against your selected targets. For example, if your scan specifies 100 credentials, and the successful credential is the 59th credential out of 100, the first 58 credentials have to fail before the 59th credential succeeds. If you use Targets To Prioritize Credentials, you configure the scan to use the successful credential first, which allows the scan to access the target faster. |
Tip: To view whether your Arcon credentials were successfully authenticated, view the plugin output of the integration_status.nasl plugin once the scan is complete. For more information, see Plugins.
Option | Default Value |
---|---|
Arcon host |
(Required) The Arcon IP address or DNS address. Note: If your Arcon installation is in a subdirectory, you must include the subdirectory path. For example, type IP address or hostname/subdirectory path. |
Arcon port |
The port on which Arcon listens. |
API User |
(Required) The API user provided by Arcon. |
API Key |
(Required) The API key provided by Arcon. |
Authentication URL | The URL Tenable Nessus Manager uses to access Arcon. |
Password Engine URL |
The URL Tenable Nessus Manager uses to access the passwords in Arcon. |
Username | (Required) The username to log in to the hosts you want to scan. |
Arcon Target Type | (Optional) The name of the target type. . Depending on the Arcon PAM version you are using and the system type the SSH credential has been created with, this is set to linux by default. Refer to the Arcon PAM Specifications document (provided by Arcon) for target type/system type mapping for the correct target type value. |
Checkout Duration |
(Required) The length of time, in hours, that you want to keep credentials checked out in Arcon. Configure the Checkout Duration to exceed the typical duration of your Tenable Vulnerability Management scans. If a password from a previous scan is still checked out when a new scan begins, the new scan fails. Note: Configure the password change interval in Arcon so that password changes do not disrupt your Tenable Vulnerability Management scans. If Arcon changes a password during a scan, the scan fails. |
Use SSL | When enabled, Tenable Nessus Manager uses SSL through IIS for secure communications. You must configure SSL through IIS in Arcon before enabling this option. |
Verify SSL | When enabled, Tenable Nessus Manager validates the SSL certificate. You must configure SSL through IIS in Arcon before enabling this option. |
Targets to Prioritize Credentials |
Specify IPs or CIDR blocks on which this credential is attempted before any other credential. To specify multiple IPs or CIDR blocks, use a comma or space-separated list. Using this setting can decrease scan times by prioritizing a credential that you know works against your selected targets. For example, if your scan specifies 100 credentials, and the successful credential is the 59th credential out of 100, the first 58 credentials have to fail before the 59th credential succeeds. If you use Targets To Prioritize Credentials, you configure the scan to use the successful credential first, which allows the scan to access the target faster. |