DocumentationAPI ReferenceRelease Notes
Documentation

Kerberos | PRA

Suggest Edits

Benefits of Kerberos integration

BeyondTrust Privileged Remote Access integrates with Kerberos to deliver single sign-on and centralized authentication. Users gain secure access without re-entering passwords, while administrators manage accounts in one place.

  • Simplify login with single sign-on.
  • Centralize account control.
  • Strengthen security with time-stamped tickets.

How do I access the Security Providers page?

  1. Use a Chromium-based browser to sign in to your Privileged Remote Access URL.
    This URL is provided in the BeyondTrust welcome email and includes your site URL followed by /login.
  2. From the left menu, click Users & Security.
    The Users page opens and displays by default.
  3. At the top of the page, click Security Providers.
    The Security Providers page displays.

Add a security provider

  1. On the Security providers page, click + Add, and then select Kerberos from the list.
    The Add Security Provider page displays.
  2. Configure the security provider following the steps below.
Kerberos fields

ℹ️

Prerequisites

  • Ensure you have a working Kerberos Key Distribution Center (KDC).
  • Synchronize clocks across all clients, the KDC, and the appliance (Network Time Protocol is recommended).
  • Create a service principal on the KDC for your appliance.

  • Name: Create a unique name to help identify this provider.

  • Enabled: If checked, your appliance can search this security provider when a user attempts to log in to the access console or /login. If unchecked, this provider will not be searched.

  • Keep display name synchronized with remote system: These values determine which fields should be used as the user's private and public display names.

  • Strip realm from principal names: Select this option to remove the REALM portion from the User Principal Name when constructing the BeyondTrust username.

  • Authorization settings

    • User handling mode: Select which users can authenticate to your appliance.

      • Allow all users: allows anyone who currently authenticates via your Key Distribution Center (KDC).

      • Allow only user principals specified in the list: allows only user principles explicitly designated.

      • Allow only user principals that match the regex: allows only users principals who match a Perl-compatible regular expression (PCRE).

    • Default group policy: Each user who authenticates against an external server must be a member of at least one group policy in order to authenticate to your appliance, logging into either the /login interface or the access console. You can select a default group policy to apply to all users allowed to authenticate against the configured server.

    • SPN handling mode

      • Allow only SPNs specified in the list: If unchecked, all configured service principal names (SPNs) for this security provider are allowed. If checked, select specific SPNs from a list of currently configured SPNs.

    • LDAP group lookup: If you want users on this security provider to be associated with their groups on a separate LDAP server, choose one or more LDAP group servers to use for group lookup.

✅

See Additional setup and tips to:

  • Understand SPN usage in Privileged Remote Access
  • Review network setup examples
  • Troubleshoot the integration
  1. Click Save at the top of the page.

Change priority order of security providers

  1. At the top of the Security providers page, click Change Order.
  2. Drag and drop security providers to set their priority. You can drag and drop servers within a cluster; clusters can be dragged and dropped as a whole.
  3. Click Save Order for prioritization changes to take effect.

Disable a security provider

Disable this security provider connection. This is useful for scheduled maintenance, when you want a server to be offline but not deleted.

  1. On the Security providers page, locate the security provider you want to disable.
  2. Click > Disable.

To re-enable the security provider, click > Enable.

View the log for a security provider

View the status history for a security provider connection.

  1. On the Security providers page, locate the security provider you want to view.
  2. Click > View Log.

Copy a security provider

Create a copy of an existing security provider configuration. This will be added as a top-level security provider and not as part of a cluster.

  1. On the Security providers page, locate the security provider you want to copy.
  2. Click > Copy.

Edit a security provider

ℹ️

If you edit the local security provider and select a default policy that does not have administrator permissions, a warning message appears. Ensure other users have administrator permissions before proceeding.

  1. On the Security providers page, locate the security provider you want to edit from the list.
  2. Click .
    The Edit security provider page displays.
  3. Edit the security provider details. The details available are the same as the Add security provider page details.
  4. Click Save at the top of the page.

