USER MANUALS

Setting-up Kerberos Authentication

Several modules of the Denodo Platform support Kerberos authentication:

  • Virtual DataPort

  • Data Catalog

  • Diagnostic and Monitoring Tool

  • Scheduler and its administration tool

Before enabling Kerberos authentication on the Denodo Platform, you have to create a service account on the Active Directory of your organization and configure this account appropriately. This page explains how to do it.

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). In many organizations, only the administrators of the Active Directory can do this.

  1. Create a user in the Kerberos server of type “User”.

  2. Declare a Service Principal Name (SPN) and associate it with the user of the Virtual DataPort server.

  3. Enable Kerberos delegation for this user account.

  4. Generate a keytab file.

After this, enable Kerberos authentication on the Denodo servers.

Consider this:

  • Create one account for each installation of the Denodo Platform: one account for the Denodo server for development, one for testing, etc.

  • We recommend all the components of an installation of the Denodo Platform to share the same account to make the configuration easier. That is, share the same keytab file and the same Service Principal Name (SPN).

  • If a Denodo installation is part of a cluster of Denodo servers and their client applications will connect to them through a load balancer, use the same account for all the installations of this cluster.

Creating a User in the Active Directory

Create a service account in Active Directory. This service account has to meet these requirements:

  • Create a User account, not a Machine account nor a Computer account.

  • Clear the option User must change password at next logon.

  • We recommend selecting Password never expires.

To do this in Active Directory, follow these steps:

  1. Launch the tool Active Directory Users and Computers (in the menu Programs > Administrative Tools).

  2. Right-click the Users node and click New > User (do not select Machine nor Computer).

  3. Enter denodo_server_production in the Logon name field. You can enter a different name; the rest of the examples use “denodo_server_production”.

  4. Click Next and enter a password.

  5. Locate denodo_server_production in the Users tree, in the left side pane and double-click it.

  6. Click the tab Account of “denodo_server_production” and in the panel Account options, do this:

    • We recommend selecting Password never expires. Otherwise, you will have to reconfigure and restart the Virtual DataPort server every time the password expires.

    • For security reasons, we recommend doing this:

      • Clear Use Kerberos DES encryption types for this account

      • Select This account supports Kerberos AES 128 encryption

      • Select This account supports Kerberos AES 256 encryption

    • We recommend clearing Account is sensitive and cannot be delegated. Otherwise, you will not be able to use Kerberos with constrained delegation, to pass-through the client credentials to underlying databases.

Active Directory User Configuration (Account tab)

Active Directory User Configuration (Account tab)

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 the SPN for Denodo, follow these steps:

Step #1

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

Step #2

With the utility setspn, declare the SPN and associate it with the user account created in the previous step (“denodo_server_production”).

Syntax of the setspn utility
setspn -U -S HTTP/<Fully Qualified Domain Name of the Denodo server> <REALM>\<server account>

For example,

setspn -U -S HTTP/denodo-dv-prod.contoso.com CONTOSO.COM\denodo_server_production

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.

Step #3

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_production

The output should be like:

Registered ServicePrincipalNames for CN=denodo_server_production,CN=Users,DC=contoso,DC=com:
     HTTP/denodo-dv-prod.contoso.com

or:

Registered ServicePrincipalNames for CN=denodo_server_production,CN=Users,DC=contoso,DC=com:
    HTTP/denodo-dv-prod.contoso.com
    HTTP/denodo-dv-prod

Consider the following rules regarding SPNs:

  • In step #2, if setspn -U -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 SPN has to comply with the following rules:

    1. 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 defined in the load balancer for this cluster.

    2. The “service class” of the SPN has to be HTTP, except for the Scheduler server (it could be any string, for instance, SCHED).

      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 all the modules that require Kerberos authentication (i.e. Solution Manager, Design Studio, ODBC clients, web services, the Data Catalog, the Diagnostic and Monitoring Tool, and the Scheduler administration tool). The Denodo JDBC driver and the administration tool will be able to connect.

  • You can register several SPNs with the same user account, but the one used to generate the keytab must meet the previous rules, otherwise, the Kerberos authentication will fail with the web tools of Denodo.

  • 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 SPNs with the proper case. That is, the host name in lowercase (e.g. denodo-prod.subnet1.contoso.com) and the domain name in uppercase (e.g. CONTOSO.COM).

  • If your organization uses Microsoft Active Directory 2003 or earlier, you cannot use the -S switch in setspn 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 setspn.

