Kerberos Authentication

Tenable Identity Exposure authenticates to the configured Domain Controller(s) using the credentials you provided. These DCs accept either NTLM or Kerberos authentication. NTLM is a legacy protocol with documented security issues, and Microsoft and all cybersecurity standards now discourage its use. Kerberos, on the other hand, is a more robust protocol that you should consider. Windows always attempts Kerberos first and resorts only to NTLM if Kerberos is not available.

Tenable Identity Exposure is compatible with both NTLM and Kerberos with a few exceptions. Tenable Identity Exposure prioritizes Kerberos as the preferred protocol when it fulfills all the required conditions. This section describes the requirements and shows you how to configure Tenable Identity Exposure to ensure the use of Kerberos.

The use of NTLM instead of Kerberos is also the reason why SYSVOL hardening interferes with Tenable Identity Exposure. For more information, see SYSVOL Hardening Interference with Tenable Identity Exposure.

Compatibility with Tenable Identity Exposure Deployment Modes

Deployment Mode Kerberos Support
On-Premises Yes
SaaS-TLS (legacy) Yes
SaaS with Secure Relay Yes
SaaS with VPN No — You must switch your installation to the Secure Relay deployment mode.

  • DNS configuration and DNS server must allow resolving all necessary DNS entries — You must configure the Directory Listener or Relay machine to use DNS servers that know the domain controllers. If the Directory Listener or Relay machine is domain-joined, which Tenable Identity Exposure does not recommend, you should already meet this requirement. The easiest way is to use the domain controller itself as the preferred DNS server because it usually also runs DNS. For example:

    Note: If the Directory Listener or Relay machine is connected to several domains, and potentially in several forests, ensure that the configured DNS servers can resolve all required DNS entries for all domains. Otherwise you need to set up several Directory Listener or Relay machines.

  • Reachability of the Kerberos “server” (KDC) — This requires network connectivity from the Directory Listener or Relay to domain controllers over port TCP/88. If the Directory Listener or Relay is domain-joined, which Tenable does not recommend, you should already meet this requirement. Each configured Tenable Identity Exposure forest requires Kerberos network connectivity with at least one domain controller in its respective domain containing the service account, as well as at least one domain controller in each connected domain.

    For more information about requirements, see Network Flow Matrix.

    Note: The Directory Listener or Relay machine does not need to be domain-joined to use Kerberos.

To configure the AD service account and AD domain in Tenable Identity Exposure to use Kerberos:

  1. Use the User PrincipalName (UPN) format for the login. In this example, the UPN attribute is “[email protected]”.

    1. Locate the UPN attribute in the domain of the forest that contains the service account as follows:

    Note: The UPN looks like an email address, and it is even often - but not always – the same as the user’s email.

    1. In Tenable Identity Exposure, in the forest configuration section , set this UPN instead of the short “username” format or the NetBIOS “domain\username” format, as follows:

  1. Use the Fully Qualified Domain Name (FQDN) In the domain configuration in Tenable Identity Exposure, set the FQDN for the Primary Domain Controller (PDC) instead of its IP.

Kerberos requires several configuration steps to work properly. Otherwise, Windows, and by extension Tenable Identity Exposure, silently fall back to NTLM authentication.

DNS

Ensure that the DNS server(s) used on the Directory Listener or Relay machine can resolve the provided PDC FQDN, such as:

Kerberos

To verify that Kerberos works with the commands you run on the Directory Listener or Relay machine:

  1. Verify that the AD service account configured in Tenable Identity Exposure can obtain a TGT:

  1. In a command line or PowerShell, run “runas /netonly /user:<UPN> cmd” and type the password. Be extra cautious when typing or pasting the password because there is no verification due to the “/netonly” flag.

  2. At the second command prompt, run “klist get krbtgt” to request a TGT ticket.

    The following example shows a successful result:

    The following are potential error codes:

    • 0xc0000064: "User logon with misspelled or bad user account" -> Check the login (i.e. the part before the ‘@’ in the UPN).

    • 0xc000006a: "User logon with misspelled or bad password" -> Check the password.

    • 0xc000005e: "There are currently no logon servers available to service the logon request." -> Check that DNS resolution works and that the server can contact the returned KDC(s), etc.

    • Other error codes: See the Microsoft documentation relating to 4625 events.

  1. Verify that the domain controller configured in Tenable Identity Exposure can obtain a service ticket. In the same second command prompt, run "klist get host/<DC_FQDN>" (replace "<DC_FQDN>").

    The following example shows a successful result: