Introduction
For certain database platforms, the Strategy Intelligence Server can be configured to connect using Kerberos authentication as opposed to traditional user / password authentication.  This functionality is provided by the relevant ODBC or JDBC driver for the database connection, but some configuration is required on the Strategy Intelligence Server to make use of it.
Depending on the database type and driver in use, it may also be possible to configure warehouse pass-through authentication using Kerberos to provide a Single Sign-On functionality that connects to the database with the credentials of the end user who performs the action that requires the database connection.  This article will cover fixed-credential authentication, where a single set of Kerberos credentials (typically those belonging to the Strategy Intelligence Server service account) is used for all connections to the database.
Prerequisites:

1. The Intelligence Server machine must be configured for general Kerberos functionality.  See the Strategy Intelligence Server host machine configuration section of KB19110: How to configure MicroStrategy Intelligence Server for Integrated Authentication (Kerberos) on Unix / Linux for more information if necessary.
2. A Kerberos user principal must exist for the Intelligence Server to use when requesting tickets to the database service(s).  Typically this will be an Active Directory user for use by the Intelligence Server as a service account, or an MIT Kerberos user principal.  In this article, an account named mstr-example will be used as an example.
3. The user principal must have the required access on the target database(s).  All connections to the database will use this user principal.
4. The Service Principal Name (SPN) for the database service(s) must be known.

 
Kerberos configuration

1. Check Point 1 - kinit as Kerberos user
2. Check Point 2 - Get a ticket to the database service

DSN configuration

1. Check Point 3 - Test the connection using mstrtodbcx

Kerberos configuration:

CHECK POINT 1 - kinit as Kerberos user:

Verify that it is possible to kinit on the Intelligence Server machine with the desired user principal.  After running the kinit command and entering the password, run the klist command to verify that a ticket was created for the krbtgt service (this is actually the ticket that entitles the user to get other tickets in the realm after authenticating).
 

[mstr@exampleserver Strategy]# kinit mstr-example
Password for mstr-example@EXAMPLE.COM:
[mstr@exampleserver Strategy]#
[mstr@exampleserver Strategy]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: mstr-example@EXAMPLE.COM

Valid starting     Expires            Service principal
08/23/17 10:35:44  08/23/17 20:35:32  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until 08/30/17 10:35:44
[mstr@exampleserver Strategy]#

If an error occurred when running either the kinit or klist commands, this means that the krb5.conf configuration or some other system-level configuration (network, etc.) is incorrect.  Stop here and consult the system administrator or Kerberos administrator to resolve this issue before continuing.
 

CHECK POINT 2 - Get a ticket to the database service:

Verify that it is possible to manually obtain a ticket for the database SPN.  Assuming that the mstr-example user is still authenticated on the Intelligence Server machine, use the kvno <SPN> command to obtain a ticket.  After running the kvno command, run the klist command to verify that a ticket was created.  This ticket should match the SPN for the database service.  Make a note of the ticket cache location (in this case /tmp/krb5cc_0) as this will be needed for a later configuration step.
 

[mstr@exampleserver Strategy]#
[mstr@exampleserver Strategy]# kvno hive/hiveserver.example.com@EXAMPLE.COM
hive/hiveserver.example.com@EXAMPLE.COM: kvno = 2
[mstr@exampleserver Strategy]#
[mstr@exampleserver Strategy]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: mstr-example@EXAMPLE.COM

Valid starting     Expires            Service principal
08/23/17 10:35:44  08/23/17 20:35:32  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until 08/30/17 10:35:44
08/23/17 10:51:25  08/23/17 20:35:32  hive​/hiveserver.example.com@EXAMPLE.COM
        renew until 07/20/17 11:09:42
[mstr@exampleserver Strategy]#

If an error occurred when running the kvno command, this means that the Intelligence Server's user principal was not able to obtain a ticket for the database service.  This could be because the database service SPN was incorrectly specified, or because the Kerberos configuration on the Intelligence Server machine is incorrect or incomplete.  Stop here and consult the system administrator or Kerberos administrator to resolve this issue before continuing.
 

DSN Configuration:

If a DSN has not yet been created for the desired database connection, do so now following the appropriate steps according to the database type.  Consult the driver vendor's documentation to determine the necessary parameters to configure for using Kerberos (typically there will be a parameter to indicate the use of Kerberos, and the SPN for the database service will need to be specified in some way).  An example DSN created in Strategy 10.4 to connect to Hive is provided below, with the relevant parameters bolded:
 

[hiveexample]
Driver=/opt/MicroStrategy/lib/libhiveodbc_sb64.so
Description=Strategy Hive ODBC Driver
AuthMech=1
DefaultStringColumnLength=2147483647
FastSQLPrepare=0
GetTablesWithQuery=1
HiveServerType=2
Host=hiveserver
Port=10000
Schema=default
ThriftTransport=1
UseNativeQuery=0
KrbHostFQDN=hiveserver.example.com
KrbServiceName=hive
KrbRealm=EXAMPLE.COM

 

CHECK POINT 3 - Test the connection using mstrtodbcx:

After the DSN has been configured, test the connection using the mstrtodbcx tool to ensure that it can connect successfully.  This step requires that the ticket for the database service has been successfully obtained as in Check Point 2.  Make sure that the same shell (terminal) is used to launch DB Query tool after generating the ticket. Since the Kerberos credentials will be used for authentication, a username and password will not need to be specified for the login attempt.  If desired, one or more test queries may be run after connecting.
 

[mstr@exampleserver Strategy]# bin/mstrtodbcx
Strategy ODBC Test Tool
  Version 10.4.0026.0049

Type .help (including the period) for help.

- > .cn -d hiveexample
# Data Source Name: hiveexample
# Login:
# Connection type : Strategy DB Classes

hiveexample > .quit
[mstr@exampleserver Strategy]#

If an error occurred when connecting to the database, there may be an issue with the DSN configuration or the ticket for the database service may not have been successfully obtained.  Double-check the configuration and the service ticket, and follow up with the driver vendor for support as needed.
If the connection succeeded, Kerberos authentication on the relevant DSN is now operational.  As long as a valid ticket-granting ticket (TGT) is present in the Kerberos credentials cache, the ODBC driver will automatically obtain a ticket for the database service (if needed) when the connection is created.  NOTE: Strategy does not currently have the ability to refresh the Kerberos authentication, so if the TGT expires then the authentication will need to be performed again (either manually via kinit command or through some other mechanism set up by the system administrator).
If it is desired to save the Kerberos credentials cache to a specific location other than the default in /tmp, an environment variable called KRB5CCNAME may be set with the desired path and filename:
 

export KRB5CCNAME=/var/opt/MicroStrategy/krb5/krb5cc_0

If doing so, it is important to ensure that the variable is set at the time of Intelligence Server startup in order for it to take effect.
The Strategy internal reference number for this Knowledge Base article is KB438573. KB438573