ADO.Net如何将“Persist Security Info”默认值更改回True?

8
信息:我们在公司使用第三方应用程序进行生产。该程序使用DSN通过ODBC连接到我们的SQL Server 2012数据库。此应用程序在Server 2003 (MADC 2.8)下工作正常,但是当我将其带到Server 2008 x86 (DAC 6.0)时,出现了连接失败,显示“Microsoft OLE DB Provider SQL Server Login failed for user XXX”。我有一种感觉,这是由于默认值“persist security info”从True更改为False,在Server 2008及更高版本的Windows服务器上发生的(在DAC 6.0中进行更改)。由于该应用程序是第三方的,我无法访问更改应用程序内部的连接字符串。文章 问题: 是否有办法更改ADO.Net的行为,使此值默认为True而不是False(在连接字符串之外)?我想至少能够证明或否定这个特性是否引起了问题。 注意: 我意识到这是一个巨大的安全问题,修改此设置会产生风险。如果更改了该值,我们将采取正确的预防措施,以确保服务器和应用程序被隔离。 解决方案: 由@William提供。如果您正在将SQL Server第三方应用程序从Server 2003更新到Server 2008+,并且出现了上述连接问题,则将SQL帐户的密码设置为空白(仅在临时或分期阶段,这在生产中非常危险)以测试应用程序是否会在提供空白密码时再次正常工作。如果工作正常,则该应用程序未在连接字符串中设置Persist Security Info,并且默认为true的值现在默认为false。您的应用程序可能被限制在使用Server 2003下,并且在Server 2008+上可能无法正常运行。我找不到任何方法来使该值默认回到true。

1
你是否尝试过在 [HKLM]\SOFTWARE\ODBC\ODBC.INI\ 的注册表下编辑你的 DSN 连接? - KarmaEDV
据我所知,每次应用程序启动时都会发生以下情况。如果应用程序尚未设置,则会在根目录中创建一个新的.DSN文件,然后允许最终用户使用设置配置此文件,在用户登录时,ODBC注册表中的设置将从上次成功登录更新,然后reg DSN用于应用程序。连接字符串是在对象代码中构建的,不存储在注册表中。我已经尝试在DSN下向注册表添加其他键,但它们会被覆盖或无法加载到代码中的对象中。 - Random Developer
1
我有一个类似的问题。我们有一个遗留应用程序(没有源代码),需要将其移植到使用Windows 2008,并且该应用程序依赖于能够从连接对象中获取连接字符串以创建更多连接。它是在Persist Security Info的影响被广泛知晓之前编写的,因此没有指定它(隐含地依赖于默认值)。由于默认值在Windows Vista及更高版本中更改为False,因此该应用程序无法在其中运行。我还没有找到任何设置系统(或用户)默认Persist Security Info的方法。 - William
1个回答

4

如果应用程序正在使用现有的连接对象来构建新的连接字符串,那么根据应用程序和安全约束,可能存在解决此问题的方法。

由于在使用集成安全性时可能不存在此问题,因此我们可以假设“SQL Server标准安全性”是必需的。 如果对于 SQL 服务器帐户使用空白密码,那么当构建新的连接字符串时,它将是正确的(某种程度上是偶然发生的)。


享受这份奖励,这是一种可靠的方法来证明连接字符串中未设置持久性安全信息。就像你所说的,将密码留空是有些危险的,在生产环境中不应该这样做。在解决我们的问题时,如果我们计划实施这个更改,我们需要非常仔细地思考。感谢您的帮助! - Random Developer

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接