# Microsoft SQL Server (Kerberos) ## 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)](https://docs.strongdm.com/admin/resources/datasources/microsoft-sql-server-azure-ad) and [Microsoft SQL Server](https://docs.strongdm.com/admin/resources/datasources/microsoft-sql-server) resource types. When the resource is added, StrongDM proxies client connections through a [node](https://docs.strongdm.com/admin/networking) (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](https://docs.strongdm.com/admin/resources/datasources). ## Supported Versions and Clients {% hint style="info" %} StrongDM supports Microsoft SQL Server versions 2016, 2017, 2019, 2022, and 2025. {% endhint %} 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 {% hint style="info" %} To verify that the resource is accessible by the node, log in to the gateway or relay and use Netcat: `nc -zv ` (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". {% endhint %} 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](#generate-a-keytab-file) (Base64-encoded) for the AD user, which will be used for Kerberos authentication * [Generated krb5.conf file](#generate-a-krb5conf-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. {% hint style="info" %} For detailed information, refer to the krb5.conf man page or [MIT Kerberos Documentation](https://web.mit.edu/kerberos/krb5-1.12/doc/admin/conf_files/krb5_conf.html). Only a small portion of the possible configuration parameters are relevant to StrongDM’s use of Kerberos and need to be defined. {% endhint %} 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 `example-user@AD.EXAMPLE.COM` * 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. {% hint style="info" %} 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. {% endhint %} 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](#keytabs-on-macos), [Linux](#keytabs-on-linux), or [Windows](#keytabs-on-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: ```sh ktutil -k add -p -e -V ``` * `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: ```sh ktutil -k krb5.keytab add -p example-user@AD.EXAMPLE.COM -e aes256-cts-hmac-sha1-96 -V 5 ``` **List entries in the keytab** To list all entries in a specified keytab, use the following: ```sh ktutil -k list ``` For example: ```sh $ ktutil -k krb5.keytab list krb5.keytab: Vno Type Principal Aliases 5 aes256-cts-hmac-sha1-96 example-user@AD.EXAMPLE.COM ``` **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. ```sh KRB5_CONFIG= kinit -c -V -t -S ``` * `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: ```sh $ KRB5_CONFIG=krb5.conf kinit -c krb5.cache -V -t krb5.keytab -S 'MSSQLSvc/prod-mssql.ad.example.com:1433' example-user@AD.EXAMPLE.COM klist -c krb5.cache Credentials cache: FILE:krb5.cache Principal: example-user@AD.EXAMPLE.COM Issued Expires Principal May 10 16:43:19 2023 May 10 16:48:18 2023 MSSQLSvc/prod-mssql.ad.example.com:1433@AD.EXAMPLE.COM ``` 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: ```sh 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. ```sh ldapsearch -h -D -W -b ``` This prompts for the password of the user for authentication. For example: ```sh $ ldapsearch -h ad.example.com -D example-user@ad.example.com -W -b "cn=users,dc=ad,dc=example,dc=com" "(cn=example-user)" msDS-KeyVersionNumber # extended LDIF # # LDAPv3 # base 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 {% hint style="warning" %} 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](#keytabs-on-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. {% endhint %} **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 ``: ```sh $ ktutil ktutil: add_entry -password -p -e -k ktutil: write_kt ktutil: quit ``` For example: ```sh $ ktutil ktutil: add_entry -password -p example-user@AD.EXAMPLE.COM -e aes256-cts-hmac-sha1-96 -k 5 Password for example-user@AD.EXAMPLE.COM: 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. {% hint style="info" %} 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. {% endhint %} **List entries in the keytab** To list all entries in the keytab, invoke `ktutil` and use the `read_kt` and `list` commands: ```sh $ ktutil ktutil: read_kt ktutil: list ktutil: quit ``` For example: ```sh $ ktutil ktutil: read_kt krb5.keytab ktutil: list slot KVNO Principal ---- ---- --------------------------------------------------------------------- 1 5 example-user@AD.EXAMPLE.COM ktutil: quit ``` **Verify the keytab** To verify the keytab by acquiring a service ticket, `kinit` can be used: ```sh KRB5_CONFIG= kinit -c -V -k -t -S ``` For example: ```sh 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: ```sh 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. ```sh ldapsearch -h -D -W -b ``` This prompts for the password of the user for authentication. For example: ```sh $ ldapsearch -h ad.example.com -D example-user@ad.example.com -W -b "cn=users,dc=ad,dc=example,dc=com" "(cn=example-user)" msDS-KeyVersionNumber # extended LDIF # # LDAPv3 # base 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: ```powershell ktpass -princ @ -pass -crypto -ptype -kvno -out ``` For example: ```powershell ktpass -princ example-user@AD.EXAMPLE.COM -pass * -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -kvno 6 -out krb5.keytab ``` See [ktpass](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/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: ```powershell C:\Users\example-user>ktpass -in krb5.keytab Existing keytab: Keytab version: 0x502 keysize 89 example-user@AD.EXAMPLE.COM 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: ```powershell 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: ```powershell 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. {% tabs %} {% tab title="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** > **Managed Resources**. 3. Click **Add Resource**. 4. For **Resource Type**, select **Microsoft SQL Server (Kerberos)**. 5. Complete all required [configuration properties](#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. {% endtab %} {% tab title="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](https://app.gitbook.com/s/4XOJmXFslCMVCzIG2rKp/cli) 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" ``` {% endtab %} {% tab title="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](https://github.com/strongdm/terraform-provider-sdm) documentation. ``` # Install StrongDM provider terraform { required_providers { sdm = { source = "strongdm/sdm" version = "16.5.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" } } ``` {% endtab %} {% tab title="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](https://pkg.go.dev/github.com/strongdm/strongdm-sdk-go/v16) | [strongdm-sdk-go](https://github.com/strongdm/strongdm-sdk-go) | [Go SDK Examples](https://github.com/strongdm/strongdm-sdk-go-examples) | | Java | [javadoc](https://strongdm.github.io/strongdm-sdk-java-docs/) | [strongdm-sdk-java](https://github.com/strongdm/strongdm-sdk-java) | [Java SDK Examples](https://github.com/strongdm/strongdm-sdk-java-examples) | | Python | [pdocs](https://strongdm.github.io/strongdm-sdk-python-docs/) | [strongdm-sdk-python](https://github.com/strongdm/strongdm-sdk-python) | [Python SDK Examples](https://github.com/strongdm/strongdm-sdk-python-examples) | | Ruby | [RubyDoc](https://www.rubydoc.info/gems/strongdm) | [strongdm-sdk-ruby](https://github.com/strongdm/strongdm-sdk-ruby) | [Ruby SDK Examples](https://github.com/strongdm/strongdm-sdk-ruby-examples) | | {% endtab %} | | | | | {% endtabs %} | | | | ## **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. {% hint style="info" %} If you are connecting an Azure SQL Server resource, you must enable the **Override Default Database** option. {% endhint %} | Property | Requirement | Description | | --------------------------------------- | ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Display Name** | Required | Meaningful name to display the resource throughout StrongDM; exclude special characters like quotes (") or angle brackets (< or >) | | **Resource Type** | Required | Select **Microsoft SQL Server (Kerberos)** | | **Proxy Cluster** | Required | Defaults to "None (use gateways)"; if using [proxy clusters](https://docs.strongdm.com/admin/networking/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](#prerequisites) 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](https://docs.strongdm.com/admin/clients/client-networking/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](https://docs.strongdm.com/admin/clients/client-networking/virtual-networking-mode) and/or [multi-loopback mode](https://docs.strongdm.com/admin/clients/client-networking/loopback-ip-ranges) 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](https://docs.strongdm.com/admin/resources/port-overrides) | | **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; defaults to none (credentials are stored in StrongDM resource configuration); learn more about [Secret Store](https://docs.strongdm.com/admin/resources/microsoft-sql-server-azure-ad#secret-store-options) 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 and chosen as the value of **Secret Store** | | **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`@` 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/:` (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](https://app.gitbook.com/s/4XOJmXFslCMVCzIG2rKp/cli/tags "mention") consisting of key-value pairs `=` (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](https://docs.strongdm.com/admin/access/secret-stores). ### 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: ```bash 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](https://help.strongdm.com/hc/en-us). 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 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.strongdm.com/admin/resources/datasources/microsoft-sql-server-kerberos.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.