Der Unterschied zwischen integrierter Sicherheit = True und Integrated Sicherheit = SSPI

Question

Ich habe zwei Anwendungen, die integrierte Sicherheit verwenden. Man ordnet Integrated Security = true in der Verbindungszeichenfolge und die anderen setzt Integrated Security = SSPI.

Was ist der Unterschied zwischen SSPI und true im Kontext der integrierten Sicherheit?

Answer 1

Nach Microsoft sind sie das gleiche.

Wenn false, sind Benutzer-ID und Passwort in der Verbindung angegeben. Wenn dies der Fall ist, werden die aktuellen Windows-Kontoanmeldeinformationen für die Authentifizierung verwendet.
Gültige Werte sind true, false, yes, no und (dringend empfohlen), die true entspricht.

Answer 2

Lassen Sie uns beginnen mit Integrated Security = false

false Benutzer-ID und Kennwort in der Verbindungszeichenfolge angegeben werden.
true Windows-Kontoanmeldeinformationen werden für die Authentifizierung verwendet.

Erkannte Werte sind true, false, yes, no und SSPI.

Wenn User ID und Password spezifiziert und integrierte Sicherheit wird auf true, dann User ID und Password werden ignoriert und Integrierte Sicherheit wird

Answer 3

Verwendung von Windows-Authentifizierung verwendet werden

Um die Verbindung Datenbankserver wird empfohlen, die Windows-Authentifizierung zu verwenden, die allgemein als integrierte Sicherheit bezeichnet wird. Um die Windows-Authentifizierung anzugeben, können Sie eines der folgenden zwei Schlüssel/Wert-Paare mit dem Datenprovider verwenden. NET Framework für SQL Server:

Integrated Security = true; 
Integrated Security = SSPI; 

jedoch nur die zweite Arbeit mit dem Datenanbieter .NET Framework OleDb. Wenn Sie Integrated Security = true für ConnectionString festlegen, wird eine Ausnahme ausgelöst.

Zum Angeben der Windows-Authentifizierung im Datenprovider. NET Framework für ODBC sollten Sie das folgende Schlüssel/Wert-Paar verwenden.

Trusted_Connection = yes; 

Quelle: MSDN: Working with Connection Strings

Answer 4

Integrated Security = False: User-ID und Passwort sind in der Verbindung angegeben. Integrierte Sicherheit = true: Die aktuellen Windows-Kontoanmeldeinformationen werden für die Authentifizierung verwendet.

Integrierte Sicherheit = SSPI: Dies ist gleichbedeutend mit wahr.

Wir können den Benutzernamen und das Passwort vermeiden Attribute aus der Verbindungszeichenfolge und verwenden Sie die integrierte Sicherheit

Answer 5

Viele Fragen Antworten bekommen, wenn wir .Net Reflector verwenden den eigentlichen Code von SqlConnection :) true und gleich sind zu sehen:

internal class DbConnectionOptions 

... 

internal bool ConvertValueToIntegratedSecurityInternal(string stringValue) 
{ 
    if ((CompareInsensitiveInvariant(stringValue, "sspi") || CompareInsensitiveInvariant(stringValue, "true")) || CompareInsensitiveInvariant(stringValue, "yes")) 
    { 
     return true; 
    } 
} 

... 

EDIT 2018.02.20 Jetzt in .Net-Core können wir seine Open-Source auf github sehen! Suche nach ConvertValueToIntegratedSecurityInternal Methode:

https://github.com/dotnet/corefx/blob/fdbb160aeb0fad168b3603dbdd971d568151a0c8/src/System.Data.SqlClient/src/System/Data/Common/DbConnectionOptions.cs

Answer 6

Beachten Sie, dass Verbindungszeichenfolgen sind spezifisch für WHAT und wie Sie Daten verbinden. Diese verbinden sich mit derselben Datenbank, aber die erste verwendet .NET Framework Data Provider für SQL Server. Integrierte Sicherheit = True funktioniert nicht für OleDb.

• Data Source = .; Initial Catalog = aspnetdb; Integrated Security = True
• Provider = SQLOLEDB; Data Source = .; Integrated Security = SSPI; Initial Catalog = aspnetdb

Im Zweifel Verwenden Sie die Datenverbindungen von Visual Studio Server Explorer.

• Was ist sspi?
• Connection Strings Syntax

Answer 7

Integrated Security=true; funktioniert nicht in allen SQL-Provider, es löst eine Ausnahme aus, wenn sie mit dem OleDb Anbieter verwendet.

Also grundsätzlich Integrated Security=SSPI; ist bevorzugt, da mit SQLClient & OleDB Anbieter arbeitet.

Hier ist der volle Satz von Syntaxen nach MSDN - Connection String Syntax (ADO.NET)

Answer 8

Wahr ist nur gültig, wenn Sie die .NET SqlClient-Bibliothek verwenden. Es ist nicht gültig, wenn Sie OLEDB verwenden. Wenn SSPI in beiden verwendet wird, verwenden Sie entweder die .net SqlClient-Bibliothek oder OLEDB.

Answer 9

In meiner Sicht, nicht

Wenn Sie die integrierte Sicherheit verwenden = SSPI, dann müssen Sie den Benutzernamen und das Kennwort in der Verbindungszeichenfolge codieren, die „relativ unsicher“ warum denn alle Mitarbeiter die haben bedeutet, Zugang auch Ex-Mitarbeiter könnten die Informationen in böser Absicht nutzen.