This document details the process for configuring Kerberos in the Denodo servers.

Note: This document is the third one of a series of four 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.

Denodo server configuration (Denodo Platform - denodovm.denodo.loc)

The next step is to configure the Denodo Platform installation in order to enable Kerberos using the generated “denodovm.keytab” file. For the Denodo Platform (Virtual DataPort server) we will follow the instructions explained in the Setting-Up the Kerberos Authentication in the Virtual DataPort Server section of the Denodo documentation.

Note: check that documentation for a detailed explanation. This guide only shows the steps done in this sample environment.

Preparing Keytab

Let’s start copying the keytab to a known directory, for example /opt/denodo/shared/vdp/kerberos/denodovm.keytab

Preparing Kerberos configuration file

As this server is Linux, Virtual DataPort also needs a Kerberos configuration file. Our machine is already joined to the Windows Domain and, by default, it has a krb5.conf file located at /etc/krb5.conf

• Check krb5.conf file exists and it’s correct:

        

        You will get an output like this one:

• Note: If this file is not created for any reason, you have to create a new krb5.conf file (in any directory). Use the previous one as reference.

Important things to consider in a krb5.conf file:

1. Check domain and KDC (the Active Directory domain controller server) are correct.
2. Test KDC is accessed correctly (it should be, but just in case there’s a DNS problem). Execute:
   ping domaincontroller.denodo.loc
3. Very important: ensure the property “forwardable = true” is in the krb5 file.

• Not really needed but in some cases necessary to avoid DNS issues: the properties “rdns = false”, “dns_lookup_realm = false” and “dns_lookup_kdc = false”

4. If entries setting the algorithms for default_tkt_enctypes, default_tgs_enctypes, permitted_enctypes or preferred_enctypes are included in the krb5 file it is better to remove these lines to avoid issues and to let the KDC pick the most secure algorithm.

NOTE: A krb5 file used by a web application will not be automatically refreshed after a change. To ensure the changes in the file take effect, all Denodo servers must be completely stopped, including the Tomcat embedded web container and all web applications.  To change the krb5 file used by the web applications follow these steps:

1. Stop all Denodo services, including the web container. Make sure no Java processes are running for the Denodo JRE.
2. Edit the krb5 file as needed.
3. Start the VDP server and the web application.
4. Upload the new file to the VDP server.
5. Verify that SSO is working from the web application.

In addition to that, after a change, a web application will override the krb5 file of other web applications as they run on the same JVM. To avoid configuration problems with this, we recommend using the default location of the krb5 file or, if a custom krb5 file is needed for the web applications, to configure the same file for all the web applications running on the same web container.

Configuring the Denodo Platform

Now we have all the files needed, so we can start configuring the Denodo Platform. We will start first testing the LDAP configuration to avoid permissions issues later when Kerberos is activated in the server.

Check RMI Host in Virtual DataPort

As usual for Linux boxes, we need to ensure the RMI Host configuration of VDP is correct for connecting from external. Execute:

more /opt/denodo/denodo80/denodo-platform/conf/vdp/VDPConfiguration.properties | grep registryURL

Note: you should use the hostname of the server, in our example this is denodovm.denodo.loc

If you need to modify the RMI host, edit the VDPConfiguration.properties, save it and execute the standard script:

/opt/denodo/denodo80/denodo-platform/bin/regenerateFiles.sh

Once the RMI host configuration is correct, start the server and ensure the Virtual DataPort server is running correctly.

In order to test the connection, open a Denodo Administration Tool (from your laptop, for example) and connect to Virtual DataPort using a local user (for example, the default admin/admin user).

Note: You can use //denodovm.denodo.loc:9999/admin for the connection.

Configure console logging

By default Kerberos-related log messages are written to the console (standard output). As a best practice, it is recommended to add a new logger to the $DENODO_HOME/conf/vdp/log4j2.xml file (only with Denodo 8.0 or Denodo 7.0 starting update 20190903):

<Logger name="com.denodo.util.logging.JavaConsoleLogging" level="debug" />

After doing this modification you have to restart the VDP server (in our host, execute: service vdpserver80 restart )

Configure LDAP authentication

This step is not needed for enabling Kerberos authentication but it helps a lot for creating the roles before enabling Kerberos and for testing privileges associated with the users.

Follow these steps:

1. Create a new LDAP data source pointing to the Active Directory (domaincontroller.denodo.loc)

