Microsoft SQL Server (Kerberos)

Learn how to add Microsoft SQL Server (Kerberos) as a resource in StrongDM.

Overview

This guide describes how to add a Microsoft SQL Server (Kerberos) database as a datasource in StrongDM. This resource type only supports Windows authentication with Active Directory (AD) via Kerberos. For other options, see the Microsoft SQL Server (Azure AD) and Microsoft SQL Server resource types.

When the resource is added, StrongDM proxies client connections through a node (gateway, relay, or proxy cluster). This enables centralized access control, credential management, and audit logging.

Use this guide to complete all necessary preparations to add this resource to your StrongDM environment; input the correct properties in the Admin UI, CLI, SDKs, or Terraform provider; and test for a successful connection.

For general information about how to add a database as a resource in StrongDM, see our main guide, Add a Datasource.

Supported Versions and Clients

StrongDM supports Microsoft SQL Server instances using Azure Active Directory authentication. Only SQL Servers that are configured to accept Azure AD clients are compatible.

StrongDM works with standard SQL Server clients and drivers that support Azure AD authentication, including:

• Tools such as sqlcmd, Azure Data Studio, and SSMS

• Application libraries/drivers (for example, JDBC/ODBC, .NET SqlClient, or Node.js mssql) with Azure AD support

• GUI clients that allow specifying Azure AD credentials or service principals

Prerequisites

To add your resource in StrongDM, you need to meet several technical and configuration prerequisites. Please ensure that the following requirements are met.

In StrongDM, you must have the following:

• Administrator permission level

• At least one operational StrongDM node (gateway, relay, or proxy cluster) that can reach the SQL Server endpoint (hostname and port, default 1433)

• If using secrets management tools for storing your database credentials, a Secret Store configured in StrongDM

To verify that the resource is accessible by the node, log in to the gateway or relay and use Netcat: nc -zv <HOSTNAME> <PORT> (in this example, nc -zv testdb-01.fancy.org 3306). If your gateway server can connect to this hostname, proceed.

Netcat is a tool for checking various hostnames and ports by either sending data (a ping) or checking for listeners on the ports. The command in the aforementioned example use "-z" to check for listeners without sending data and "-v" to show verbose output. If you don't have Netcat, you can install the Netcat package with whatever package manager you are using, such as "apt-get install netcat".

On the SQL Server/Azure side, you must have the following:

• Computer running SQL Server that is joined to the Active Directory domain

• SPN (Service Principal Name) for the SQL Server service must be registered in AD so clients can authenticate via Kerberos.

• Generated keytab file (Base64-encoded) for the AD user, which will be used for Kerberos authentication

• Generated krb5.conf file (or equivalent Kerberos configuration) set up properly for the realm/domain

• SQL Server with TCP connections enabled

• AD user configured in the keytab must be granted login access to the SQL Server.

Kerberos Setup

Generate a krb5.conf file

The krb5.conf file is a text file containing Kerberos configuration information, including the locations of Key Distribution Centers (KDCs) for the Kerberos realms of interest, defaults for the current realm and for Kerberos applications, and mappings of hostnames onto Kerberos realms.

For detailed information, refer to the krb5.conf man page or MIT Kerberos Documentation. Only a small portion of the possible configuration parameters are relevant to StrongDM’s use of Kerberos and need to be defined.

An example krb5.conf file for use with a StrongDM Microsoft SQL Server (Kerberos) resource is as follows:

[libdefaults]
default_realm = AD.EXAMPLE.COM
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
forwardable = yes
default_tgs_enctypes = aes256-cts-hmac-sha1-96
default_tkt_enctypes = aes256-cts-hmac-sha1-96
permitted_enctypes = aes256-cts-hmac-sha1-96

[realms]
AD.EXAMPLE.COM = {
  kdc = ad.example.com:88
}

[libdefaults]

• default_realm: This should match the name of the realm under the [realms] section. For Active Directory (AD), it should generally be defined as the AD domain in uppercase.

• enctypes: Weaker encryption algorithms should not be needed so this should not need to be changed.

• All other parameters should be specified as in the example.

[realms]

• This specifies the name of the realm and the KDC (or KDCs) to use for that realm. In AD terms, a Kerberos realm is the same as an AD domain.

• kdc: the hostname or IP address and port of the KDC (the AD server). The port can be omitted when the default (88) is used. Multiple kdc lines may be specified if the server is accessible from multiple addresses for failover purposes.

Each StrongDM datasource is authenticated with a single realm (AD domain). Optionally, if your situation requires it, multiple realms may be specified in the krb5.conf to allow the same configuration file to be used for configuring other datasources in different realms. In that case the default_realm may be omitted and the krb5.conf must also specify a mapping from each server principal name domain (or subdomain) to the desired realm instructing the Kerberos library which realm to use for a given Service Principal Name (SPN). For a single configuration supporting resources with both an SQL Server principal name like MSSQLSvc/prod-mssql.ad.example.com:1433 and MSSQLSvc/dev-mssql.dev.ad.example.com:1433 the mapping would look like the following example:

[domain_realm]
.dev.ad.example.com:1433 = DEV.AD.EXAMPLE.COM
.dev.ad.example.com = DEV.AD.EXAMPLE.COM
.ad.example.com:1433 = AD.EXAMPLE.COM
.ad.example.com = AD.EXAMPLE.COM

A mapping with the domain name both including the port number from the SPN and excluding the port number from the SPN must be specified.

Generate a keytab file

A Kerberos keytab (short for "key table") stores long-term keys for one or more principals (users or service accounts, for example). Keytabs are normally represented by files in a standard binary format, although in rare cases they can be represented in other ways. Keytabs are used most often to allow server applications to accept authentications from clients, but can also be used to obtain initial credentials for client applications.

Each entry in the keytab consists of:

• Principal name, such as [email protected]

• Encryption key, derived from a password supplied for the principal

• Encryption type of the key, typically aes256-cts-hmac-sha1-96

• Timestamp the entry was added to the keytab

• Key version number ("kvno"), indicating the version of the key (where a higher version indicates a more recent key)

For use with a Microsoft SQL Server (Kerberos) datasource through StrongDM, the keytab should be created with an entry that has a principal name matching the AD user account password of the user that is used to log in. The username should include the AD domain/realm.

The keytab can contain any number of principals and keys to allow the same keytab to be used with multiple datasources using different principals or realms.

While some Kerberos libraries and tools do not validate the key version number (or always use the highest or zero), the Kerberos library used by StrongDM currently does require the key version number in the keytab to match the key version number stored in AD (under the msDS-KeyVersionNumber attribute of the user). The key version number in AD increments every time the password of the account changes (including any automatic rotation), requiring the key version number in the keytab to also be updated to match. If the key version number does not match, authentication between StrongDM and SQL Server fails. The correct key version number to use in the keytab can be determined from the logged error, or queried from AD in advance.

The keytab can be created locally on any operating system (macOS, Linux, or Windows), using commands described in the relevant sections. Testing the keytab locally (before configuring the StrongDM resource) is optional, but must be done on a system with access to the KDC.

Keytabs on macOS

macOS comes preinstalled with the Heimdal Kerberos user space tools, including ktutil and kinit. Refer to the inline help or man pages of these tools for more details, including commands not described here.

Add an entry to the keytab

To add an entry to a keytab (creating the keytab if it does not exist), use kutil as follows:

ktutil -k <KEYTAB_FILE> add -p <PRINCIPAL> -e <ENCRYPTION_TYPE> -V <KVNO>

• KEYTAB_FILE: Name of the output keytab file to create or modify

• PRINCIPAL: Principal name to add (the user account like USER@DOMAIN)

• ENCRYPTION_TYPE: Type of encryption to use for the key (where aes256-cts-hmac-sha1-96 is most likely to be used)

• KVNO: Key version number (matching the key version number of the corresponding user account in AD)

The utility prompts for the password of the principal. If the keytab file already exists it adds a new entry to the existing keytab. For example:

ktutil -k krb5.keytab add -p [email protected] -e aes256-cts-hmac-sha1-96 -V 5

List entries in the keytab

To list all entries in a specified keytab, use the following:

ktutil -k <KEYTAB_FILE> list

For example:

$ ktutil -k krb5.keytab list  
krb5.keytab:
Vno  Type                     Principal                                Aliases
  5  aes256-cts-hmac-sha1-96  [email protected] 

Verify the keytab

To verify that the keytab can be used to acquire a service ticket for an SQL Server instance, kinit can be used. This must be run on a system with network connectivity to AD and uses the krb5.conf created previously.

KRB5_CONFIG=<KRB5_FILE> kinit -c <CACHE_FILE> -V -t <KEYTAB_FILE> -S <SERVICE_PRINCIPAL_NAME> <PRINCIPAL_NAME>

• KRB5_FILE: Path to the krb5.conf

• CACHE_FILE: Path at which to store the acquired ticket (can be anything)

• KEYTAB_FILE: Path to the keytab

• SERVICE_PRINCIPAL_NAME: SPN of the SQL Server instance to acquire a ticket for, typically MSSQLSvc/HOSTNAME:1433 where HOSTNAME is the hostname of the SQL Server and 1433 is the port

• PRINCIPAL_NAME: Principal name added to the keytab earlier to use to acquire the ticket (that is, USER@DOMAIN)

For example:

$ KRB5_CONFIG=krb5.conf kinit -c krb5.cache -V -t krb5.keytab -S 'MSSQLSvc/prod-mssql.ad.example.com:1433' [email protected]

klist -c krb5.cache
Credentials cache: FILE:krb5.cache
        Principal: [email protected]

  Issued                Expires               Principal
May 10 16:43:19 2023  May 10 16:48:18 2023  MSSQLSvc/prod-mssql.ad.example.com:[email protected]

Note that success with kinit does not necessarily guarantee that the keytab works with a StrongDM Microsoft SQL Server resource, as it is built on a different Kerberos library than that used by the StrongDM relay. In particular, kinit does not validate the key version number, so it does not detect a keytab with an incorrect version number.

Base64 encode the keytab

Because the keytab is in a binary format, inputting it into the StrongDM Admin UI requires it to be Base64-encoded. This can be done using the following command:

base64 KEYTAB_FILE

Look up the key version number

If the system has LDAP connectivity to the AD server, ldapsearch can be used to query the current key version number of a user for use in creating the keytab.

ldapsearch -h <AD_SERVER> -D <USER_ACCOUNT> -W -b <BASE_DN> <FILTER> <ATTR>

This prompts for the password of the user for authentication.

For example:

$ ldapsearch -h ad.example.com -D [email protected] -W -b "cn=users,dc=ad,dc=example,dc=com" "(cn=example-user)" msDS-KeyVersionNumber
# extended LDIF
#
# LDAPv3
# base <cn=users,dc=ad,dc=example,dc=com> with scope subtree
# filter: (cn=example-user)
# requesting: msDS-KeyVersionNumber 
#

# example-user, Users, ad.example.com
dn: CN=example-user,CN=Users,DC=ad,DC=example,DC=com
msDS-KeyVersionNumber: 5

Keytabs on Linux

Check to see whether your Linux system has Kerberos utilities provided by an installation of heimdal-clients, krb5-user or krb5-workstation packages.

If you have heimdal-clients, the utilities ktutil and kinit will work as described in the macOS section.

If you have krb5-user (for Debian or Ubuntu) or krb5-workstation (for RHEL or CentOS), the same utilities are present, but the krb5-user and krb5-workstation command invocations differ from heimdal-clients. The krb5-user and krb5-workstation invocations are described below.

