SQL Server¶
Backed by the ADBC ODBC driver and the go-mssqldb client.
Authentication¶
Default port: 1433 - Driver: dbc install mssql
| Auth type | Fields you'll enter |
|---|---|
sql_auth |
Username (SQL Server username), Password (SQL Server password) |
azure_ad_service_principal |
Username (Entra ID application (client) ID), Password (Client secret) |
azure_ad_managed_identity |
Username (Client ID of a user-assigned identity (optional — omit for system-assigned)) |
azure_ad_default |
Nothing extra |
azure_ad_access_token |
Nothing extra |
Extra parameters:
| Parameter | Applies to | Description |
|---|---|---|
application_client_id |
azure_ad_service_principal |
Entra ID application (client) ID, as an alternative to the Username field. |
client_cert_path |
azure_ad_service_principal |
Path to a client certificate file, as an alternative to a client secret. |
client_id |
azure_ad_managed_identity |
Client ID of a user-assigned managed identity, as an alternative to the Username field. |
instance |
All | A named SQL Server instance. |
encrypt |
All | Encryption mode: true, false, or strict. |
TrustServerCertificate |
All | Skip certificate validation: true or false. |
connection timeout |
All | Connection timeout in seconds. |
Verification status
azure_ad_managed_identity and azure_ad_default depend on the ADBC
SQL Server driver forwarding its federated-auth parameter through to
the underlying Azure Identity credential chain, running on the server
side. This has not been exercised against a live Azure SQL endpoint.
azure_ad_access_token is the documented fallback — CatalystData
acquires the token itself and forwards it, so it needs no credential
chain on the connector side at all.