Setting-up Kerberos Authentication¶
Several modules of the Denodo Platform support Kerberos authentication:
The Virtual DataPort server
The Information Self-Service Tool
The Diagnostic and Monitoring Tool
The Scheduler server and administration tool
Before enabling this support, you have to perform these tasks:
Configure the Kerberos authentication server to be able to authenticate the Virtual DataPort server and its users.
If necessary, install the “Unlimited Strength Policy Files” for the Java Cryptography Extension (JCE). This section explains when that is necessary.
Optionally, modify the Windows registry to use the native ticket cache so the user does not have to enter her credentials when opening the administration tool.
After performing these steps, you have to configure the Virtual DataPort server and its clients to use Kerberos authentication. The section Kerberos Authentication of the Virtual DataPort Administration Guide explains how to do this.
Configuring the Kerberos Authentication Server (e.g. Active Directory)¶
You need to perform the following tasks on Active Directory (or the Kerberos server your organization uses):
Declare a Service Principal Name (SPN) and associate it with the user of the Virtual DataPort server.
In many organizations, only the administrators of the Active Directory can do this.
Creating a User in the Active Directory¶
Create a service account in the Active Directory, which the Virtual DataPort server will use to authenticate itself. This user account has to meet these requirements:
Create a User account, not a Machine account or a Computer account.
Clear the option User must change password at next logon.
We recommend selecting Password never expires.
Select This account supports AES 128 bit encryption and clear This account supports AES 256 bit encryption.
If you select This account supports AES 256 bit encryption, the encryption level is higher, but you will have to install the Unlimited Strength Policy Files for the “Java Cryptography Extension” (JCE) in:
All the clients that connect to Virtual DataPort using the JDBC driver.
And in all the hosts that have an administration tool.
And in the host that runs the Virtual DataPort server.
The reason you have to install this package to use AES 256 is that Java, by default, does not support this level of encryption due to export regulations.
Using AES 128 bit encryption does not require installing this package.
To do this in Active Directory, follow these steps:
Launch the tool Active Directory Users and Computers (in the menu Programs > Administrative Tools).
Right click the Users node and select New > User (do not select Machine nor Computer).
denodo_server_prodin the “Logon name” field. You can enter a different name; the rest of the examples use this name.
Click Next and enter a password.
denodo_server_prodin the “Users” tree, in the left side pane and double-click it.
Click the tab Account of
denodo_server_prodand in the panel Account options, do this:
Clear the check box User must change password at next logon.
Select Password never expires. Otherwise, you will have to reconfigure and restart the Virtual DataPort server every time the password expires.
Select This account supports AES 128 bit encryption
Clear This account supports AES 256 bit encryption
Clear Use Kerberos DES encryption types for this account.
Declaring a Service Principal Name (SPN)¶
A Service Principal Name (SPN) is a unique identifier for a service running on a server. SPNs are used by Kerberos authentication to associate a service instance with a service logon account.
To define a SPN, follow these steps:
Open a command prompt as an administrator, either from the host where the Denodo server is going to run or from the “Windows Domain Controller”.
With the utility
setspn, declare the SPN and associate it with the user account created in the previous step (denodo_server_prod).
setspn -U -S HTTP/<Fully Qualified Domain Name of the Denodo server> <REALM>\<server account>
setspn -U -S HTTP/denodo-dv-prod.contoso.com CONTOSO.COM\denodo_server_prod
The output should be like:
Checking domain DC=contoso,DC=com Registering ServicePrincipalNames for CN=Denodo Production Server,CN=Users,DC=contoso,DC=com HTTP/denodo-dv-prod.contoso.com Updated object
If you are doing this for a Denodo server that will be part of a cluster of Denodo servers and the client applications will connect to it through a load balancer, use the host name defined in the load balancer, not the actual host name of the Denodo server.
Verify that the user account only has one SPN. To do this, execute
setspn -L <user account>. For example,
setspn -L CONTOSO.COM\denodo_server_prod
The output should be like:
Registered ServicePrincipalNames for CN=denodo_server_prod,CN=Users,DC=contoso,DC=com: HTTP/denodo-dv-prod.contoso.com
Registered ServicePrincipalNames for CN=denodo_server_prod,CN=Users,DC=contoso,DC=com: HTTP/denodo-dv-prod.contoso.com HTTP/denodo-dv-prod
Consider the following fules regarding SPNs:
In step #2, if
setspn -s ...returns an error like “Duplicate SPN found, aborting operation!”, it means this SPN is already registered, either on this account or another one. The SPN you use for Kerberos authentication of the Denodo servers cannot be associated with more than one user account. If it is, this authentication will not work.
The user account cannot be associated with two different SPNs either. If it is, the Kerberos authentication will fail for ODBC clients, web services, the Information Self-Service Tool, the Diagnostic and Monitoring Tool, and the Scheduler administration tool. The Denodo JDBC driver and the administration tool will be able to connect.
The SPN has to comply with the following two rules.
The host name (in this example “host1.subnet1.contoso.com”) has to be the Fully Qualified Domain Name (FQDN) of the host where the Virtual DataPort server runs or in case of a cluster of Denodo servers, the FQDN of the load balancer.
The “service class” of the SPN has to be
HTTP, except for the Scheduler server (it could be any string, for instance,
When web browsers request a Kerberos ticket, they do it for the service “HTTP/<host name of the URL you are accessing>” (the browser forms the SPN with “HTTP” even if you use the protocol “https”). The SPN of this ticket has to match the SPN that the Denodo servers will use; otherwise the authentication will fail.
If the SPN does not meet these rules, the Kerberos authentication will fail for ODBC clients, web services, the Information Self-Service Tool, the Diagnostic and Monitoring Tool, and the Scheduler administration tool. The Denodo JDBC driver and the administration tool will be able to connect.
SPNs are case insensitive when used by Microsoft Windows-based computers. However, Linux/Unix is case-sensitive and requires the proper case to function properly. So when you create the SPN and configure the Virtual DataPort server, always enter the names with the proper case. That is, the host name in lower case (e.g. denodo-prod.subnet1.contoso.com) and the domain name in upper case (e.g. CONTOSO.COM).
If your organization uses Microsoft Active Directory 2003 or earlier, you cannot use the -S switch because it is not available for that version. In that case, replace -S with -a but make sure that the same SPN is not associated to two user accounts.
See the documentation of
See what a Fully Qualified Domain Name is at https://en.wikipedia.org/wiki/Fully_qualified_domain_name.
Generating a Keytab File¶
Generate a keytab file for the Virtual DataPort server. A keytab file contains pairs of Kerberos principals and encrypted keys derived from the password of a user account.
From the command line of the Windows Domain Controller, execute this (only domain administrators can run it):
ktpass /out denodo.keytab /princ <SPN with FQDN>@<REALM> /mapUser <server Active Directory account> /crypto ALL -pass * /ptype KRB5_NT_PRINCIPAL
ktpass /out denodo_server_prod.keytab /princ HTTP/denodo-dv-prod.contoso.com@CONTOSO.COM /mapuser denodo_server_prod /pass * /crypto ALL /ptype KRB5_NT_PRINCIPAL
You will have to enter the password of the user account “denodo_server_prod”.
Make sure the password entered is correct. ktpass does not validate that the password entered here is the correct one. It just generates the keytab based on the password you enter.
You should see something like:
Successfully mapped HTTP/denodo-dv-prod.contoso.com to denodo_server_prod. Type the password for HTTP/denodo-dv-prod.contoso.com: Type the password again to confirm: Password succesfully set! Key created. Key created. Key created. Key created. Key created. Output keytab to denodo.keytab: Keytab version: 0x502 keysize 70 HTTP/denodo-dv-prod.contoso.com@CONTOSO.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x1 (DES-CBC-CRC) keylength 8 (0xfbeaece643fef213) keysize 70 HTTP/denodo-dv-prod.contoso.com@CONTOSO.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x3 (DES-CBC-MD5) keylength 8 (0xfbeaece643fef213) keysize 78 HTTP/denodo-dv-prod.contoso.com@CONTOSO.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x17 (RC4-HMAC) keylength 16 (0x25e19011618301a73e20fda538e18a91) keysize 94 HTTP/denodo-dv-prod.contoso.com@CONTOSO.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x12 (AES256-SHA1) keylength 32 (0x0370175225b496a88a120973d70e28bb9e94f113a2b827926ad52d093471f35f) keysize 78 HTTP/denodo-dv-prod.contoso.com@CONTOSO.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x11 (AES128-SHA1) keylength 16 (0x60c3d8c6f43727deeaccc480f8101c41)
See more about this utility in its documentation .
Copy the file denodo_server_prod.keytab to the host where the Denodo server runs. If this server is part of a cluster of Denodo servers, copy it to all these servers.
Step #3 (Optional)
Only do this step if you plan on creating JDBC data sources that will use the option “pass-through session credentials” and Kerberos authentication. If not, continue to the next post-installation task.
After running setspn and ktpass, the configuration of the user account in Active Directory changes in two ways:
In the Account tab, the field User logon name changes to the Service Principal Name (before, it was just the name user account).
There is a new tab: Delegation. If you are going to use “pass-through session credentials” and Kerberos authentication on the data sources that support it, select one of these:
Trust this user for delegation to any service. With this option, known as “opened delegation”, Active Directory will allow Virtual DataPort to connect to any service on behalf of its users.
Trust this user for delegation to specified services only. If you select this, you also have to do this:
Select Use any authentication protocol. Otherwise, the pass-through session credentials of Kerberos will not work.
In Services to which this account can present delegated credentials, add the SPNs (Service Principal Names) of the databases and web services that you want Denodo to access on behalf of users.
With this option, known as “constrained delegation”, Active Directory will allow Virtual DataPort to connect only to the services on this list.
For clarification, the options in the Delegation tab only affects to services (databases or web services) to which Virtual DataPort will connect with Kerberos authentication and “pass-through session credentials”. Otherwise, it does not matter.
If you select Trust this user for delegation to specified services only, you are enabling what it is called “constrained delegation”.
In this case, the queries sent to Virtual DataPort could fail if they involve a JDBC data source with the authentication option “pass-through session credentials” and the driver does not support Kerberos authentication with constrained delegation. Read the section Connecting to a JDBC Source with Kerberos Authentication of the Administration Guide to check if in your scenario, you can enable this option.
To use “constrained delegation”, you have to configure the Denodo server to run with Java 8. Otherwise, an error java.security.PrivilegedActionException: java.lang.ClassNotFoundException: com.sun.security.jgss.ExtendedGSSCredential will be shown.
Repeat the process described in this page (create a user account, define the SPN and create the keytab), for each cluster of Denodo servers. For the Denodo servers that are not in a cluster, repeat the process for each server. More details:
All the Denodo servers of a cluster must share the same SPN. Therefore, they need to use the same account in Active Directory and use the same keytab file. By cluster, we are referring to a group of Denodo servers that are all accessed through the same hostname, which points to a load balancer that distributes the connections across the Denodo servers of the cluster.
Each cluster must have its own user account in Active Directory, SPN and keytab. Two clusters cannot share a keytab, nor an SPN, nor a user account. Therefore, you need to create the user accounts “denodo_server_development”, “denodo_server_staging”, “denodo_server_production”, etc.
If in the future you regenerate the keytab file for a server, you have to copy the keytab to all the servers that use the same SPN. That is because when a keytab is regenerated, the previous keytabs associated to that user account stop working.
Installing the “Unlimited Strength Policy Files” for the Java Cryptography Extension (JCE)¶
Jump to the next task if in Active Directory, you did not select the option This account supports AES 256 bit encryption in the configuration of the user account.
If you did, install the “Unlimited Strength Policy Files” for the Java Cryptography Extension (JCE). To do this, follow these steps:
Download the Unlimited strength JCE package for Java 7.
Although the Denodo Platform includes Java 7, you can configure it to run with Java 8. In that case, download this package for Java 8 instead.
Make a copy of the original JCE policy files (
local_policy.jarof the folder
<DENODO_HOME>/jre/lib/security/). This will allow reverting to the original policy versions.
Copy the jar files included the downloaded file to
If you configured Denodo to run with a JRE other than the one included by Denodo, copy these files to the
lib\securityfolder of JRE you are using, instead of to the Denodo’s JRE.
You need to install this in:
The host where the Virtual DataPort server runs.
All the clients that connect to Virtual DataPort using the JDBC driver.
In all the hosts that have an administration tool.
And in the host that runs the Virtual DataPort server.
You do not need to install it in the hosts of the clients that connect to the ODBC interface or from a browser (e.g. clients of the Information Self-Service Tool).
Modifying the Windows Registry to Use the Native Ticket Cache¶
The Virtual DataPort administration tool provides “Single Sign-on” (SSO), which means that the users do not need to enter their password to log in.
If the administration tool runs on Windows and you want to use this feature, you have to modify the Windows registry of the host where the tool runs. That way, the tool will be able to obtain the Kerberos ticket that the system acquired when you logged in to the system. The reason for having to modify the registry to use SSO is that Microsoft added a new feature in which they no longer export the session keys for Ticket-Granting Tickets (TGTs). As a result, the native TGT obtained on Windows has an “empty” session key and null EType.
You do not have to do anything to use single sign-on on Linux or to connect to the Denodo server using the ODBC driver.
Jump to the next task if you are not going to use “single sign-on” or the administration tool runs on Linux.
Note that you can use Kerberos authentication without modifying the registry by providing the user and the password when you log in. This is what you do when selecting Use user/password of the Kerberos authentication options of the administration tool.
To modify the registry, follow these steps:
Look for the key
Right-click the “Parameters” node and click New > DWORD.
Enter the name of the entry:
Double click on the new entry and set the value to
You have to do this in all these hosts:
All the hosts where Virtual DataPort administration tools run and whose users want to use Kerberos authentication.
All the hosts where JDBC clients run and want to use Kerberos authentication.
You have to do this when the client runs on Windows because, as explained in the Troubleshooting page for Kerberos authentication of the Java Runtime Environment, Windows does not give access to the session key of a Ticket-Granting Ticket (TGT) by defaults. This change in the registry will make the session key for TGT accessible, so Java can use it to acquire additional service tickets.
Even if you modify the registry, if the user that starts the administration tool belongs to the group “local administrator” of that computer, the tool will not be able to retrieve the Kerberos ticket from the system. This will make the single sign-on to fail. If that is the case, use the options Use user/password or Use ticket cache of the Kerberos authentication options of the administration tool.
The information provided in this section also applies to the Denodo JDBC driver.