Add an entry to the keytab

To add an entry to a new or existing keytab, invoke the ktutil command and use the add_entry and write_kt commands, being sure to use the key version number that you located for this user for the value of <KVNO>:

$ ktutil
ktutil:  add_entry -password -p <PRINCIPAL_NAME> -e <ENCRYPTION_TYPE> -k <KVNO>
ktutil:  write_kt <KEYTAB_FILE>
ktutil:  quit

For example:

$ ktutil
ktutil:  add_entry -password -p [email protected] -e aes256-cts-hmac-sha1-96 -k 5
Password for [email protected]: 
ktutil:  write_kt krb5.keytab 
ktutil:  quit

To modify an existing keytab, run read_kt krb5.keytab as the first command after starting ktutil to load the existing keytab into memory first.

The addent command (typically an alias for the add_entry command) can also be used when adding an entry. Different distributions and versions may have slightly varied syntax requirements.

List entries in the keytab

To list all entries in the keytab, invoke ktutil and use the read_kt and list commands:

$ ktutil
ktutil:  read_kt <KEYTAB_FILE>
ktutil:  list
ktutil: quit

For example:

$ ktutil
ktutil:  read_kt krb5.keytab
ktutil:  list
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    5  [email protected]
ktutil:  quit

Verify the keytab

To verify the keytab by acquiring a service ticket, kinit can be used:

KRB5_CONFIG=<KRB5_FILE> kinit -c <CACHE_FILE> -V -k -t <KEYTAB_FILE> -S <SERVICE_PRINCIPAL_NAME> <PRINCIPAL_NAME>

For example:

KRB5_CONFIG=krb5.conf kinit -c krb5.cache -V -k -t krb5.keytab -S 'MSSQLSvc/prod-mssql.ad.example.com:1433' example-user

Base64 encode the keytab

The keytab is in a binary format, so inputting it into the StrongDM Admin UI requires it to be Base64-encoded. This can be done using the following command:

base64 KEYTAB_FILE

Look up the key version number

If the system has LDAP connectivity to the AD server, and has the package ldapsearch installed, it can be used to query the current key version number of a user for use in creating the keytab.

ldapsearch -h <AD_SERVER> -D <USER_ACCOUNT> -W -b <BASE_DN> <FILTER> <ATTR>

This prompts for the password of the user for authentication.

For example:

$ ldapsearch -h ad.example.com -D [email protected] -W -b "cn=users,dc=ad,dc=example,dc=com" "(cn=example-user)" msDS-KeyVersionNumber
# extended LDIF
#
# LDAPv3
# base <cn=users,dc=ad,dc=example,dc=com> with scope subtree
# filter: (cn=example-user)
# requesting: msDS-KeyVersionNumber 
#

# example-user, Users, ad.example.com
dn: CN=example-user,CN=Users,DC=ad,DC=example,DC=com
msDS-KeyVersionNumber: 5

Keytabs on Windows

Add an entry to the keytab

On Windows, the ktpass command-line utility can be used to create a keytab:

ktpass -princ <WINDOWS_USERNAME>@<REALM_NAME> -pass <PASSWORD> -crypto <ENCRYPTION_TYPE> -ptype <PRINCIPAL_TYPE> -kvno <KEY_VERSION_NUMBER> -out <KEYTAB_FILE_PATH>

For example:

ktpass -princ [email protected] -pass * -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -kvno 6 -out krb5.keytab

See ktpass for more details on its usage.

List entries in the keytab

ktpass can also be used to list entries in an existing keytab. For example:

C:\Users\example-user>ktpass -in krb5.keytab
Existing keytab:

