Submit a ticketCall us

Have You Auto Renewed? If not, you're missing out.
The SolarWinds Renewal Program comes with a host of benefits including the most recent product updates, 24/7 technical support, virtual instructor-led training and more. Experience all of this with the convenience of Auto Renewal, and never worry about missing any of these great benefits. Learn More.

Home > Success Center > Database Performance Analyzer (DPA) > Configure DPA to use Kerberos instead of NTLM to authenticate the DPA server

Configure DPA to use Kerberos instead of NTLM to authenticate the DPA server

Updated October 19, 2017

Overview

By default, DPA uses NTLM to authenticate the DPA server to monitored database instances. To configure DPA to use Kerberos instead of NTLM, complete the following tasks. 

Prerequisites

  • The database instance must already be registered for monitoring in DPA.
  • You have not set up DPA for SSO via browser.

Environment

  • DPA 11.0 or later

Steps

Task 1: Set up a Kerberos configuration file on the DPA server

First determine if a Kerberos configuration file already exists on the DPA server. Look for the following are standard file names.

Operating system Path and file name
Solaris /etc/krb5/krb5.conf
Windows C:\Windows\krb5.ini
Linux /etc/krb5.conf

If you do not have a Kerberos configuration file on the DPA server, complete the following steps to create one.

  1. In a text editor, create a new file and copy the following text to use as a template:

    # Set defaults
    [libdefaults]
        default_realm = {REALM NAME}
        default_tkt_enctypes = rc4-hmac,aes256-cts-hmac-sha1-96,aes128-cts-hmac-sha1-96
        default_tgs_enctypes = rc4-hmac,aes256-cts-hmac-sha1-96,aes128-cts-hmac-sha1-96
        forwardable=true
     
    # Define where to find the kerberos server for a particular realm
    [realms]
    {REALM NAME} = {
        kdc = {ActiveDirectoryServerName.domain.com}
        default_domain = {domain.com}
    }
     
    # Map subdomains and domain names to Kerberos realm names.
    # Individual host names may be specified. Domain suffixes may be
    # specified with a leading period and will apply to all host
    # names ending in that suffix.
    [domain_realm]
        {domain.com} = {REALM NAME}
        {.domain.com} = {REALM NAME}
     
    [logging]
    #    kdc = CONSOLE
    #    kdc = SYSLOG:INFO
    #    admin_server = FILE:=/var/kadm5.log
    
  2. Change the values surrounded by braces: {REALM NAME}, {ActiveDirectoryServerName.domain.com}, and {domain.com}.

    To determine the Realm Name, run the following command on your Active Directory server:

    ksetup

    A typical value for REALM.NAME is your company's domain, such as YOURCOMPANY.COM.

    The Realm Name must be specified in uppercase.

  3. Save the file with the path and file name specified in the table above.

Task 2: Create a service account

  1. Ask your Active Directory administrator to create a service account in Active Directory. A service account is similar to a regular domain user account, but the password should be set to Never Expire, and the user is not required to change the password on the next login.

    Later in this article, this user is referred to as {Service Account}.

  2. Configure this user in SQL Server to have sufficient permissions to be the DPA monitoring user.

    Later in this article, the computer name is referred to as {SQL Server name} and the SQL Server port is referred to as {SQL Server port}.

  3. On the domain controller, verify that SQL server has registered itself correctly:
    1. Run this command:

      setspn -L  {SQL Server name}

    2. Verify that the following are included in the SPNs:
      • MSSQLSvc/{SQL Server Name}.{Fully Qualified Domain Name}
      • MSSQLSvc/{SQL Server Name}.{Fully Qualified Domain Name}:{SQL Server port}
    3. If you do not see them, add them manually by running the following commands:

      setspn MSSQLSvc/{SQL Server Name}.{Fully Qualified Domain Name} {SQL Server Name}

      setspn MSSQLSvc/{SQL Server Name}.{Fully Qualified Domain Name}:{SQL Server port} {SQL Server Name}

Task 3: Build the ignite.keytab file

