Product Selector

Fusion 5.12
    Fusion 5.12

    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 support requires Fusion 5.9.5.

    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.
    Kerberos support requires Fusion 5.9.5.

    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:

    NETBIOS Domain

    FUSIONIS

    Fully qualified domain name

    fusionis.life

    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)

    kerberos500@fusionis.life

    NETBIOS Domain\samAccountName

    FUSIONIS\kerberos500

    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 AES256-SHA1 -pType KRB5_NT_PRINCIPAL -kvno 0

    +

    The following weak encryption types are not supported by Fusion:

    • DES-CBC-CRC

    • DES_CBC_MD5

    • Microsoft Windows 2000 RC4-HMAC

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

    Type

    Kerberos

    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:

    DEFAULT
RULE:[1:$1@$0](.*@.*)s/@.*//

    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.

    Troubleshooting

    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.