Was ist der Unterschied zwischen Integrated Security = True und Integrated Security = SSPI?

531

Ich habe zwei Apps, die Integrated Security verwenden. Einer weist Integrated Security = truein der Verbindungszeichenfolge zu, der andere setzt Integrated Security = SSPI.

Was ist der Unterschied zwischen SSPIund trueim Kontext der integrierten Sicherheit?

— JD.
quelle

70

Die akzeptierte Antwort ist nicht die beste, sie ist auch nicht vollständig korrekt. Integrated Security = Trueoder SSPIsind nicht gleich. Integrated Security=true;funktioniert nicht bei allen SQL-Anbietern, löst bei Verwendung mit dem OleDbAnbieter eine Ausnahme aus . Also im Grunde Integrated Security=SSPI;ist seit Arbeiten mit beiden bevorzugt SQLClient& OleDBProvider. Ich habe eine Antwort zur besseren Klarstellung hinzugefügt.

— Pranav Singh

3

@PranavSingh hat die richtige Idee, diese Frage ist unvollständig, es sei denn, Sie geben an, welchen Anbieter Sie verwenden. Verschiedene Anbieter akzeptieren und / oder übersetzen verschiedene Zeichenfolgen in interne Zustände.

— Mark

Obwohl sie gleich sind, glaube ich, dass es auf einer der Websites ein sehr altes Dokument gab. Zu der Zeit war ich genauso neugierig wie Sie. Das heißt, wenn Sie für Windows Mobile entwickeln (nicht das, was Sie heute sehen, die alten Geräte, die ich Ich erinnere mich nicht an das Betriebssystem-Suffix, da ich nie eines hatte. Sie sollten SSPI und Benutzerkennwort zusammen verwenden. Aber da ich nie einen geschrieben habe und mich nicht an die Quelle dieses Dokuments erinnere, kann ich es nicht garantieren.

— deadManN

436

Laut Microsoft sind sie dasselbe.

Wann falsewerden Benutzer-ID und Passwort in der Verbindung angegeben. Wenn true, werden die aktuellen Anmeldeinformationen des Windows-Kontos zur Authentifizierung verwendet.
Erkannte Werte sind true, false, yes, no, und sspi(dringend empfohlen), was äquivalent ist true.

— cptScarlet
quelle

28

Ursprünglich gab es meines Erachtens einen Unterschied darin, dass "True" NTLM und "SSPI" Kerberos verwendete, aber sie sind jetzt austauschbar.

— SqlRyan

5

Der letzte Kommentar wurde nicht überprüft, aber wenn er wahr ist, sollte er als Antwort dienen, aber nicht der Kommentar

— Johnny_D

20

@ RodneyFoley Entschuldigung, meine Tests bestätigen, dass diese Antwort korrekt ist und Ihr Kommentar nicht. Vielleicht hat es einmal so funktioniert, aber jetzt nicht, und Sie können keinen Verweis auf ein Microsoft-Dokument geben, das Ihre Meinung unterstützt.

— Kirk Broadhurst

3

Stimmen Sie Kirk zu. Benutzer / Passwort wird ignoriert, wenn SSPI angegeben wird - .net 4.0, SQL Server 2012.

— Alex des Pelagos

3

Also, wenn sie "dasselbe sind", warum wird SSPI "dringend empfohlen" anstatt "wahr" oder "ja"? Das ist der Grund, warum ich zu dieser Frage gekommen bin ...

— Zé Carlos

171

Integrated Security=true;funktioniert nicht bei allen SQL-Anbietern, löst bei Verwendung mit dem OleDbAnbieter eine Ausnahme aus .

Also im Grunde Integrated Security=SSPI;ist seit Arbeiten mit beiden bevorzugt SQLClient& OleDBProvider.

Hier ist der vollständige Satz von Syntaxen gemäß MSDN - Connection String Syntax (ADO.NET)

— Pranav Singh
quelle

73

Verwenden der Windows-Authentifizierung

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

 Integrated Security = true;
 Integrated Security = SSPI;

Allerdings funktioniert nur die zweite mit dem Datenprovider .NET Framework OleDb . Wenn Sie Integrated Security = trueConnectionString festlegen, wird eine Ausnahme ausgelöst.

So legen Sie die Windows-Authentifizierung im Datenprovider fest NET Framework für ODBC sollten Sie das folgende Schlüssel-Wert-Paar verwenden.

Trusted_Connection = yes;

Quelle: MSDN: Arbeiten mit Verbindungszeichenfolgen

— Asereware
quelle

33

Viele Fragen erhalten Antworten, wenn wir .Net Reflectorden tatsächlichen Code von SqlConnection:) sehen trueund sspisind die gleichen:

internal class DbConnectionOptions

...

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

...

EDIT 20.02.2018 Jetzt in .Net Core können wir seine Open Source auf Github sehen! Suchen Sie nach der ConvertValueToIntegratedSecurityInternal-Methode:

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

— Pavel Biryukov
quelle

2

Dieser Teil des Codes ist nur für einen Fall Eigentum, der durch den Namen erklärt werden kann ConvertValueToIntegratedSecurityInternal. Diese Eigenschaft wird nur verwendet, wenn der Anbieter SqlClientdies tut SqlClientund SSPI& trueidentisch ist, jedoch nicht, wenn der Client OleDboder ist OracleClient. Ich habe klargestellt, dass in stackoverflow.com/a/23637478/704008 mit msdn Referenz

— Pranav Singh

Stimmen Sie hier für Pranavs Grund ab.

— Scott

21

Integrierte Sicherheit = Falsch: Benutzer-ID und Kennwort werden in der Verbindung angegeben. Integrierte Sicherheit = true: Die aktuellen Anmeldeinformationen des Windows-Kontos werden zur Authentifizierung verwendet.

Integrierte Sicherheit = SSPI: Dies entspricht true.

Wir können die Attribute für Benutzername und Kennwort aus der Verbindungszeichenfolge vermeiden und die integrierte Sicherheit verwenden

— NITIN KAUSHIK
quelle

13

Lass mich anfangen mit Integrated Security = false

false Benutzer-ID und Kennwort werden in der Verbindungszeichenfolge angegeben.
true Die Anmeldeinformationen des Windows-Kontos werden zur Authentifizierung verwendet.

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

Wenn User IDund Passwordangegeben sind und Integrierte Sicherheit auf gesetzt ist true, wird User IDund Passwordignoriert und Integrierte Sicherheit verwendet

— Kudlatiger
quelle

7

Beachten Sie, dass Verbindungszeichenfolgen spezifisch dafür sind, was und wie Sie eine Verbindung zu Daten herstellen. Diese stellen eine Verbindung zu derselben Datenbank her, aber die erste verwendet .NET Framework Data Provider für SQL Server. Integrierte Sicherheit = True funktioniert nicht für OleDb.

Datenquelle =.; Erstkatalog = aspnetdb; Integrierte Sicherheit = True
Provider = SQLOLEDB; Datenquelle =.; Integrierte Sicherheit = SSPI; Erstkatalog = aspnetdb

Verwenden Sie im Zweifelsfall die Datenverbindungen von Visual Studio Server Explorer.

Was ist sspi ?
Syntax der Verbindungszeichenfolgen

— user1874524
quelle

5

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

— Amit Shishodia
quelle

social.msdn.microsoft.com/Forums/en-US/…

— Amit Shishodia

2

Aus meiner Sicht,

Wenn Sie Integrated Security = SSPI nicht verwenden, müssen Sie den Benutzernamen und das Kennwort in der Verbindungszeichenfolge fest codieren. Dies bedeutet "relativ unsicher", da alle Mitarbeiter Zugriff haben, auch wenn ein ehemaliger Mitarbeiter die Informationen böswillig verwenden könnte.

— Sathishkumar
quelle

1

Die Verbindungszeichenfolge ist für keinen Mitarbeiter unbedingt sichtbar.

— underscore_d