Delete a security provider

  1. On the Security providers page, locate the security provider you want to delete.
  2. Click to delete the security provider.

Additional setup and tips

Kerberos: SPN use in Privileged Remote Access

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 access.example.com might ultimately resolve to the hostname internal.example.com.

access.example.com → 10.0.0.1 → 1.0.0.10.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 upgrades (HTTP/access.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/access.example.com, and installed them on your 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.

Kerberos: Network setup examples
Kerberos KDC

ℹ️

For this example:

  • The appliance may or may not be located behind a corporate firewall.
  • Users may or may not be on the same network as the appliance.
  • Users belong as members of a Kerberos realm.
  • Users can communicate with their KDC (typically over port 88 UDP).
Network diagram of Kerberos authentication setup. A client workstation connects via ports 80/443 through the Internet/WAN and firewall to a BeyondTrust appliance. User workstations communicate with the appliance and the Kerberos KDC using ports 80/443 and 88. The KDC provides authentication using a Kerberos keytab with SPN: HTTP/example@REALM.

  1. On the Kerberos KDC, register an SPN for your appliance hostname and then export the keytab for this SPN from your KDC.

  2. Log into your appliance's /login interface.

  3. Go to Users & Security > Kerberos Keytab.

  4. Under Import Keytab, click Choose File, and then select the exported keytab to upload. You should now see this SPN under the list of Configured Principals.

  5. Go to Users & Security > Security Providers. Click Add. From the dropdown, select Kerberos.

  6. Create a unique name to help identify this provider.

  7. Be sure to check the Enabled box.

  8. Choose if you want to synchronize display names.

  9. Optionally, select to remove the REALM portion from the User Principal Name when constructing the BeyondTrust username.

  10. For User Handling Mode, select Allow all users.

  11. For SPN Handling Mode, leave the box unchecked to allow all SPNs.

  12. You may also select a default group policy for users who authenticate against this Kerberos server.

  13. Click Save to save this security provider configuration.

Kerberos KDC and LDAP server on the same network

ℹ️

For this example:

  • The appliance may or may not be located behind a corporate firewall.
  • Users may or may not be on the same network as the appliance.
  • Users belong as members of a Kerberos realm.
  • Users can communicate with their KDC (typically over port 88 UDP).
  • An LDAP server exists (which may or may not be the same machine as the KDC) that maps user principal names to groups to which the users may belong.
  • The appliance can directly communicate with the LDAP server.
Network diagram of Kerberos authentication architecture. A client workstation connects through the Internet/WAN and firewall to an appliance using ports 80/443. The appliance communicates with an LDAP server via ports 389/636 and with a Kerberos KDC via port 88. User workstations also connect to the appliance. The setup includes a Kerberos keytab with SPN: HTTP/example@REALM and uses Kerberos User Provider and LDAP Group Provider for REALM.

  1. On the Kerberos KDC, register an SPN for your appliance hostname and then export the keytab for this SPN from your KDC.

  2. Log into your appliance's /login interface.

  3. Go to Users & Security > Security Providers. Click Add. From the dropdown, select LDAP.

  4. Create a unique name to help identify this provider.

  5. Be sure to check the Enabled box.

  6. Choose if you want to synchronize display names.

  7. For Lookup Groups, select either Only perform group lookups or Allow user authentication and perform group lookups.

  8. Continue to configure the settings for this LDAP server.

  9. For the User Query, enter a query that can tie the User Principal Name as supplied in the user's Kerberos ticket to a single entry within your LDAP directory store.

  10. Click Save to save this security provider configuration.

  11. Go to Users & Security > Kerberos Keytab.

  12. Under Import Keytab, click Choose File, and then select the exported keytab to upload. You should now see this SPN under the list of Configured Principals.

  13. Go to Users & Security > Security Providers. Click Add. From the dropdown, select Kerberos.

  14. Create a unique name to help identify this provider.

  15. Be sure to check the Enabled box.

  16. Choose if you want to synchronize display names.

  17. Optionally, select to remove the REALM portion from the User Principal Name when constructing the BeyondTrust username.

  18. For User Handling Mode, select Allow all users.

  19. For SPN Handling Mode, leave the box unchecked to allow all SPNs.

  20. In LDAP Group Lookup, select the server configured in this process and add it to the Group Providers In Use list.

  21. You may also select a default group policy for users who authenticate against this Kerberos server.

  22. Click Save to save this security provider configuration.

Kerberos KDC and LDAP Server on Separate Networks

ℹ️

For this example:

  • The appliance may or may not be located behind a corporate firewall.
  • Users may or may not be on the same network as the appliance.
  • Users belong as members of a Kerberos realm.
  • Users can communicate with their KDC (typically over port 88 UDP).
  • An LDAP server exists (which may or may not be the same machine as the KDC) that maps user principal names to groups to which the users may belong.
  • The appliance cannot directly communicate with the LDAP server.
Network diagram of Kerberos and LDAP authentication architecture. A client workstation connects via ports 80/443 through the Internet/WAN and firewall to a BeyondTrust appliance in the DMZ. User workstations also connect to the appliance and to the Kerberos Key Distribution Center (KDC) using port 88. A connection agent communicates with the firewall via ports 80/443 and with an LDAP server via ports 389/636. The setup includes a Kerberos keytab with SPN: HTTP/example@REALM and uses Kerberos User Provider and LDAP Group Provider for REALM.

  1. On the Kerberos KDC, register an SPN for your appliance hostname and then export the keytab for this SPN from your KDC.

  2. Log into your appliance's /login interface.

  3. Go to Users & Security > Security Providers. Click Add. From the dropdown, select LDAP.

  4. Create a unique name to help identify this provider.

  5. Be sure to check the Enabled box.

  6. Choose if you want to synchronize display names.

  7. For Lookup Groups, select either Only perform group lookups or Allow user authentication and perform group lookups.

  8. Continue to configure the settings for this LDAP server.

  9. Because the LDAP server does not have direct communication with the appliance, check the option Proxy from appliance through the Connection Agent.

  10. Create a password for the connection agent.

  11. Click Download Connection Agent to install the agent on a system behind your firewall. When installing the connection agent, provide the name and password you created for this LDAP server.

  12. For the User Query, enter a query that can tie the User Principal Name as supplied in the user's Kerberos ticket to a single entry within your LDAP directory store.

  13. Click Save to save this security provider configuration.

  14. Go to Users & Security > Kerberos Keytab.

  15. Under Import Keytab, click Choose File, and then select the exported keytab to upload. You should now see this SPN under the list of Configured Principals.

  16. Go to Users & Security > Security Providers. Click Add. From the dropdown, select Kerberos.

  17. Create a unique name to help identify this provider.

  18. Be sure to check the Enabled box.

  19. Choose if you want to synchronize display names.

  20. Optionally, select to remove the REALM portion from the User Principal Name when constructing the BeyondTrust username.

  21. For User Handling Mode, select Allow all users.

  22. For SPN Handling Mode, leave the box unchecked to allow all SPNs.

  23. In LDAP Group Lookup, select the server configured in this process and add it to the Group Providers In Use list.

  24. You may also select a default group policy for users who authenticate against this Kerberos server.

  25. Click Save to save this security provider configuration.

Kerberos KDC in multiple realms

ℹ️

For this example:

  • The appliance may or may not be located behind a corporate firewall.
  • Users may or may not be on the same network as the appliance.
  • Users may belong as members of multiple Kerberos realms existing in the corporate infrastructure (traditionally, a multi-domain hierarchy in Windows).
  • If a DMZ realm exists, the users' realms may have inbound trusts with that DMZ realm, allowing principals in the trusted realms to obtain tickets for services in the DMZ realm.
A network diagram shows the flow of data and security protocols between client workstations, the internet or WAN, firewalls, an appliance, and three Kerberos Key Distribution Centers labeled DMZ Realm KDC, Realm1 KDC, and Realm2 KDC. Connections are made using ports 80 and 443 for HTTP and HTTPS traffic and port 88 for Kerberos authentication. The diagram includes a Kerberos keytab with the service principal name HTTP/example@REALM. It also defines two security providers: one for Realm1 where the user principal name matches the regular expression open parenthesis dot asterisk close parenthesis at REALM1, and another for Realm2 with a similar pattern open parenthesis dot asterisk close parenthesis at REALM2. The image emphasizes secure authentication and realm-based user validation using Kerberos protocols.

  1. Register one or more of the SPNs according to the following rules:

    • If a DMZ Kerberos realm is involved, register a unique SPN within the DMZ realm.
    • If no DMZ Kerberos realm is involved and no trust exists between the two realms, register a unique SPN in each realm.
    • If no DMZ Kerberos realm is involved and trust exists between the two realms, register a unique SPN in a realm of your choosing.

  2. Export all registered SPNs.

  3. Log into your appliance's /login interface.

  4. Go to Users & Security > Kerberos Keytab.

  5. Under Import Keytab, click Choose File, and then select the exported keytab to upload. You should now see this SPN under the list of Configured Principals.

  6. Repeat the previous step for each exported keytab.

  7. Go to Users & Security > Security Providers. Click Add. From the dropdown, select Kerberos.

  8. Create a unique name to help identify this provider.

  9. Be sure to check the Enabled box.

  10. Choose if you want to synchronize display names.

  11. Optionally, select to remove the REALM portion from the User Principal Name when constructing the BeyondTrust username.

  12. If using a DMZ realm or using the same SPN for multiple realms, you will want to match on user principle name to identify users from the first realm.

  13. If you registered multiple SPNs, choose the SPN that users from the first realm will use.

  14. You may also select a default group policy for users who authenticate against this Kerberos server.

  15. Click Save to save this security provider configuration.

  16. Repeat steps 7 through 15 for each realm from which users will authenticate, substituting the UPN or SPN rule for each realm as appropriate.

Kerberos: Troubleshoot the integration
Failed logins

If a user cannot log into BeyondTrust using valid credentials, please check that at least one of the following sets of criteria is met.

  1. The user has been expressly added to an existing group policy.
  2. A default group policy has been set for the security provider configuration created to access the server against which the user is authenticating.
  3. The user is a member of a group that has been expressly added to an existing group policy, and both user authentication and group lookup are configured and linked.
Error 6ca and slow logins
  1. A 6ca error is a default response signifying that the appliance has not heard back from the DNS server. It may occur when attempting to log into the access console access console.
  2. If users are experiencing extremely slow logins or are receiving the 6ca error, verify that DNS is configured in your /appliance interface.
Troubleshooting individual providers

When configuring an authentication method tied to group lookup, it is important to configure user authentication first, then group lookup, and finally group policy memberships. When troubleshooting, you will want to work in reverse.

  1. Verify that the group policy is looking up valid data for a given provider and that you do not have any @@@ characters in the Policy Members field.
  2. If a group provider is configured, verify that its connection settings are valid and that its group Search Base DN is in the proper format.
  3. If you want to use group lookup, verify that the security provider is set to look up group memberships of authenticated users.
  4. To test the user provider, set a default policy and see if your users can log in

Updated 16 days ago

©2003-2025 BeyondTrust Corporation. All Rights Reserved. Other trademarks identified on this page are owned by their respective owners. BeyondTrust is not a chartered bank or trust company, or depository institution. It is not authorized to accept deposits or trust accounts and is not licensed or regulated by any state or federal banking authority.