Legacy Product

Fusion 5.4

Configure Fusion for Kerberos in Windows

To configure the Fusion UI service to use Kerberos for user authentication, you must create a Kerberos security realm.

Kerberos is a system that provides authenticated access for users and services on a network. Instead of sending passwords in plaintext over the network, encrypted passwords are used to generate time-sensitive tickets that are used for authentication. SPNEGO provides a mechanism for extending Kerberos to Web applications through the standard HTTP protocol.

Kerberos uses symmetric-key cryptography and a trusted third party called a Key Distribution Center (KDC) to authenticate users to a suite of network services. (By users we mean both end users and client programs). The computers managed by that KDC and any secondary KDCs constitute a realm. When a user authenticates to the KDC, the KDC sends a set of credentials (a ticket) specific to that session back to the user’s machine. Kerberos-aware services use the ticket on the user’s machine for authentication instead of requiring sign-on with a password. Because tickets are used rather than passwords, this provides the convenience of Single Sign-On (SSO) in addition to security.

A Kerberized process is one that has been configured so it can get tickets from a KDC and negotiate with Kerberos-aware services. When a user sends an HTTP request, Fusion tries to authenticate using the Kerberos/SPNEGO protocol. If the request was sent from a browser, Fusion does not display the initial sign-on panel; instead on login, the user sees the main Fusion collections panel.

This article focuses on configuring Fusion for Kerberos in Windows. To learn how to configure Fusion for Unix, see Configure Fusion for Kerberos in Unix.

1. Set up and Configure the Active Directory Domain Service

1.1. Install the Active Directory Domain Service

To begin, follow Microsoft’s instructions on how to install Active Directory Domain Services.

This topic uses the following domain throughout this example:



Fully qualified domain name


1.2. Create a New User

Launch the Server Manager. Navigate to Tools > Active Directory Users and Computers. Within the fusionis.life server, locate the "Users" folder, right-click on the folder and select New > User.

When creating a user for this purpose, ensure the First name and Display name fields both hold the exact same value.

These instructions use the following user name throughout this example:

Distinguished name (DN)

CN = kerberos500

CN = Users

DC = fusionis

DC = life

User Principal Name (UPN)


NETBIOS Domain\samAccountName


Establish the desired delegation rules for the new user in the "Delegation" tab.

Kerberos500 Delegation

1.3. Create a Keytab for the New User

Enter the following command into the command prompt to create a keytab for the user you just created:

ktpass -out c:\Users\Administrator\kerberos500.keytab -princ HTTP/fusionis.life@FUSIONIS.LIFE -mapUser FUSIONIS\kerberos500 -mapOp set -pass YOUR_PASSWORD -crypto ALL -pType KRB5_NT_PRINCIPAL -kvno 0

The output will be similar to:

C:\Users\Administrator>ktpass -out c:\Users\Administrator\kerberos500.keytab -princ HTTP/fusionis.life@FUSIONIS.LIFE -mapUser kerberos500 -mapOp set -pass FroFro123# -crypto ALL -pType KRB5_NT_PRINCIPAL
Targeting domain controller: WIN-OVV6VHBGIB8.fusionis.life
Using legacy password setting method
Successfully mapped HTTP/fusionis.life to kerberos500.
Key created.
Key created.
Key created.
Key created.
Key created.
Output keytab to c:\Users\Administrator\kerberos500.keytab:
Keytab version: 0x502
keysize 71 HTTP/fusionis.life@FUSIONIS.LIFE ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x1 (DES-CBC-CRC) keylength 8 (0xcd07200bea625d20)
keysize 71 HTTP/fusionis.life@FUSIONIS.LIFE ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x3 (DES-CBC-MD5) keylength 8 (0xcd07200bea625d20)
keysize 79 HTTP/fusionis.life@FUSIONIS.LIFE ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x17 (RC4-HMAC) keylength 16 (0xe39a141de38abd8750bf9c0bf49fd1c5)
keysize 95 HTTP/fusionis.life@FUSIONIS.LIFE ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x12 (AES256-SHA1) keylength 32 (0xdd6018ab718a4c312038189a20498f70c07d09a19d77ceea31cdd4cd1b08800a)
keysize 79 HTTP/fusionis.life@FUSIONIS.LIFE ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x11 (AES128-SHA1) keylength 16 (0x9b610485eae2d97dcf0ecaf4ab38a32b)

This process will create the kerberos500.keytab file required to set up the Kerberos realm in Fusion. The command will also set the service principal to HTTP/fusionis.life@FUSIONIS.LIFE.

If you see the following, the user was not created correctly:

DsCrackNames returned 0x2 in the name entry for kerberos500.
Ktpass:failed getting target domain for specified user.

Delete the user, and repeat the steps above.

2. Set up Kerberos on Fusion Server

2.1. Install Fusion and set up the Kerberos Realm

If you have not done so already, install Fusion now.

Copy the keytab file to the server.

The keytab file must be installed on each Fusion node.

Log into Fusion as a native admin and navigate to DevOps > Access Control > Realms > New Realm. Use the following parameters:



Keytab file

The path to the keytab file you saved on the server

Service principal

The service principal you generated in the previous step

Kerberos name mapping

The field that specifies the mapping from a Kerberos Principal name to a short name

You can specify the default rule, which should work for most situations:


You can also add custom rules. See Mapping Kerberos Principals to Short Names for more information on creating custom rules.

Save your new realm before continuing. You should now be able test with Negotiate authentication.

3. Verify Kerberos is Working

You will test to verify that Kerberos is working in the following sections. You must log into Windows as a user in the protected realm, meaning that the service principal name you are using has access to generate a ticket for your user.

Verify with cURL

Windows users can log in as a user within the domain, launch the command prompt, and run the cURL command below:

curl --negotiate -u : http://fusionis.life:8764/api/apollo/collections

Linux users may also need to run a kinit to login as a user prior to running.

Navigate your web browser to http://fusionis.life:8764. If you are automatically logged in, Kerberos is working.

Verify with Google Chrome

To verify Kerberos is working with Google Chrome, run Chrome with the following command parameters:

"c:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --auth-server-whitelist="*fusionis.life" --auth-negotiate-delegate-whitelist="*fusionis.life" --auth-schemes="basic,digest,ntlm,negotiate"

Navigate your web browser to http://fusionis.life:8764. If you are automatically logged in, Kerberos is working.

Verify with Firefox

To verify Kerberos is working with Firefox, navigate to about:config in your browser’s URL bar. If a message appears stating "This might void your warranty!", click "I accept the risk!".

Search for the string network.negotiate-auth.trusted-uris, double-click the field, and enter fusionis.life into the field that appears. Click "Ok".

Navigate your web browser to http://fusionis.life:8764. If you are automatically logged in, Kerberos is working.


Defective token detected

If you encounter this issue, check the var/log/proxy/proxy.log after attempting to make a request.

See Stack Overflow for addtional steps to resolve this issue.

Kerberos Name mapping rules

You may see the following error if you did not specify a mapping rule and the Proxy could not figure out how to map the Kerberos Principal name to a short name:

2021-07-30T15:15:03,584 - ERROR [qtp353842779-52:clojure.tools.logging$eval11$fn__16@0] - {} - Uncaught application error!
org.apache.hadoop.security.authentication.util.KerberosName$NoMatchingRule: No rules applied to YOURUSERNAME@YOURDOMAIN.SUBDOMAIN.EXAMPLE.COM

Adjust your Kerberos name mapping rules to resolve this issue.