ADO.Net Ändern Sie den Standardwert für "Persist Security Info" wieder auf "True"

8

Information: Wir haben eine Anwendung von Drittanbietern, die wir für die Produktion in unserem Unternehmen verwenden. Dieses Programm verwendet einen DSN, um eine Verbindung zu unserer SQL Server 2012-Datenbank über ODBC herzustellen. Diese Anwendung funktioniert ordnungsgemäß unter Server 2003 (MADC 2.8), aber wenn ich es auf Server 2008 x86 (DAC 6.0) bringen, bekomme ich eine Verbindung mit "Microsoft OLE DB-Provider SQL Server Login für Benutzer XXX fehlgeschlagen" fehlgeschlagen. Ich habe das Gefühl, dass dies der Grund dafür ist, dass die "persist security info" auf Servern mit Windows ab Server 2008 von True auf False wechselt (Änderung in DAC 6.0). Ich habe keinen Zugriff darauf, die Verbindungszeichenfolge in der Anwendung zu ändern, da es sich um eine Drittpartei handelt. wie in diesem Artikel

Frage: Gibt es eine Möglichkeit, das Verhalten von ADO.Net so zu ändern, dass dieser Wert außerhalb der Verbindungszeichenfolge standardmäßig auf "True" und nicht auf "False" gesetzt wird. Ich möchte zumindest beweisen oder widerlegen können, dass dies das Problem ist, das das Problem verursacht.

Hinweis: Mir ist klar, dass dies ein riesiges Sicherheitsproblem ist, das diese Einstellung manipuliert, und wir werden die richtigen Vorsichtsmaßnahmen treffen, wenn es geändert wird, um sicherzustellen, dass der Server und die Anwendung isoliert sind.

Lösung: Zur Verfügung gestellt von @William unten. Wenn Sie Ihre SQL Server-Anwendung von Drittanbietern aktualisieren Von Server 2003 auf Server 2008+ und Sie erhalten eine Verbindung wie oben, für die Sie 2003 nicht festgelegt haben, legen Sie das Kennwort für das SQL-Konto leer (temporär oder nur im Staging) sehr gefährlich, um in der Produktion leer zu bleiben), um zu testen, ob die Anwendung erneut funktioniert, wenn ein leeres Passwort angegeben wird. Wenn dies der Fall ist, setzt die Anwendung die persistenten Sicherheitsinformationen nicht in der Verbindungszeichenfolge und der Wert, der standardmäßig auf "wahr" gesetzt wurde, wird jetzt standardmäßig auf "false" gesetzt. Ihre Anwendung ist möglicherweise auf die Verwendung unter Server 2003 beschränkt und funktioniert möglicherweise nicht ordnungsgemäß auf Server 2008+. Es gibt keinen Weg, den ich finden könnte, um den Wert auf Standard zurück auf wahr zu bekommen.

    
Random Developer 17.06.2015, 14:19
quelle

1 Antwort

4

Wenn die Anwendung das vorhandene Verbindungsobjekt verwendet, um neue Verbindungszeichenfolgen zu erstellen, könnte es eine Problemumgehung für dieses Problem geben - abhängig von der Anwendung und Sicherheitseinschränkungen.

Da dieses Problem bei Verwendung integrierter Sicherheit wahrscheinlich nicht existiert, können wir davon ausgehen, dass "SQL Server Standard Security" eine Voraussetzung ist. Wenn ein leeres Kennwort für das SQL Server-Konto verwendet wird, ist es dann (wenn auch zufällig) korrekt, wenn die neue Verbindungszeichenfolge erstellt wird.

    
William 10.07.2015, 20:28
quelle