See what a Fully Qualified Domain Name is at https://en.wikipedia.org/wiki/Fully_qualified_domain_name.

Enable Kerberos Delegation for this User Account

You need to do this step if:

  • You plan on enabling Kerberos authentication in the Data Catalog or Scheduler.

  • Or you plan on creating JDBC data sources that use the option “pass-through session credentials” and Kerberos authentication.

If you are not going to do any of these things, jump to the next section. You can do these changes in the future.


After running setspn and ktpass, two things change in the configuration of the user account in Active Directory:

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

Follow these steps:

  1. Open the new user account and go to the tab Delegation.

  2. Select one of these options:

    • Trust this user for delegation to any service (known as “open delegation”). With this option, Active Directory will allow Virtual DataPort to delegate to any service (database, web service…) the Kerberos credential that the user used to connect to Virtual DataPort. In addition, it will allow the Data Catalog and Scheduler to connect to Virtual DataPort using Kerberos authentication.

    • Trust this user for delegation to specified services only (known as “constrained delegation”). If you select this, you also have to do this:

      1. Select Use any authentication protocol. Otherwise, the pass-through session credentials of Kerberos will not work.

      2. In the list Services to which this account can present delegated credentials, add the following:

        • The SPN (Service Principal Name) of this same user (e.g. HTTP/denodo-dv-prod.contoso.com@CONTOSO.COM). That way, if you enable Kerberos authentication on the Data Catalog or Scheduler, these components can delegate to Virtual DataPort the Kerberos credential of the user.

        • The SPNs (Service Principal Names) of the databases and web services to which you want to allow Denodo to delegate the Kerberos credentials that the user used to connect to Virtual DataPort.

        With the option Trust this user for delegation to specified services only, Active Directory will allow Virtual DataPort - and any other Denodo components that use the same SPN - to delegate the Kerberos credentials of the users only to the services on this list.

Important

If you select Trust this user for delegation to specified services only, you are enabling “constrained delegation”. That is, the queries sent to Virtual DataPort will 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.

Active Directory User Configuration (Delegation tab)

Active Directory User Configuration (Delegation tab)

Note

Constrained delegation between two domains requires to configure Resource Based Constrained Delegation. To accomplish this, it is required to:

  1. Configure regular constrained delegation on the delegating service. That means to select the classic options “Allow delegation to specific services”, “Use any authentication protocol” and add the target service (including realm) to the delegation list.

  2. On the target domain, you have to configure resource based constrained delegation on the target service. This could be done using the following PowerShell commands:

    $delegatingAccount = Get-ADUser -Server "DOMAIN.LOCAL" -Identity "delegatingAccountName"
$targetAccount = Get-ADUser -Identity "targetAccountName"
Set-ADUser $targetAccount -PrincipalsAllowedToDelegateToAccount $delegatingAccount

Generating a Keytab File

After defining the SPN, generate a keytab file. A keytab file contains pairs of Kerberos principals and encrypted keys derived from the password of a user account. The Denodo components (Virtual DataPort, Scheduler…) will use this keytab to authenticate themselves with Active Directory. Once they are authenticated, they can authenticate other users.

From the command line of the Windows Domain Controller, execute this (only domain administrators can run it):

Syntax of the ktpass utility
ktpass /out denodo.keytab /princ <SPN with FQDN>@<REALM> /mapUser
<server Active Directory account> /crypto ALL /pass *
/ptype KRB5_NT_PRINCIPAL

For example:

Example of generating a keytab file
ktpass /out denodo_server_production.keytab /princ HTTP/denodo-dv-prod.contoso.com@CONTOSO.COM
/mapuser denodo_server_production /pass * /crypto ALL /ptype KRB5_NT_PRINCIPAL

