This document details the process for configuring the Domain Controller (KDC) in order to be able to enable SSO (Kerberos) in the Denodo servers.
Note: This document is the second 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.
KDC Configuration (MS Active Directory - domaincontroller.denodo.loc)
We will start configuring the Domain Controller (KDC). For this server, we will follow the instructions explained in the Setting-up Kerberos Authentication section of the Denodo documentation.
Note: check that documentation for a detailed explanation. This guide only shows the steps done in this sample environment.
Create a User for Denodo server in the MS Active Directory
This step is the first one, Denodo will need a user to authenticate itself!
- Open Active Directory Users and Computers
- Create a new element of type User:
- Fill the details of the Denodo user (in our example denodovm_krb)
- Set the password (save it, you will need it later!). Also, unselect the “User must change password at next logon” and select “Password never expires”
- Accept the rest of the dialogs to create the denodovm_krb user.
- Once it’s created, it is needed to set user account options. Double click on the user:
- Go to the Account tab:
- Ensure the “Account is sensitive and cannot be delegated” option is disabled.
- We also recommend to disable “Kerberos DES encryption types” and enable “AES 128/256bit encryption types” for security reasons.
- Click OK to save the changes.
Declare a Service Principal Name (SPN) for Denodo
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. In other words, we have to link the denodovm_krb user with the Denodo service running in denodovm.denodo.loc (this is the Fully Qualified Domain Name, or FQDN, of the denodo server).
- Open a Command prompt and execute the following command to define the SPN (the prefix HTTP is needed!, check the documentation:
setspn -U -S HTTP/denodovm.denodo.loc DENODO.LOC\denodovm_krb
Why using HTTP/denodovm.denodo.loc ?
When web browsers request a Kerberos ticket (for example when using the Data Catalog), 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.
- Verify that the SPN was defined correctly and the user only has one SPN:
setspn -U -L DENODO.LOC\denodovm_krb
- Check the user account again in the Active Directory. Double click on it (the user logon name has changed!):
- You can also double check the Attributes of the User (sAMAccountName, servicePrincipalName and userPrincipalName)
Select the type of Delegation
Denodo supports two types of Delegation: “Open delegation” and “Constrained delegation”
- Open delegation: 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. For configuring it you have to select this option in the Delegation tab:
- Constrained delegation: 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. For example, you can configure here that credentials can be delegated only to a specific SQL Server instance. For configuring it you have to do the following:
- Select this option in the Delegation tab:
- Click on Add… and search for our user denodovm_krb:
- Select the user denodovm_krb (the other object is the denodo server itself, as that machine was added to the domain previously) and select it:
- Follow the same steps to add more services (SQL servers, etc.)
Generate a Keytab File
A keytab is a file which contains pairs of Kerberos principals and encrypted keys derived from the password of a user account. When the Virtual DataPort server starts it will use the keytab to authenticate itself with the Active Directory. Once it authenticates itself, it can authenticate other users (because the account was configured for the Delegation of credentials).
- For generating the keytab execute this from a command prompt (you will have to enter the password of the user denodovm_krb):
ktpass /out denodovm.keytab /princ HTTP/denodovm.denodo.loc@DENODO.LOC /mapUser denodovm_krb /pass * /crypto ALL /ptype KRB5_NT_PRINCIPAL
- The keytab is generated in C:/ by default
- You have to copy the file “denodovm.keytab” to the host where the Denodo server runs, in our case denodovm.denodo.loc. See next document for getting more information about this process.
Note: Next step in this process will be configuring the Denodo Server to use Kerberos. You can check the second part of this tutorial in the following link: Kerberizing Denodo for SSO - Step by step guide - Server Configuration (III)