Configure the BeyondTrust Appliance for Kerberos Authentication
BeyondTrust supports single sign-on functionality using the Kerberos authentication protocol, enabling users to authenticate to their BeyondTrust user accounts without having to enter credentials. This document details methods for integrating the BeyondTrust Appliance in some typical Kerberos/networking configurations. This document is intended to be used by trained individuals with a working knowledge of Kerberos. It is assumed that you either have an existing implementation of Kerberos deployed or are in the process of deploying a Kerberos implementation. As there are many possible Kerberos configuration implementations, this document serves only as a guide for standard implementations.
Prior to integrating the BeyondTrust Appliance with your Kerberos configuration, ensure that the following requirements are met.
- You must have a working Kerberos Key Distribution Center (KDC).
- Clocks must be synchronized across all clients, the KDC, and the BeyondTrust Appliance. Using a Network Time Protocol (NTP) is the recommended method of synchronization.
- You must have a service principal created on the KDC for your BeyondTrust Appliance.
The most appropriate configuration for your Kerberos security provider depends on your overall authentication and network infrastructure, as well as where your BeyondTrust Appliance is located in your network. The examples in the following section demonstrate typical setups, while the chart below explains each of the Kerberos security provider options.
|Keep display name synchronized with remote system||If selected, a Kerberos-authenticated user's display name will be that of their User Principal Name. If deselected, display names can be edited locally on the BeyondTrust Appliance.|
User Handling Mode
Allow all users
|Allows anyone who currently authenticates via your KDC to log into your BeyondTrust Appliance.|
|Allow only user principals specified in the list||Allows only specified user principals to log into your BeyondTrust Appliance.|
|Allow only user principals that match the regex||Allows only user principals who match a Perl-compatible regular expression (PCRE) to log into your BeyondTrust Appliance.|
SPN Handling Mode
Allow all SPNs
|Allow all configured Service Principal Names (SPNs) for this security provider.|
|Allow only SPNs specified in the list||Allow only specific SPNs selected from a list of currently configured SPNs.|
|Default Policy||Select a group policy as the default for users authenticating against this Kerberos security provider.|
Browsers may use different methods to canonicalize the hostname for a site, including performing a reverse lookup of the IP of the hostname specified in the URL. The SPN canonicalization of this address may cause the browser to request an SPN based on an internal hostname rather than the appliance hostname.
For example, a BeyondTrust site built as hostname support.example.com may ultimately resolve to the hostname internal.example.com.
support.example.com → 10.0.0.1 → 18.104.22.168.in-addr.arpa → internal.example.com
The BeyondTrust software expects the SPN in the form of HTTP/ followed by the hostname configured in the BeyondTrust software during purchases or upgrade (HTTP/support.example.com). If the browser canonicalizes the hostname to an internal hostname and uses that hostname for the SPN (HTTP/internal.example.com), authentication will fail unless you have registered SPNs for both HTTP/internal.example.com and HTTP/support.example.com and installed them on your BeyondTrust Appliance.
If SPNs for multiple hostnames are imported, the BeyondTrust software will use the site hostname to which it was previously able to connect as a client. Therefore, if you are experiencing Kerberos authentication issues, it is advised to import a keytab for each hostname to which the site might canonicalize.