You will have to enter the password of the user account “denodo_server_production”.

Important

Make sure the password entered is correct and the case of the principal is the right one. ktpass does not validate this. It just generates the keytab based on the principal and the password you enter.

You should see something like:

Successfully mapped HTTP/denodo-dv-prod.contoso.com to denodo_server_production.
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 “ktpass” in its documentation.

Distribute the Keytab and Enable Kerberos Authentication on Denodo Servers

Copy the file “denodo_server_production.keytab” to the computer where you installed the Denodo Platform. If this server is part of a cluster of Denodo servers, copy it to all these computers.

After this, enable Kerberos authentication on the modules required. See:

Kerberos authentication on the Diagnostic & Monitoring Tool is enabled automatically when you enable it on Virtual DataPort.

Deal with the keytab with the same precautions you use when dealing with passwords. That is, do not store them in a file share, when copying to a Denodo installation, change the privileges of the file so it can only be accessed by the user account that launches the Denodo components, etc.

Setting-up Kerberos Authentication in Scheduler

Scheduler provides support to authenticate its clients using the Kerberos authentication protocol.

If you are not going to use the Scheduler, go to the next post-installation action.

Once you set-up the Virtual DataPort server to use Kerberos, it is important to distinguish these two scenarios:

  1. Scheduler and Virtual DataPort Are in the Same Machine (most common scenario).

  2. Scheduler and Virtual DataPort Are in Different Machines

Scheduler and Virtual DataPort Are in the Same Machine

If Scheduler runs on the same host as Virtual DataPort, follow the instructions on the page Kerberos Configuration (Scheduler Administration Guide), and use the same keytab file you are going to use for Virtual DataPort.

We recommend using the same keytab file and the same Service Principal Name (SPN) as for Virtual DataPort. That way, you do not have do anything extra and Scheduler will be easier to manage.

Scheduler and Virtual DataPort Are in Different Machines

Follow these steps if:

  • Scheduler runs on a different machine than Virtual DataPort.

  • Or if you want Scheduler to use a different service principal name (SPN) than Virtual DataPort.

In this scenario, you will have to perform the same post-installation tasks you did to enable Kerberos on Virtual DataPort:

  1. In the Active Directory, create a user of type “User”.

  2. Declare a Service Principal Name (SPN) and associate it with this new user.

  3. Generate a keytab file for this SPN.

  4. Copy the keytab file to the host where the Scheduler runs.

After performing these steps, configure the Scheduler to use Kerberos authentication. The section Kerberos Configuration of the Scheduler Guide explains how to do this.

Important

To configure the Scheduler server and the Scheduler administration tool with different user accounts and therefore, different SPNs, you will have to perform these actions for each one.

Setting-up Kerberos Authentication in the Data Catalog

The Data Catalog provides support to authenticate its clients using the Kerberos authentication protocol.

If you are not going to use the Data Catalog, go to the next post-installation action.

Once you set-up the Virtual DataPort server to use Kerberos, it is important to distinguish these two scenarios:

  1. The Data Catalog and the Virtual DataPort Server Are in Different Machines

  2. The Data Catalog and the Virtual DataPort Server Are in the Same Machine

The Data Catalog and the Virtual DataPort Server Are in Different Machines

In this scenario, you will have to perform the same post-installation tasks you did to enable Kerberos on Virtual DataPort:

  1. In the Active Directory, create a user of type “User”.

  2. Declare a Service Principal Name (SPN) and associate it with this new user.

  3. Generate a keytab file for this SPN.

  4. Copy the keytab file to the host where the Data Catalog runs.

After performing these steps, you have to configure the Data Catalog to use Kerberos authentication. The section Enable Single Sign-On with Kerberos of the Data Catalog Guide explains how to do this.

The Data Catalog and the Virtual DataPort Server Are in the Same Machine

If the Data Catalog runs on the same host than the Virtual DataPort server, it has to use the same keytab file and the same Service Principal Name as in the Virtual DataPort server. That way, you do not have do anything extra and the Server will be easier to manage.

Add feedback