Implementing Kerberos SSO for Protegrity Appliances

• 1: Prerequisites
• 2: Setting up Kerberos SSO
• 3: Logging to the Appliance
• 4: Scenarios for Implementing Kerberos SSO
• 5: Viewing Logs
• 6: Feature Limitations
• 7: Troubleshooting

1 - Prerequisites

For implementing Kerberos SSO, ensure that the following prerequisites are considered:

• The appliances, such as, the ESA, or DSG are up and running.
• The AD is configured and running.
• The IP addresses of the appliances are resolved to a Fully Qualified Domain Name (FQDN).

2 - Setting up Kerberos SSO

This section describes the different tasks that an administrative user must perform for enabling the Kerberos SSO feature on the Protegrity appliances.

Importing Users and Assigning Role

In the initial steps for setting up Kerberos SSO, a user with administrative privileges must import users from an AD to the appliance. After importing, assign the required permissions to the users for logging with SSO.

To import users and assign roles:

1. On the appliance Web UI, navigate to Settings > Users > Proxy Authentication.

2. Enter the required parameters for connecting to the AD.

   For more information about setting AD parameters, refer here.

3. Navigate to the Roles tab.

4. Create a role or modify an existing role.

5. Select the SSO Login permission check box for the role and click Save.

   If you are configuring SSO on the DSG, then ensure the user is also granted the required cloud gateway permissions.

6. Navigate to the User Management tab.

7. Click Import Users to import the required users to the internal LDAP.

   For more information about importing users, refer here.

8. Assign the role with the SSO Login permissions to the required users.

Creating Service Principal Name (SPN)

A Service Principal Name (SPN) is an entity that represents a service mapped to an instance on a network. For a Kerberos-based authentication, the SPN must be configured in Active Directory (AD). For Protegrity appliances, only Microsoft AD is supported. The SPN is registered with the AD. In this configuration, a service associates itself with the AD for the purpose of authentication requests.

For Protegrity, the instance is represented by appliances, such as, the ESA or DSG. It uses the SPNEGO authentication for authenticating users for SSO. The SPNEGO uses the HTTP service for authenticating users. The SPN is configured for the appliances in the following format.

service/instance@domain

Ensure an SPN is created for every ESA appliance involved in the Kerberos SSO implementation.

Example SPN creation

Consider an appliance with host name esa1.protegrity.com on the domain protegrity.com. The SPN must be set in the AD as HTTP/esa1.protegrity.com@protegrity.com.

The SPN of the appliance can be configured in the AD using the setspn command. Thus, to create the SPN for esa1.protegrity.com, run the following command.

setspn -A HTTP/esa1.protegrity.com@protegrity.com

Creating the Keytab File

The keytab is an encrypted file that contains the Kerberos principals and keys. It allows an entity to use a Kerberos service without being prompted for a password on every access. The keytab file decrypts every Kerberos service request and authenticates it based on the password.

For Protegrity appliances, an SSO authentication request of a user from an appliance to the AD passes through the keytab file. In this file, you map the appliance user’s credentials to the SPN of the appliance. The keytab file is created using the ktpass command. The following is the syntax for this command:

ktpass -out <Location where to generate the keytab file> -princ HTTP/<SPN of the appliance> -mapUser <username> -mapOp set -pass <Password> -crypto All -pType KRB5_NT_PRINCIPAL

The following sample snippet describes the ktpass for mapping a user in the keytab file. Consider an ESA appliance with host name esa1.protegrity.com on the domain protegrity.com. The SPN for the appliance is set as HTTP/esa1.protegrity.com@protegrity.com. Thus, to create a keytab file and map a user Tom, run the following command.

ktpass -out C:\esa1.keytab -princ HTTP/esa1.protegrity.com@protegrity.com -mapUser Tom@protegrity.com -mapOp set -pass Test@1234 -crypto All -pType KRB5_NT_PRINCIPAL

Uploading Keytab File

After creating the keytab file from the AD, you must upload it on the appliance. You must upload the keytab file before enabling Kerberos SSO

To upload the keytab file:

1. On the Appliance Web UI, navigate to Settings > Users > Single Sign-On.

   The Single Sign On screen appears.

2. From the Keytab File field, upload the keytab file generated.

   

3. Click the Upload Keytab icon.

   A confirmation message appears.

4. Select Ok.

   Click the Delete icon to delete the keytab file. You can delete the keytab file only when the Kerberos for single sign-on (Spnego) option is disabled.

5. Under the Kerberos for single sign-on (Spnego) tab, click the Enable toggle switch to enable Kerberos SSO.

   A confirmation message appears.