Keytab version: 0x502
keysize 89 [email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 6 etype 0x12 (AES256-SHA1) keylength 32 (0xfa8d4d926f1c32084d32cee7365e56edfb5ba53a0b209fb676f864e46130012b)

Base64 encode the keytab

The certutil command-line utility can be used to Base64-encode a keytab file. This utility is intended for encoding certificates but can be used to generically encode in Base64 by removing the "BEGIN CERTIFICATE" and "END CERTIFICATE" header and footer from the generated file. For example:

certutil -encode krb5.keytab krb5.keytab-tmp.txt && findstr /v /c:- krb5.keytab-tmp.txt > krb5.keytab.txt

Look up the key version number

The key version number of a user account is stored in AD as the msDS-KeyVersionNumber attribute of the user. The current value of this attribute can be determined from the command-line using dsquery, for example:

C:\Users\example-user>dsquery * -filter sAMAccountName=example-user -attr msDS-KeyVersionNumber
  msDS-KeyVersionNumber
  5

It is also possible to find this attribute using Server Manager. Open Server Manager and select Active Directory Users & Computers or ADSI Edit under Tools. Both of these tools allow browsing of the user attributes. Find the user and select Properties and then Attributes. Ensure the Constructed option is selected under Filters, as msDS-KeyVersionNumber is a generated attribute and therefore not editable.

Resource Management in StrongDM

After all prerequisites and prep work is done, you are ready to add the resource to StrongDM. This section provides instructions for adding the resource in either the StrongDM Admin UI, CLI, Terraform provider, or SDKs.

Admin UI

Set up and Manage With the Admin UI

If using the Admin UI to add your Microsoft SQL Server as a resource to StrongDM, use the following steps.

1. Log in to the StrongDM Admin UI.

2. Go to Resources > Datasources.

3. Click Add datasource.

4. For Datasource Type, select Microsoft SQL Server (Kerberos).

5. Complete all required configuration properties for your selected datasource type.

6. Click Create to save the resource.

7. Click the resource name to view status, diagnostic information, and setting details.

CLI

Set up and Manage With the CLI

This section provides an example of how to add the resource using the StrongDM CLI. For more information and examples, please see the CLI Reference documentation.

# Add Microsoft SQL Server (Kerberos) datasource
sdm admin datasources add mssqlKerberos sqlserver-kerb-prod
  --hostname="sqlserver-kerb.example.com"
  --port=1433
  --username="ADUser"
  --realm="EXAMPLE.COM"
  --keytab="BASE64_ENCODED_KEYTAB"
  --krb5-config="BASE64_ENCODED_KRB5_CONF"
  --server-spn="MSSQLSvc/sqlserver-kerb.example.com:1433"
  --bind-interface="127.0.0.1"
  --egress-filter="tag:env=prod"
  --port-override="15433"
  --proxy-cluster-id="n-1a2b345c67890123"
  --secret-store-id="se-e1b2"
  --subdomain="sqlserver-kerb-prod"
  --tags="env=production,team=appdb"

Terraform

Set up and Manage With Terraform

This section provides an example of how to configure and manage the resource using the Terraform provider. For more information and examples, please see the Terraform provider documentation.

# Install StrongDM provider
terraform {
  required_providers {
    sdm = {
      source  = "strongdm/sdm"
      version = "5.1.0"
    }
  }
}

# Configure StrongDM provider
provider "sdm" {
  # Add API access key and secret key from Admin UI
  api_access_key = "njjSn...5hM"
  api_secret_key = "ziG...="
}

# Create Microsoft SQL Server (Kerberos) resource
resource "sdm_mssqlkerberos" "sqlserver_kerb_prod" {
  name             = "sqlserver-kerb-prod"
  hostname         = "sqlserver-kerb.example.com"
  port             = 1433

  username         = "ADUser"
  realm            = "EXAMPLE.COM"
  keytab           = "BASE64_ENCODED_KEYTAB"
  krb5_config      = "BASE64_ENCODED_KRB5_CONF"
  server_spn       = "MSSQLSvc/sqlserver-kerb.example.com:1433"

  bind_interface   = "127.0.0.1"
  egress_filter    = "tag:env=prod"
  port_override    = 15433
  proxy_cluster_id = "n-1a2b345c67890123"

  secret_store_id  = "se-e1b2"
  subdomain        = "sqlserver-kerb-prod"
  tags = {
    env  = "production"
    team = "appdb"
  }
}

SDKs

Set up and manage with SDKs

In addition to the Admin UI, CLI, and Terraform, you may configure and manage your resource with any of the following SDK options: Go, Java, Python, and Ruby. Please see the following references for more information and examples.

Language	Reference	GitHub	Examples
Go	pkg.go.dev	strongdm-sdk-go	Go SDK Examples
Java	javadoc	strongdm-sdk-java	Java SDK Examples
Python	pdocs	strongdm-sdk-python	Python SDK Examples
Ruby	RubyDoc	strongdm-sdk-ruby	Ruby SDK Examples

Configuration Properties

The following configuration properties are required to define a Microsoft SQL Server datasource in StrongDM. These settings control how StrongDM connects to the database, authenticates the connection, and optionally uses encryption or secret management. Each property must be correctly configured to ensure connectivity and access enforcement through StrongDM.

If you are connecting an Azure SQL Server resource, you must enable the Override Default Database option.

Property	Requirement	Description
Display Name	Required	Meaningful name to display the resource throughout StrongDM; exclude special characters like quotes (") or angle brackets (< or >)
Datasource Type	Required	Select Microsoft SQL Server (Kerberos)
Proxy Cluster	Required	Defaults to "None (use gateways)"; if using proxy clusters, select the appropriate cluster to proxy traffic to this resource
Hostname	Required	Hostname for your Microsoft SQL Server database resource; must be accessible to a gateway or relay
Port	Required	Port to use when connecting to your Microsoft SQL Server database; default port value is 1433
Connectivity Mode	Required	Select either Virtual Networking Mode, which lets users connect to the resource with a software-defined, IP-based network; or Loopback Mode, which allows users to connect to the resource using the local loopback adapter in their operating system; this field is shown if Virtual Networking Mode enabled for your organization
IP Address	Optional	If Virtual Networking Mode is the selected connectivity mode, an IP address value in the configured Virtual Networking Mode subnet in the organization network settings; if Loopback Mode is the selected connectivity mode, an IP address value in the configured Loopback IP range in the organization network settings (by default, 127.0.0.1); if not specified, an available IP address in the configured IP address space for the selected connectivity mode will be automatically assigned; this field is shown if Virtual Networking Mode and/or multi-loopback mode is enabled for your organization
Port Override	Optional	If Virtual Networking Mode is the selected connectivity mode, a port value between 1 and 65535 that is not already in use by another resource with the same IP address; if Loopback Mode is the selected connectivity mode, a port value between 1024 to 64999 that is not already in use by another resource with the same IP address; when left empty with Virtual Networking Mode, the system assigns the default port to this resource; when left empty for Loopback Mode, an available port that is not already in use by another resource is assigned; preferred port also can be modified later from the Port Overrides settings
DNS	Optional	If Virtual Networking Mode is the selected connectivity mode, a unique hostname alias for this resource; when set, causes the desktop app to display this resource's human-readable DNS name (for example, k8s.my-organization-name) instead of the bind address that includes IP address and port (for example, 100.64.100.100:5432)
Database	Required	Database name you want to connect to using this datasource
Secret Store	Optional	Credential store location with the default set to Strong Vault; learn more about Secret Store options
Username	Required	Username to utilize when connecting to this resource that must be the name of the AD user account specified in the keytab (excluding the realm) and that must also be trusted by the SQL Server to log in; displays when Secret Store integration is not configured for your organization or when Strong Vault serves as the Secret Store type
Username (path)	Required	Path to the secret in your Secret Store location (for example, path/to/credential?key=KeyName where key argument is required); required when using a non-StrongDM Secret Store type
Kerberos Keytab	Required	File that you generate that stores long-term keys and is used to obtain keys for the client (Base64-encoded). Should contain an entry with the principal name in the format<YOUR_USERNAME>@<YOUR_REALM> and a key version number with which to authenticate.
Kerberos Keytab (path)	Required	Path to the secret in your Secret Store location (for example, path/to/credential?key=KeyName where key argument is required); required when using a non-StrongDM Secret Store type
Kerberos Configuration	Required	File that you generate (krb5.conf) that contains Kerberos configuration information (Base64-encoded). It should specify the AD Server (KDC) for the configured realm.
Kerberos Configuration (path)	Required	Path to the secret in your Secret Store location (for example, path/to/credential?key=KeyName where key argument is required); required when using a non-StrongDM Secret Store type
Schema	Optional	Name of the schema that should be used if the user belongs to a particular schema
Override Default Database	Optional	By default, StrongDM limits all connections to the configured database. Uncheck the box to disable this option. If this option is deselected, the value entered in the Database field is only used for healthchecks, not for user connections. When accessing the database via StrongDM, users need to explicitly pass the database name they wish to connect to in the connection string. If they do not, the value of the Username field is passed in as the database name. This is the default behavior of the database type.
Allow Deprecated Encryption Methods	Optional	When selected, allows deprecated encryption protocols (for example, TLS 1.0) to be used for this resource
Realm (path)	Required	Path to the secret in your Secret Store location (for example, path/to/credential?key=KeyName where key argument is required); required when using a non-StrongDM Secret Store type
Server SPN	Required	Service Principal Name (SPN) for the Microsoft SQL Server instance in AD in the format MSSQLSvc/<YOUR_SERVER>:<YOUR_PORT> (example: MSSQLSvc/test-mssql.ad.example.com:1433)
Realm	Required	Realm (domain) from the Kerberos Configuration file to which the configured username belongs, in the format AD.EXAMPLE.COM
Resource Tags	Optional	Datasource Tags consisting of key-value pairs <KEY>=<VALUE> (for example, env=dev)

Secret Store options

By default, datasource credentials are stored in StrongDM. However, these credentials can also be saved in a secrets management tool.

Non-StrongDM options appear in the Secret Store dropdown if they are created under Network > Secret Stores. When you select another Secret Store type, its unique properties display. For more details, see Configure Secret Store Integrations.

Resource status

After a resource is created, the Admin UI displays that resource as unhealthy until the healthchecks run successfully. When the resource is ready, the Health icon indicates a positive, green status.

When the resource does not display a positive status, click the resource name to go to the Diagnostics tab and check for errors.

Test the Connection

After you have added your resource in StrongDM, follow these steps to verify that it’s working correctly.

1. Assign yourself access by ensuring that your user or role has access to the resource. In the StrongDM Admin UI, go to Access > Roles, and verify that the resource is attached to a role you’re in.

2. In the CLI, run sdm status to list the available datasources. Ensure that the resource appears in your list of accessible datasources.

3. Start a session to the resource, as in the following example:

   sdm connect sqlserver-kerb-prod

4. Connect using a Kerberos-enabled client (for example, using sqlcmd with integrated authentication via keytab, or a JDBC/ODBC driver configured for Kerberos). Use the SPN, realm, keytab, and so forth, to authenticate. Then run a simple query. For example:

   SELECT @@VERSION;

5. In the StrongDM Admin UI, check Logs > Queries (and Logs > Connections) to verify session establishment and audit of queries.

When these steps succeed, you’re ready to connect to your resource through StrongDM.

Help

If you still encounter issues, please consult the StrongDM Help Center.

Be prepared to provide the following information to StrongDM Support, so that they can inspect logs and confirm node and resource health:

• Resource name or ID

• CLI error output or logs

• Node name and region