• Test the connection:

• Save the data source.

2. Import the roles into Virtual DataPort from Administration > Role Management > Import roles:

Why do we use that configuration? 

• In the AD we can see that groups are created inside groups folder, and that element has OU=groups,DC=denodo,DC=loc as distinguishedName:

• And if we inspect one group we see the attribute cn has the name of the group:

3. Click OK in the Administration Tool to import the roles:

4. Important step! Give privileges to the roles, for example, connection privileges or whatever.

5. The last step is to configure LDAP authentication from Administration > Database management:

Why do we use that configuration?

• Users are in the users folder which has CN=Users,DC=denodo,DC=loc as distinguishedName:y

• Checking the attributes of a user, the login information is in the sAMAccountName attribute and has several objectClass (we selected person in this example):

• For the fields related to the roles we can use the same configuration used for the Import roles from, and for the search pattern, the standard one (we can use it because the groups have the users as members using the user distinguished name)

6. Test the LDAP configuration connecting to the database using any user of the Active Directory:

Configure Kerberos in Virtual DataPort

With the previous test, we know the privileges are working so we can move to configure Kerberos!

Follow these steps:

1. In the VDP Administration Tool, go to Administration > Server Configuration > Server authentication and click the Kerberos tab:

Why do we use this configuration?

• Server Principal: this is the SPN of the user created at the beginning having the syntax shown in the screenshot.
• Keytab: browse to the keytab file copied to the denodovm machine.
• Configuration file: browser to the krb5.conf file.
• Activate Kerberos debug mode: select it to see the messages in the vdp.log (only if this step was done).
• LDAP configuration:

• You can select to use exactly the same details of the LDAP configuration used before by selecting the option “Use global LDAP configuration”. However, since one change is needed, as explained in the next point, the “Use custom LDAP configuration” option needs to be selected.
• One change from the previous LDAP configuration is needed: When Kerberos is used, there’s no user/password entered at login time, so the LDAP search is done using the principal name included in the Kerberos token of the user. Typically it corresponds to the attribute userPrincipalName of the Active Directory:

2. (Optional) You can also modify the database configuration to allow Kerberos in ODBC/ADO.NET connections:

3. After these changes, you have to restart Virtual DataPort, but before restarting, if you are connected through SSH to denodovm.denodo.loc, you can open the <DENODO_HOME>/logs/vdp/vdp.log file to see in real-time the new messages shown in the log:
   
   tail -f /opt/denodo/denodo80/denodo-platform/logs/vdp/vdp.log -n 500
   
   Leave it open.
4. From another SSH console, restart the server:
   
   service vdpserver80 restart
5. Check the vdp.log to see Kerberos messages (and other stuff). If you see something like “Commit succeed”, everything is ok:

• If any error is thrown you can check it and try to solve it (most are related to problems connecting to the KDC or AD, or a wrong keytab, or a wrong configuration of the Principal Name in the server configuration or a wrong krb5.conf, also the issues could be check encryption types and forwardable attributes).

• Check the KB document Kerberos configuration and troubleshooting to see the list of the most common issues.

Configure Kerberos in Data Catalog

Now the Virtual DataPort server was configured successfully with Kerberos. Now it’s time to configure the web applications. In our case, the Denodo Data Catalog.

Follow these steps:

1. Open a browser and navigate to the data catalog url http://denodovm.denodo.loc:29090/denodo-data-catalog/LoginLocal

1. With this URL we are using the local access to the Data Catalog, so you only have to enter the admin password (admin, by default):

2. In the Servers set up configuration, ensure the connection to the Virtual DataPort server uses the FDQN (it is a best practice):

3. In the Kerberos set up configuration, enable Kerberos with the same values used in Virtual DataPort:

4. Restart the Data Catalog.
5. Test the Data Catalog is now trying to use Kerberos when the main page is loaded:

1. Go to http://denodovm.denodo.loc:29090/denodo-data-catalog
2. Now, the login form is not showing the login and password fields. Only a Sign in button and the selector of the Virtual DataPort server.
3. If you click on Sign In the browser will try to use your Kerberos token for authentication but it will not work at this moment because further configuration is needed in the client machine.

Note: Next step in this process would be configuring the Denodo client applications and external tools to authenticate using Kerberos. You can check the third and last part of this tutorial in the following link: Kerberizing Denodo for SSO - Step by step guide - Clients Configuration (IV)