Generate the keytab file that the DPA server will use to authenticate itself to the domain controller. This file contains the private key for the service account and should be protected accordingly.

  1. Choose a {Service account} login name that can be used as the SPN (service principal name). This name cannot conflict with anything already registered in AD as an SPN.

    This name will be referred to as {Service Account Login}.

  2. To generate the file, run the following command from your Active Directory server on a single line:

    ktpass /out .\ignite.keytab /mapuser {Service Account}@{Fully Qualified Domain Name} /princ {Service Account Login}@{REALM NAME} /pass {Service Account Password} /ptype KRB5_NT_PRINCIPAL /crypto ALL

    Notes:

    /princ The value for the /princ parameter is case-sensitive.
    {encryption type}

    Example values for {encryption type} are:

    • ALL
    • RC4-HMAC-NT
    • AES128-SHA1

    If you use AES128-SHA1 encryption, be sure that "This account supports AES 128 bit encryption" is selected for the user account.

    By default, the files bundled in the Java JRE enforce a restriction that limits the maximum key length to 128 bits. To use AES256 encryption, you must install the JCE Unlimited Strength Jurisdiction Policy Files.

  3. Move the keytab file to the DPA server.
    • Do not put the file in a directory inside of the DPA installation directory structure, so you will not have to change paths if you move the DPA installation directory.
    • If your server already has a keytab file, you may want to merge the ignite.keytab file with the existing one.
    • For UNIX, keytab files are typically stored in /etc/krb5.keytab.

Task 4: Create the login.conf file

  1. In a text editor, create a file with the following content:

    com.sun.security.jgss.krb5.initiate {
       com.sun.security.auth.module.Krb5LoginModule required
       useTicketCache=false
       doNotPrompt=true
       useKeyTab=true
       keyTab="{Path to ignite.keytab}"
       principal="{Service Account Login}@{REALM NAME}"
       storeKey=true
       debug=false;
    };
    
  2. Save the file with the following name and location:

    <DPA_install_directory>/iwc/tomcat/ignite_config/login.conf

Task 5: Edit the system.properties file

Add the following lines to your system.properties file:

javax.security.auth.useSubjectCredsOnly=false
java.security.auth.login.config={Path to login.conf}
com.confio.ws.ldap.sso.krbConfLocation={Path to krb5.conf}

Task 6: Restart DPA

Restart DPA to apply the changes in the configuration files.

  • On Windows, stop and restart the Ignite PI Server service.
  • On Linux, run the following commands from the DPA directory:
    • shutdown.sh
    • startup.sh

Task 7: Update connection information

In DPA, update the connection information for each monitored database instance that you want to authenticate using Kerberos.

  1. Click Options > Update Connection Info.
  2. Select a database instance and click Next.
  3. In Connection Properties, enter the following:

    integratedSecurity=true;useKerberos=true

    You may leave the Monitoring User and Password values as they are, or set them to anything non-empty. These values will not be used for authentication.

  4. Click Next, and then click Update Connection.

Common issues

The computer name is not properly resolved to the IP address

Use nslookup to ensure that both the computer name and its IP address are resolved correctly.

While building the ignite.keytab file, an error is returned

Verify that no error was returned during keytab generation, and that the SPN was set correctly. 

The following is an example of ktpass output with errors:

C:\Users\Administrator>ktpass /out .\DPA_user.keytab /mapuser DPA_user@ignite.local /princ MSSQLSvc/JJ-W-NINER.ignite.local@IGNITE.LOCAL /pass Confio123 /ptype KRB5 _NT_PRINCIPAL /crypto ALL
DsCrackNames returned 0x5 in the name entry for DPA_user@ignite.local.
ktpass:failed getting target domain for specified user.

The following is an example of correct ktpass output:

C:\Users\Administrator>ktpass /out .\DPA_user.keytab /mapuser DPA_user@ignite.local /princ dpa/kerberos@IGNITE.LOCAL /pass Confio123 /ptype KRB5_NT_PRINCIPAL /crypto ALL
Targeting domain controller: {ActiveDirectoryServerName.domain.com}
Successfully mapped dpa/kerberos to DPA_user.
Password successfully set!
Key created.
Key created.
Key created.
Key created.
Key created.
Output keytab to .\DPA_user.keytab:
Keytab version: 0x502
keysize 52 dpa/kerberos@IGNITE.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 20 etype 0x1 (DES-CBC-CRC) keylength 8 (0xc808a145ea01731c)
keysize 52 dpa/kerberos@IGNITE.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 20 etype 0x3 (DES-CBC-MD5) keylength 8 (0xc808a145ea01731c)
keysize 60 dpa/kerberos@IGNITE.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 20 etype 0x17 (RC4-HMAC) keylength 16 (0xdeeb603a6c4d7bf8a30e485abfc6155c)
keysize 76 dpa/kerberos@IGNITE.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 20 etype 0x12 (AES256-SHA1) keylength 32 (0xdb8cf130ca48925b4b1fb26f982429d720f1d6665cf431a6ae1c4d8fe4029440)
keysize 60 dpa/kerberos@IGNITE.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 20 etype 0x11 (AES128-SHA1) keylength 16 (0x39fbfbbb4a11a126eea073da8d3eb627)

 

 

Last modified

Tags

Classifications

Public