You can translate the document:

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.

Note: these steps have to be done for each client connecting to Virtual Dataport!

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.
  1. 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!

  1. 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.

Note: these steps have to be done for each user of the machine (because the browser configuration is per user). Maybe it could be configured for all users using GPO but it is out of the scope of this guide.

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….”
  1. 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:

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


  1. Click ok and restart the machine if any change was done.
  2. 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.

  1. (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.
  2. 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:


  1. 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):