Update base.py#520
Conversation
This change fixes an authentication issue in _build_connection_string() where Trusted_Connection is implicitly enabled even when it was never configured by the user.
@microsoft-github-policy-service agree |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
@OctaOmega - thanks for your contribution! |
There was a problem hiding this comment.
Pull request overview
This PR adjusts how mssql/base.py::_build_connection_string() chooses authentication-related ODBC keywords to avoid implicitly enabling Windows integrated authentication for Microsoft SQL Server drivers when the user did not explicitly request it.
Changes:
- Default
Trusted_Connectionis changed toNoneand is only appended when explicitly provided. - Stops injecting
Integrated Security=SSPIfor Microsoft drivers (keeps legacySSPIbehavior for non-Microsoft drivers). - Adds inline comments clarifying the intended authentication behavior.
| password = conn_params.get('PASSWORD', None) | ||
| port = conn_params.get('PORT', None) | ||
| trusted_connection = conn_params.get('Trusted_Connection', 'yes') | ||
| trusted_connection = conn_params.get('Trusted_Connection', None) |
| # or Trusted_Connection. | ||
| if not ms_drivers.match(driver): | ||
| cstr_parts['Integrated Security'] = 'SSPI' | ||
|
|
This change fixes an authentication issue in
_build_connection_string()where Windows authentication is implicitly enabled even when it was never configured by the user.Problem
The current code does this:
and later, when
USERis not present and noTOKENis supplied, it unconditionally adds:Additionally, in another branch it adds:
For Microsoft SQL Server drivers, both of these effectively enable Windows integrated authentication:
Trusted_Connection=yesIntegrated Security=SSPIAs a result, Windows authentication is silently injected into the ODBC connection string by default.
This causes failures in environments that use SQL Server authentication, because the backend forces Windows auth even though the user did not explicitly request it.
Why this is a bug
Not specifying authentication should not be treated as equivalent to enabling Windows authentication.
These are different cases:
Trusted_Connection=yesorIntegrated Security=SSPI→ Explicit request for Windows authentication
No authentication parameters provided
→ No preference expressed; backend should not force a mode
By defaulting to
Trusted_Connection='yes'and unconditionally addingIntegrated Security=SSPI, the current implementation overrides SQL authentication and leads to unexpected connection failures.Fix
Trusted_Connectionfrom'yes'toNoneTrusted_Connectionif it is explicitly providedIntegrated Security=SSPIfor Microsoft SQL Server drivers unless explicitly requiredThis ensures the backend does not implicitly force Windows authentication.
Behavior after this change
Trusted_Connection='yes', it is still addedIntegrated Security=SSPIvia non-Microsoft drivers, legacy behavior is preservedUSERandPASSWORD, SQL authentication works as expectedSummary
This is a minimal and backward-compatible fix that removes implicit Windows authentication (
Trusted_Connection/SSPI) for Microsoft SQL Server drivers, preventing unintended overrides of SQL authentication while preserving explicitly configured behavior.