USER MANUALS

Setting-Up the Kerberos Authentication in the Virtual DataPort Server

To set up the Kerberos authentication in Virtual DataPort, first you need to do the post-installation tasks regarding Kerberos described in the Installation Guide.

After this, copy the keytab file to the host where the Virtual DataPort server runs. For example, to <DENODO_HOME>/conf.

After this, login with the Administration Tool as an administrator user, click the menu Administration > Server configuration and then, click the tab Kerberos configuration.

Kerberos configuration wizard

Kerberos configuration wizard

In this wizard, provide the following details:

  1. Select Use Kerberos.

  2. In the box Server principal enter the “Service Principal Name” (SPN) used to create the keytab file.

    For example, if you created the SPN with the command

    setspn -S HTTP/denodo-prod.subnet1.contoso.com@CONTOSO.COM CONTOSO.COM\denodo_server

    enter HTTP/denodo-prod.subnet1.contoso.com@CONTOSO.COM.

  3. In the box Key tab file enter the path to the keytab file.

    Important

    Enter the absolute path to the file, not a relative one.

  4. Leave the Kerberos configuration file box empty unless your environment meets one of these conditions:

    • The host where Virtual DataPort runs does not belong to a Kerberos realm (e.g. a Windows Active Directory domain).

    • Or the host where Virtual DataPort runs is Linux/Unix.

    • Or you are in a cross-domain scenario. That is, the organization has several domains.

    If the environment meets any of these conditions, enter the path to the file krb5.conf or krb5.ini

    Usually, the administrators of the Active Directory can provide a krb5 file. It is better to use one of an application that already uses Kerberos authentication to make sure it is correct.

  5. The first time you set up Kerberos, we recommend selecting the check box Activate Kerberos debug mode in case you run into any issues. Once Kerberos has been set up, disable this.

    Virtual DataPort with the update 20190903 or newer:

    If you installed the update 20190903 or newer, to obtain the Kerberos debug messages, open the file <DENODO_HOME>/conf/vdp/log4j2.xml and add the following line right below the line <Loggers>:

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

    Restart Virtual DataPort to apply the changes to this file.

    You will find the Kerberos debug messages in <DENODO_HOME>/logs/vdp/vdp.log.

    Virtual DataPort with the update 20190312 or older:

    If you installed the update 20190312 or older, to obtain the Kerberos debug messages with the update, launch Virtual DataPort from the command line and redirect the output to a file. That is because the Kerberos debug messages are logged to the standard output, not the log files. To do this, execute this:

    On Windows:

    cd <DENODO_HOME>\bin
vqlserver_startup.bat > server_kerberos_logging.log 2>&1

    On Linux:

    cd <DENODO_HOME>/bin
./vqlserver_startup.sh > server_kerberos_logging.log 2>&1

    You will find the Kerberos debug messages in the local file <DENODO_HOME>/bin/server_kerberos_logging.log.

    When you disable the Kerberos debug mode, you no longer need to redirect the output to a file.

  6. Set up the LDAP configuration to retrieve the roles assigned to the users that are authenticated with Kerberos.

    1. Database: select the database of Virtual DataPort where you have stored the LDAP data source created in the previous section.

    2. LDAP data source: select the data source.

    3. User base: node of the Active Directory that is used as scope to search nodes that represent users. You can enter more than one “User base” by clicking the button image1 beside the “User base” box. When there is more than one “User base”, the Server searches the user’s node in the first “User base” scope. If the Server does not find the node that represents the user, it searches it in the second “User base” scope. If it also fails, in the third, etc. If the Server does not find the node that represents the user, it denies access to the user.

    4. Attribute with user name: name of the attribute that contains the user name of users, in the nodes that represent users.

      Usually, this has to be “userPrincipalName”.

    5. User search pattern: pattern used to generate the LDAP queries that will be executed to obtain the nodes that represent the users that try to connect to the Server.

    6. Role base: node of the LDAP server that is used as the scope to search the nodes that represent roles that users of this database can have. You can enter more than one “Role base” by clicking the button image1 beside the “Role base” box. The LDAP query formed with the “Role search” pattern will be executed in every “Role base” scope.

    7. Attribute with role name: name of the attribute that contains the name of the role, in the nodes that represent roles.

    8. Role search pattern: pattern used to generate the LDAP queries that will be executed to obtain the nodes that represent the roles of a user. This pattern has to contain the token @{USERDN} or @{USERLOGIN} (it cannot contain both):

      • @{USERDN} will be replaced with the Distinguished Name of the user that tries to connect to this database. For example, “CN=john,CN=Users,DC=acme,DC=loc”.

      • @{USERLOGIN} will be replaced with the login name of the user that tries to connect to this database. For example, “john”.

    9. Select Assign “allusers” role for every connected user to grant the privileges of the role “allusers” to all the users that log in successfully even if this role has not been assigned to the user in the LDAP server.

      For example, if you want all users to have read access over a particular database, select this option and grant this privilege to the role “allusers”.

      This option does not modify the roles granted to the user in the LDAP server. This means that if you later clear this check box, the users that log in will not have the privileges granted by the role “allusers”.

    10. If in the Active Directory, the attribute you entered in Attribute with user name only stores the user account of the users but not the domain name, select Avoid domain name for authorization. For example, if the attribute stores “mphilips”, not “mphilips@contoso.com”

      The login name contained in a Kerberos ticket includes the domain name (e.g. “mphilips@contoso.com”). This is what, by default, the Server filters by when searching the entry of this user in Active Directory. If Attribute with user name is “userPrincipalName” and this attribute has the login name “mphilips” and not “mphilips@contoso.com”, the authentication will fail unless you select this check box.

      If you select this check box, the Server will search for entries whose “userPrincipalName” is “mphilips”.

    The appendix Useful Tools to Debug Issues with Active Directory or Other LDAP Servers contains a list of tools useful to debug problems related to finding a user and its roles in the Active Directory and other LDAP servers.


