This document details the process for configuring Kerberos in the Denodo Administration Tool, Denodo Web tools and other external applications connecting to Denodo through JDBC, ODBC or REST Web Services.

Note: This document is the third one of a series of 4 documents that provide a detailed explanation on how to configure Kerberos in the Denodo server and the client tools.

You can check the Kerberizing Denodo for SSO - Step by step guide - Introduction (I) that contains the index of this set of documents and a detailed explanation of the environment used for this example.

Client Machine (Admin Tool - dev_workstation.denodo.loc)

For Kerberos to work we need to connect from a client machine joined to the same Active Directory domain. This is because we are going to use the Users defined in the Active Directory: the user used for login in Windows will be the user used for login in Virtual DataPort (this is the idea of using Kerberos as Single Sign-On, the user only needs to authenticate in Windows, the rest of applications will use those credentials).

For this guide, we are going to use the machine dev_workstation.denodo.loc as a client. It is a Windows 10 machine with a Denodo Virtual DataPort Administration Tool 8.0 installed on it. We will follow the instructions explained in the Configuring the Administration Tool to Use Kerberos Authentication section of the Denodo documentation.

This machine is added to the Windows domain DENODO.LOC:

So for login into this machine, we can use any user configured in the Active Directory.

Before starting the Kerberos configuration, let’s try to connect to Virtual DataPort using a normal user and an LDAP user:

• Test 1: connect with admin user to check if the RMI host configuration of the VDP server is correct:

• Test 2: connect with an LDAP user to check if it is working correctly:

As everything is correct, let’s configure Kerberos!

Preconfiguration (needed because it is a Windows machine)

Accessing to the Kerberos Native ticket cache

Important Note: This section only applies to Denodo 7.0 update 20190312 or earlier. Denodo 8.0 or Denodo 7.0 latest updates do not need these steps.

If the administration tool runs with the Denodo update 20190312 or earlier, in order to access the Kerberos Native ticket cache in Windows systems, we need to modify in the Windows registry the following parameter:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters\allowtgtsessionkey = 1

Preparing a Kerberos configuration file

As a best practice, check if the machine has a default Kerberos configuration file in C:/Windows/krb5.ini (please note in Windows it has .ini as file extension! -instead of .conf-). In Windows systems it is not really needed, but it is always a good idea to define one.

• If no file was created, create a new one using the same values of the krb5.conf, for example:

• The most important parts are the domain realm, the encryption types (in our case aes128 and aes256 because we disabled DES in the AD) and, of course, forwardable = true !!

Important: Restart the Windows machine after these changes (Registry and Kerberos conf).

Configure Kerberos in client Denodo Administration Tool

Let’s go to the Administration Tool to configure Kerberos! Follow these steps:

1. Open the Administration Tool and before connecting, go to Tools > Admin Tool Preferences > Authentication and select Kerberos authentication.

• Select Single Sign-On and enter the path to the krb5.ini file.

2. Click OK and now you will see that the login and password fields are disabled, so just click on Connect.

• If you get an error about the Principal Name (“Unable to obtain Principal Name for authentication”), it is because something was not correctly configured (surely, the krb5.ini was not correct):
• Check the KB document Kerberos configuration and troubleshooting to see the list of the most common issues.
• If the file was ok, you will log in successfully!

3. For validating the configuration, you can check if your connection is a Kerberos session executing the Stored Procedure get_sessions()

Configure browsers to use Kerberos in Denodo Web Applications

As the Denodo Administration Tool is working with Kerberos you can think that everything is ok for using SSO, but additional configuration is needed to use Kerberos with Denodo Web Applications because the client used to connect to Denodo is a browser (Internet Explorer/Edge/Chrome/Firefox…) and it has to be also configured to use Kerberos.

Important recommendation: start testing always using Microsoft Edge, when it works correctly then move to another browser.

Follow these steps:

1. Go to Internet Options > Security > Local Intranet > Sites  and add the denodovm server to the list:

• As we have not configured SSL in Tomcat (yet), do not select “Require https….”

2. Click OK to return to the main panel and click on the Custom level… button and ensure the Automatic logon only in Intranet zone is selected:

3. Click Ok to save the new configuration.
4. Recommended: in the Advanced tab, ensure the Integrated Windows authentication is selected:

5. Click ok and restart the machine if any change was done.
6. Edge Policies configuration: In order to use Kerberos with a Denodo web tool, the Group Policy may need to be configured as explained in the Configure Microsoft Edge for Windows Microsoft article.

The following policies need to be configured (denodo.loc is used since it is the domain for this example):

AuthNegotiateDelegateAllowlist=*.denodo.loc

AuthServerAllowlist=*.denodo.loc

DisableAuthNegotiateCnameLookup=false

Note: The DisableAuthNegotiateCnameLookup may not be required in some scenarios.

7. (Optional) Depending on your network configuration, an additional step of swapping cname and alias name in the DNS configuration is necessary, so that nslookup resolves to dns-name rather than the actual host name. You may need to contact the network administrator for more information regarding this requirement.
8. Now open an Edge browser and go to a Denodo web tool, for instance, the Data Catalog, http://denodovm.denodo.loc:29090/denodo-data-catalog and voilá, you will be authenticated directly:

9. Now test in Chrome, if you get an error connecting to the web application (“s4u2self ticket must be forwardable”, “Ticket isn’t for us” among other errors), you need an additional step for using Chrome:

• Open regedit and create the following entries in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome:
  
  AuthNegotiateDelegateAllowlist = *denodo.loc
  AuthServerAllowlist = *denodo.loc
  DisableAuthNegotiateCnameLookup = 0
  EnableAuthNegotiatePort = 0

• Restart Chrome (if it was launched) and check in chrome://policy to see if the values are correct:

• And finally go to the web tool (it should work now):

10. Finally, if you are using Mozilla Firefox you will have to open it, navigate to about:config and set the following values:
    
    network.negotiate-auth.delegation-uris = *denodo.loc
    network.negotiate-auth.trusted-uris = *denodo.loc

Accessing Denodo REST Services with HTTP SPNEGO (Kerberos) Authentication

Once the configuration is done in the browser, you can also connect to the Web Services published using SPNEGO as authentication (it uses Kerberos). For example, in our Virtual DataPort server, you can connect to the ws_orders_prcessing data service:

1. Open a browser and navigate to http://denodovm.denodo.loc:29090/server/denodo_training/ws_orders_processing/
2. You can execute the data service without using the username and password. You can check the session executing the stored procedure get_sessions().

Configure Kerberos in ODBC clients

In this section, we are going to configure an ODBC DSN connection to use Kerberos. Before doing anything please ensure the database configuration in Virtual DataPort allows Kerberos in ODBC/ADO.NET connections.

Follow these steps:

1. Install the Denodo ODBC driver and configure it following the information of the Configuration of the ODBC Driver on Windows section of the documentation.

1. The installer is available at <DENODO_HOME>/tools/client-drivers/odbc

2. Note: in dev_workstation.denodo.loc the driver is already installed in C:/denodo/denodo80/denodo-odbc-driver 

2. Open the ODBC Data Sources (64-bit) application in order to define a new System DSN for the Denodo Platform.

3. In the setup panel of the Denodo ODBC driver, enter the connection details to the Virtual DataPort (leave blank the username and password fields!):

4. Click on Datasource button and configure the following:

1. In Page 2, it is a best practice to set the timeout. Add to the Connect Settings field:
   SET QUERYTIMEOUT TO 900000;
2. In Page 3,

• Add a User Agent, for example, dev_workstationOdbc.
• Check the Use Kerberos checkbox.
• Ensure the Kerberos Service Name (Krbsrvname) matches with the service class of the Principal Name of the Virtual DataPort server. As we configured it as HTTP/denodovm.denodo.loc, the Kerberos service name has to be HTTP. If using something different, check “Redefine kerberos service name” to set a different value.

5. Test the DSN:

6. In order to test if we are using Kerberos, go again to the Denodo Administration Tool and execute the stored procedure get_sessions (you can identify the session checking the user agent used in the DSN).

Using a third-party BI Tool (MS PowerBI Desktop)

Let’s see an example using a BI tool which uses the ODBC connection: Microsoft PowerBI Desktop.

1. Open PowerBI, click on Get Data, search for Denodo and select it:

2. Enter the name of the DSN created before: DenodoODBC (in our case).

3. Select Windows authentication in order to use Kerberos:

4. Now you can Import any Denodo view :)

Configure Kerberos in JDBC clients

JDBC clients use the Denodo JDBC driver for connecting to Virtual DataPort. For using SSO (Kerberos) authentication some parameters have to be added to the connection properties (you can check the complete documentation in the Connecting to Virtual DataPort Using Kerberos Authentication section of the User Manuals).

For this example, we are going to use DbVisualizer as JDBC client application:

1. Open DbVisualizer and upload the Denodo JDBC driver using the Tools > Driver Manager menu:

2. Click on Open file icon to select the Denodo JDBC driver (located in <DENODO_HOME>/tools/client-drivers/jdbc/denodo-vdp-jdbcdriver.jar):

• Recommendation: if you are using Denodo 8.0 or Denodo 7.0 update 20190903 or newer, you should also load these files (they allow you to not update the registry to read the Kerberos Native ticket cache. For us is not important because we already did it):
  
  <DENODO_HOME>/lib/contrib/jna.jar 

and

<DENODO_HOME>/lib/contrib/jna-platform.jar

3. Close the Driver Manager and Create a new Database Connection:

4. Fill the Connection information (select the Denodo 8.0 driver and use jdbc:vdb://denodovm.denodo.loc:9999/denodo_training as URL. Leave blank Userid/Password fields):

5. In the Properties tab, configure to true the properties: useKerberos, useTicketCache and renewTGT. Also, it is a good idea to set the userAgent:

6. Click on Apply and return to the Connection tab to connect to Virtual DataPort!

7. Again, you can test calling the stored procedure get_sessions to see the connection from DbVisualizer.