6. Select Ok.

   A message Kerberos SSO was enabled successfully appears.

Configuring SPNEGO Authentication on the Web Browser

Before implementing Kerberos SSO for Protegrity appliances, you must ensure that the Web browsers are configured to perform SPNEGO authentication. The tasks in this section describe the configurations that must be performed on the Web Browsers. The recommended Web browsers and their versions are as follows:

• Google Chrome version 129.0.6668.58/59 (64-bit)
• Mozilla Firefox version 130.0.1 (64-bit) or higher
• Microsoft Edge version 128.0.2739.90 (64-bit)

The following sections describe the configurations on the Web browsers.

Configuring SPNEGO Authentication on Firefox

The following steps describe the configurations on Mozilla Firefox.

To configure on the Firefox Web browser:

1. Open Firefox on the system.

2. Enter about:config in the URL.

3. Type negotiate in the Search bar.

4. Double click on network.negotiate-auth.trusted-uris parameter.

5. Enter the FQDN of the appliance and exit the browser.

Configuring SPNEGO Authentication on Chrome

With Google Chrome, you must set the white list servers that Chrome will negotiate with. If you are using a Windows machine to log in to the appliances, then the configurations entered in other browsers are shared with Chrome. You need not add a separate configuration.

3 - Logging to the Appliance

After configuring the required SSO settings, you can login to the appliance using Kerberos SSO.

To login to the appliance using SSO:

1. Open the Web browser and enter the FQDN of the ESA or DSG in the URL.

2. Click Sign in with Kerberos SSO.

   The Dashboard of the ESA/DSG appliance appears.

4 - Scenarios for Implementing Kerberos SSO

This section describes the different scenarios for implementing Kerberos SSO.

Implementing Kerberos SSO on an Appliance Connected to an AD

This section describes the process of implementing Kerberos SSO when an appliance utilizes authentication services of the local LDAP.

You can also login to the appliance without SSO by providing valid user credentials.

Steps to configure Kerberos SSO with a Local LDAP

Consider an appliance for which you are configuring SSO. Ensure that you perform the following steps to implement it.

1. Import users from an external directory and assign SSO permissions.
2. Configure SPN for the appliance.
3. Create and upload the keytab file on the appliance.
4. Configure the browser to support SSO.

Logging in with Kerberos SSO

After configuring the required settings, user enters the appliance domain name on the Web browser and clicks Sign in with SSO to access appliance. On successful authentication, the Dashboard of the appliance appears.

Example process

The following figure illustrates the SSO process for appliances that utilize the local LDAP.

1. The user logs in to the domain with their credentials.

   For example, a user, Tom, logs in to the domain abc.com as tom@abc.com and password *********.

2. Tom is authenticated on the AD. On successful authentication, he is logged in to the system.

3. For accessing the appliance, the user enters the FQDN of the appliance on the Web browser.

   For example, esa1.protegrity.com.

4. If Tom wants to access the appliance using SSO, then he clicks Sign in with SSO on the Web browser.

   A message is sent to the AD requesting a token for Tom to access the appliance.

5. The AD generates a SPNEGO token and provides it to Tom.

6. This SPNEGO token is then provided to the appliance to authenticate Tom.

7. The appliance performs the following checks.

   1. It receives the token and decrypts it. If the decryption is successful, then the token is valid.
   2. Retrieves the username from the token.
   3. Validates Tom with the internal LDAP.
   4. Retrieves the role for Tom and verifies that the role has the SSO Login permissions. After successfully validating the token and the role permissions, Tom can access the appliance.

Implementing Kerberos SSO on other Appliances Communicating with ESA

This section describes the process of implementing Kerberos SSO when an appliance utilizes authentication services of another appliance. Typically, the DSG depends on ESA for user management and LDAP connectivity. This section explains the steps that must be performed to implement SSO on the DSG.

Implementing Kerberos SSO on DSG

This section explains the process of SSO authentication between the ESA and the DSG. It also includes information about the order of set up to enable SSO authentication on the DSG.

The DSG depends on the ESA for user and access management. The DSG can leverage the users and user permissions that are defined in the ESA only if the DSG is set to communicate with the ESA.

The following figure illustrates the SSO process for appliances that utilize the LDAP of another appliance.

Example process

1. The user logs in to the system with their credentials.

   For example, John logs in to the domain abc.com as john@abc.com and password *********. The user is authenticated on the AD. On successful authentication the user is logged in to the system.

