Share via

Automating ODBC Data Source Deployment with Embedded Credentials

Wei Wei 0 Reputation points
2026-03-24T03:17:10.9266667+00:00

I am trying to set up a series of ODBC connections for SQL Server across several hundred Windows machines on our corporate network, but the main issue is that they all require pre-saved login credentials. Setting up the connection without credentials is easy, but I cannot find a supported way to include usernames and passwords; scripts and registry changes are falling short. This is becoming a major headache as we are preparing a company-wide application rollout, and users are constantly being hit with login prompts. Is there a workaround or a proper solution for this?

Windows for business | Windows Server | Devices and deployment | Other
0 comments

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. VPHAN 35,285 Reputation points Independent Advisor
    2026-03-25T17:05:09.51+00:00

    Hi Wei Wei,

    How is your issue going? Has it been resolved yet? If it has, please consider accepting the answer as it helps others sharing the same problem benefit too. Thank you :)

    VP

    Was this answer helpful?

    0 comments
  2. VPHAN 35,285 Reputation points Independent Advisor
    2026-03-24T03:39:31.3066667+00:00

    Hi Wei Wei,

    Your previous attempts to inject credentials using scripts and registry modifications are failing because of a deliberate security architecture within the Windows ODBC Data Source Administrator. When you deploy a System or User DSN, the ODBC driver manager intentionally drops the password attribute before writing the connection string to the registry path at HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI. This behavior is by design to prevent plain-text database credentials from being exposed to malicious software or unauthorized users browsing the registry. Because of this restriction, there is no supported or secure method to permanently bake SQL Authentication passwords directly into a deployed DSN.

    To resolve the login prompts for your users while maintaining strict security compliance, you must transition your ODBC deployment to Windows Integrated Authentication. This approach leverages your existing Active Directory infrastructure, allowing the ODBC driver to automatically pass the currently logged-in Windows user's token directly to the SQL Server. You can implement this by adjusting your deployment scripts to create a string value named Trusted_Connection and setting its data to Yes within your specific DSN registry key, while completely omitting the user ID and password fields. Once your database administrators map the appropriate Active Directory security groups to the required SQL Server roles, your users will authenticate silently in the background when launching the application.

    Hope this answer brought you some useful information. If it did, please hit “accept answer”. Should you have any questions, feel free to leave a comment.

    VP

    Was this answer helpful?

    0 comments

  3. AI answer

    2026-03-24T03:17:25.6366667+00:00

    There is no supported, secure way to mass‑deploy ODBC DSNs with embedded SQL usernames and passwords on Windows. The platform and drivers are designed specifically to avoid storing credentials in connection strings or DSN definitions for security reasons.

    Key points from the documentation and related guidance:

    1. Avoid embedding passwords in connection strings or DSNs
      • For SSRS/Report Builder and ODBC, guidance is to not add login information such as passwords to the connection string because it is a major security weakness and can also cause validation issues with some drivers, especially when special characters are used.
      • Instead, credentials are expected to be supplied at runtime or stored in a secure service‑side location.
    2. Use integrated/Windows authentication where possible
      • When using ODBC to SQL Server, the recommended approach for multiuser environments is to rely on Windows Integrated security (trusted connections) rather than distributing SQL logins.
      • In connection strings, this is typically done via Trusted_Connection=Yes or equivalent, and in DSN configuration via “With Integrated Windows Authentication” or “Windows Integrated” authentication mode.
      • This shifts authentication to domain accounts and group memberships, which can be centrally managed via Active Directory / Microsoft Entra ID, eliminating the need to pre‑save SQL usernames/passwords on each client.
    3. Centralize credentials on the server side when using reporting tools
      • For SSRS/Report Builder scenarios, credentials are stored securely on the report server or associated with the report’s data source, not in each client’s DSN or report file.
      • Users then run reports without entering database credentials, because the report server uses stored credentials or impersonation according to the configured credential type (Integrated security, Windows credentials, database credentials, or none with unattended execution account).
    4. If SQL logins are unavoidable, prompt or manage them per user
      • ODBC drivers support prompting for credentials via:
        • Application‑managed dialogs that collect user ID/password and pass them to SQLDriverConnect.
        • Driver‑managed dialogs (for example, the SQL Server Login dialog) when the connection string/DSN does not contain enough information.
      • This is by design; the driver expects credentials to be supplied interactively or by the calling application, not baked into DSNs.
    5. Security and manageability implications
      • Hard‑coding or mass‑deploying SQL usernames/passwords (even obfuscated) to hundreds of machines is considered insecure and is not supported by the documented patterns.
      • Recommended patterns are:
        • Use Windows Integrated / Microsoft Entra / Managed Identity authentication for SQL Server.
        • Store any shared credentials in a secure, central service (for example, SSRS data source credentials, application configuration protected by OS or DPAPI, or a secrets vault) rather than in DSNs on each client.

    Given these constraints, the proper solution for a company‑wide rollout is to redesign authentication so that:

    • ODBC DSNs use Integrated Windows Authentication (or Microsoft Entra/Managed Identity where applicable), and
    • The application or reporting layer handles any necessary credential storage centrally and securely, instead of embedding credentials into each client’s ODBC configuration.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.