Once you restart the Server, the Kerberos authentication will be available for:

When the Denodo JDBC driver, the ODBC driver and the administration tool establish a connection, they negotiate with the Server the type of authentication (user/password or Kerberos). So, by default, after enabling Kerberos in the Server, they will be able to keep using user/password authentication. If before you enabled Kerberos, they were able to connect (you created the user accounts in Virtual DataPort or set up databases with LDAP authentication), they will still be able to connect with user and password.

Enabling Kerberos Authentication for ODBC Connections Using Old Versions of the Driver

The information of this section does not apply if you connect to Denodo using the Denodo ODBC driver included in 7.0u20210818 and you installed the update 7.0u20210818 of Denodo.

This information applies to you if in your organization there are applications that use one of these two ODBC drivers to connect to Virtual DataPort:

  1. The PostgreSQL ODBC driver (e.g. Tableau and other tools use this driver), even if you installed the update 7.0u20210818 of Denodo.

  2. Or the Denodo ODBC driver of the update 7.0u20210224 or older.

When you use any of these ODBC drivers, the authentication method is set by Virtual DataPort, not the client application. That is because these drivers cannot negotiate if the authentication method is Kerberos or user/password. These drivers use the method that Virtual DataPort indicates. Therefore, to use Kerberos authentication, you have to configure Virtual DataPort to do so. To do this, follow these steps.

  1. Click the menu Administration > Database management.

  2. Select one database and click Edit.

  3. In ODBC/ADDO.net authentication type, select Allow only Kerberos authentication for ODBC/ADO.NET authentication.

Consider this:

  • When enabling this on a database, all applications that connect to this database have to use Kerberos.

  • We suggest you only do this change in one database. Then, in the client applications that want to use Kerberos authentication, when providing the connection details, enter this database. Once the connection is established, the application will be able to query the views of all the databases.

Disable Kerberos Replay Cache

A replay cache (or “rcache”) keeps track of all the tickets recently presented by a client application that connects to Denodo. The purpose of this cache is that if a duplicate authentication request is detected in the replay cache, the Server refuses the connection and returns an error to the client. This mechanism avoids “replay attacks”.

There are scenarios where replays are adequately defended against or where performance or other considerations outweigh the risk of replays. If that is the case, you may want to disable this protection. To do this, add the following system property to the Java Virtual Machine (JVM) settings of the Virtual DataPort server.

-Dsun.security.krb5.rcache=none

After adding this property, restart Virtual DataPort for the change to take effect. After this, a client can use the same Kerberos ticket during all its validity period.

This section explains how to change the JVM settings from the Control Center. This other section explains how to change it from the command line.

Cross-Domain Authentication

If the Active Directory of your organization has multiple domains and/or forests, you need to enable “cross-domain” authentication. To do this, follow these steps:

  1. The administrator of Active Directory has to create a trust relationship between both domains. This relationship may exist already.

  2. In Virtual DataPort, edit the LDAP data source used in the Kerberos configuration of Virtual DataPort, and select the check box Use GSSAPI SASL authentication mechanism.

  3. In most cases, provide a krb5 file in the Kerberos configuration. This krb5 file has to be defined for this multi-domain environment. This is not mandatory but usually is necessary (it depends on the configuration of Active Directory).


If the Active Directory servers of each Windows domain use different authentication protocols (e.g. in one domain, they require ldaps and in another domain, ldap), consider this:

  1. In the LDAP data source used in the Kerberos configuration, the URL has to be configured with the protocol supported by the primary domain (i.e. ldaps:// or ldap://).

  2. In the Kerberos configuration of Virtual DataPort, in the User base and Role base fields that point to a domain that use a different protocol than the primary domain, add a prefix with the connection URL.

    For example, if the primary domain requires ldaps but a secondary domain requires ldap, enter this for the secondary domain

    User base: ldap://denodo-prod.subnet2.contoso.com:389/CN=Users,DC=contoso,DC=com
Role base: ldap://denodo-prod.subnet2.contoso.com:389/CN=Groups,DC=contoso,DC=com
Add feedback