2. For accessing the DSG Web UI John enters the FQDN of the DSG on the Web browser.

   For example, dsg.protegrity.com.

3. If John wants to access the DSG Web UI using SSO, he clicks Sign in with SSO on the Web browser.

4. The username of John and the URL of the DSG is forwarded to the ESA.

5. The ESA sends the request to the AD for generating a SPNEGO token.

6. The AD generates a SPNEGO token to authenticate John and sends it to the ESA.

7. The ESA performs the following steps to validate John.

   1. Receives the token and decrypts it. If the decryption is successful, then the token is valid.

   2. Retrieves the username from the token.

   3. Validates John with the internal LDAP.

   4. Retrieves the role for John and verifies that the role has SSO Login .

      If ESA encounters any error related to the role, username, or token, an error is displayed on the Web UI. For more information about the errors, refer Troubleshooting.

8. On successful authentication, the ESA generates a service JWT.

9. The ESA sends this service JWT and the URL of to the Web browser.

10. The Web browser presents this JWT to the DSG for validation.

11. The DSG validates the JWT based on the secret key shared with ESA. On successful validation, John can login to the DSG Web UI.

Before You Begin:

Ensure that you complete the following steps to implement SSO on the DSG.

1. Ensure that the Set ESA Communication process is performed on the DSG for establishing communication with the ESA.

   For more information about setting ESA communication, refer to section Setting up ESA Communication in the Protegrity Data Security Gateway User Guide 3.2.0.0.

2. Import users from an external directory on the ESA and assign SSO and cloud gateway permissions.

3. Configure SPN for the ESA.

4. Create and upload the keytab file on the ESA.

5. Enable Single Sign-on on the ESA.

6. Export the JWT settings to all the DSG nodes in the cluster.

Next Steps:

After ensuring that the prerequisites for SSO in the DSG implementation are completed, you must complete the configuration on the DSG Web UI.

For more information about completing the configuration, refer to section LDAP and SSO Configurations in the Protegrity Data Security Gateway User Guide 3.2.0.0.

Exporting the JWT Settings to the DSG Nodes in the Cluster

As part of SSO implementation for the DSG, the JWT settings must be exported to all the DSG nodes that will be configured to use SSO authentication.

Ensure that the ESA, where SSO is enabled, and the DSG nodes are in a cluster.

To export the JWT settings:

1. Log in to the ESA Web UI.

2. Navigate to System > Backup & Restore.

3. On the Export, select the Cluster Export option, and click Start Wizard.

4. On the Data to import tab, select only Appliance JWT Configuration. Ensure that Appliance JWT Configuration is the only check box selected, and then click Next.

5. On the Source Cluster Nodes tab, select Create and Run a task now, and click Next.

6. On the Target Cluster Nodes tab, select all the DSG nodes where you want to export the JWT settings, and click Execute.

Implementing Kerberos SSO with a Load Balancer Setup

This section describes the process of implementing SSO with a Load Balancer that is setup between the appliances.

Steps to configure SSO in a load balancer setup

Consider two appliances, L1 and L2, that are configured behind a load balancer. Ensure that you perform the following steps to implement it.

1. Import users from an external directory on the L1 and L2 and assign SSO login permissions.
2. Ensure that the FQDN is resolved to the IP address of the load balancer.
3. Configure SPN for the load balancer.
4. Create and upload the keytab file on L1 and L2.
5. Configure the browser to support SSO.

Logging in with SSO

After configuring the required settings, the user enters the FQDN of load balancer on the Web browser and clicks Sign in with Kerberos SSO to access it. On successful authentication, the Dashboard of the appliance appears.

5 - Viewing Logs

You can view the logs that are generated for when the Kerberos SSO mechanism is utilized. The logs are are generated for the following events:

• Uploading keytab file on the appliance
• Deleting the keytab file on the appliance
• User logging to the appliance through SSO
• Enabling or disabling SSO

Navigate to Logs > Appliance Logs to view the logs.

You can also navigate on the Discover screen to view the logs.

6 - Feature Limitations

This section covers some known limitations of the Kerberos SSO feature.

Trusted Appliances Cluster

The keytab file is specific for an SPN. A keytab file assigned for one appliance is not applicable for another appliance. Thus, if your appliance is in a TAC, it is recommended not to replicate the keytab file between different appliances.

7 - Troubleshooting

This section describes the issues and their solutions while utilizing the Kerberos SSO mechanism.

Login Failure: SPNEGO authentication is not supported on this client.

Login Failure: Unauthorized to SSO Login.

Login Failure: Please contact System Administrator

Login Failure: SSO authentication disabled