8

信息:我们有一个用于我们公司生产的第 3 方应用程序。该程序使用 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”。我感觉这是由于从服务器 2008 及更高版本开始的 Windows 服务器上“持久安全信息”的默认设置从 True 更改为 False(在 DAC 6.0 中进行了更改)。我无权更改应用程序内的连接字符串,因为它是第 3 方。如本文所示

问题:有什么方法可以改变 ADO.Net 的行为,以便在连接字符串之外将此值默认为 True 而不是 False。我希望至少能够证明或反驳这是导致问题的功能。

注意:我意识到这是一个篡改此设置的巨大安全问题,如果更改它以确保服务器和应用程序是隔离的,我们将采取正确的预防措施。

解决方案:由下面的@William 提供。如果您正在将 SQL Server 3rd 方应用程序从 Server 2003 更新到 Server 2008+,并且您获得了类似上面 2003 年没有的连接,请将 SQL 帐户的密码设置为空白(暂时或仅在暂存时,这是在生产中留空非常危险)以测试应用程序在提供空白密码时是否再次工作。如果是这样,则应用程序未在连接字符串中设置持久安全信息,并且默认为 true 的值现在默认为 false。您的应用程序可能仅限于在 server 2003 下使用,并且可能无法在 server 2008+ 上正常运行。我无法找到将默认值恢复为 true 的方法。

4

1 回答 1

4

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

由于使用集成安全性时可能不存在此问题,因此我们可以假设“SQL Server 标准安全性”是一项要求。如果SQL 服务器帐户使用空白密码,那么在构造新的连接字符串时,它将是正确的(有点意外)。

于 2015-07-10T20:28:07.383 回答