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 postinstallation 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¶

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.

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

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

   • Or the host where this Server 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.

   When this option is enabled, the Server logs messages related to Kerberos to the standard output (not in the log files). To see these messages, launch the Virtual DataPort server from the command line.

   To redirect these debug messages to a file, start the Server like this:

   For Windows:

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

   For Linux:

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

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 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 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:

• JDBC clients that use the appropriate driver properties. The section Connecting to Virtual DataPort Using Kerberos Authentication of the Developer Guide lists these properties.

• Administration tools configured to use Kerberos authentication.

When the Denodo JDBC 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.

For ODBC clients, see the section below.

-Dsun.security.krb5.rcache=none