Quelle est la différence entre Integrated Security = True et Integrated Security = SSPI?

531

J'ai deux applications qui utilisent la sécurité intégrée. L'un affecte Integrated Security = truedans la chaîne de connexion et les autres ensembles Integrated Security = SSPI.

Quelle est la différence entre SSPIet truedans le contexte de la sécurité intégrée?

JD.
la source
70
La réponse acceptée n'est pas la meilleure, elle n'est pas non plus entièrement correcte. Integrated Security = Trueou SSPIne sont pas les mêmes. Integrated Security=true;ne fonctionne pas dans tous les fournisseurs SQL, il lève une exception lorsqu'il est utilisé avec le OleDbfournisseur. Donc , fondamentalement , Integrated Security=SSPI;est préférée car fonctionne aussi bien avec SQLClientet OleDBfournisseur. J'ai ajouté une réponse pour une meilleure clarification.
Pranav Singh
3
@PranavSingh a la bonne idée, cette question est incomplète sauf si vous spécifiez le fournisseur que vous utilisez. Différents fournisseurs acceptent et / ou traduisent diverses chaînes de caractères en états internes.
Mark
Bien qu'ils soient identiques, je pense qu'il y avait un très vieux document dans l'un des sites Web, à l'époque j'étais curieux comme vous, qui disait que si vous développez pour Windows Mobile (pas ce que vous voyez aujourd'hui, les anciens appareils que je ne me souviens pas du suffixe du système d'exploitation car je n'en ai jamais eu), vous devez utiliser SSPI et le mot de passe utilisateur ensemble. mais comme je n'en ai jamais écrit et que je ne me souviens pas de la source de ce document, je ne peux pas le garantir.
deadManN

Réponses:

436

Selon Microsoft, c'est la même chose.

Quand false, l'ID utilisateur et le mot de passe sont spécifiés dans la connexion. Lorsque la valeur est true, les informations d'identification de compte Windows actuelles sont utilisées pour l'authentification.
Les valeurs reconnues sont true, false, yes, noet sspi(fortement recommandé), ce qui équivaut à true.

cptScarlet
la source
28
À l'origine, je pense qu'il y avait une différence dans le fait que "True" utilisait NTLM et "SSPI" utilisait Kerberos, mais ils sont maintenant interchangeables.
SqlRyan
5
N'a pas vérifié le dernier commentaire, mais s'il est vrai, devrait être la réponse, mais pas le commentaire
Johnny_D
20
@RodneyFoley désolé, mes tests confirment que cette réponse est correcte et votre commentaire ne l'est pas. Peut-être que cela a fonctionné de cette façon une fois, mais ce n'est pas le cas maintenant, et vous ne pouvez fournir aucune référence à un document Microsoft qui prend en charge votre opinion.
Kirk Broadhurst
3
D'accord avec Kirk. L'utilisateur / mot de passe est ignoré lorsque SSPI est spécifié - .net 4.0, SQL server 2012.
Alex des Pelagos
3
Alors s'ils "sont la même chose" pourquoi le SSPI "est-il fortement recommandé" plutôt que "vrai" ou "oui? C'est la raison pour laquelle je suis venu à cette question ...
Zé Carlos
171

Integrated Security=true;ne fonctionne pas dans tous les fournisseurs SQL, il lève une exception lorsqu'il est utilisé avec le OleDbfournisseur.

Donc , fondamentalement , Integrated Security=SSPI;est préférée car fonctionne aussi bien avec SQLClientet OleDBfournisseur.

Voici l'ensemble complet des syntaxes selon MSDN - Syntaxe de chaîne de connexion (ADO.NET)

! [Syntaxe d'authentification Windows

Pranav Singh
la source
73

Utilisation de l'authentification Windows

Pour se connecter au serveur de base de données, il est recommandé d'utiliser l'authentification Windows, communément appelée sécurité intégrée. Pour spécifier l'authentification Windows, vous pouvez utiliser l'une des deux paires clé-valeur suivantes avec le fournisseur de données. NET Framework pour SQL Server:

 Integrated Security = true;
 Integrated Security = SSPI;

Cependant, seul le second fonctionne avec le fournisseur de données .NET Framework OleDb . Si vous définissez Integrated Security = trueConnectionString, une exception est levée.

Pour spécifier l'authentification Windows dans le fournisseur de données. NET Framework pour ODBC, vous devez utiliser la paire clé-valeur suivante.

Trusted_Connection = yes;

Source: MSDN: utilisation des chaînes de connexion

Asereware
la source
33

De nombreuses questions obtiennent des réponses si nous utilisons .Net Reflectorpour voir le code réel de SqlConnection:) trueet sspisont les mêmes:

internal class DbConnectionOptions

...

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

...

EDIT 20.02.2018 Maintenant dans .Net Core, nous pouvons voir son open source sur github! Recherchez la méthode ConvertValueToIntegratedSecurityInternal:

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

Pavel Biryukov
la source
2
Cette partie du code n'est la propriété que pour un cas qui peut être expliqué par son nom ConvertValueToIntegratedSecurityInternal. Cette propriété est utilisée uniquement lorsque le fournisseur est SqlClientdonc dans SqlClient, SSPIet truesont les mêmes , mais pas lorsque le client est OleDbou OracleClient. J'ai précisé que dans stackoverflow.com/a/23637478/704008 avec référence msdn
Pranav Singh
Votez pour la raison de Pranav ici.
Scott
21

Sécurité intégrée = Faux: l'ID utilisateur et le mot de passe sont spécifiés dans la connexion. Sécurité intégrée = vrai: les informations d'identification du compte Windows actuel sont utilisées pour l'authentification.

Sécurité intégrée = SSPI: c'est équivalent à vrai.

Nous pouvons éviter les attributs de nom d'utilisateur et de mot de passe de la chaîne de connexion et utiliser la sécurité intégrée

NITIN KAUSHIK
la source
13

Permettez-moi de commencer par Integrated Security = false

false L'ID utilisateur et le mot de passe sont spécifiés dans la chaîne de connexion.
true Les informations d'identification du compte Windows sont utilisées pour l'authentification.

Les valeurs reconnues sont true, false, yes, noet SSPI.

Si User IDet Passwordsont spécifiés et que la sécurité intégrée est définie sur true, alors User IDet Passwordsera ignoré et la sécurité intégrée sera utilisée

kudlatiger
la source
7

Notez que les chaînes de connexion sont spécifiques à quoi et comment vous vous connectez aux données. Ceux-ci se connectent à la même base de données, mais le premier utilise le fournisseur de données .NET Framework pour SQL Server. Integrated Security = True ne fonctionnera pas pour OleDb.

  • Source de données = .; Catalogue initial = aspnetdb; Sécurité intégrée = True
  • Fournisseur = SQLOLEDB; Source de données = .; Sécurité intégrée = SSPI; Catalogue initial = aspnetdb

En cas de doute, utilisez les connexions de données de Visual Studio Server Explorer.

user1874524
la source
5

True n'est valide que si vous utilisez la bibliothèque .NET SqlClient. Il n'est pas valide lors de l'utilisation d'OLEDB. Lorsque SSPI est bvaid dans les deux cas, vous utilisez la bibliothèque .net SqlClient ou OLEDB.

Amit Shishodia
la source
2

De mon point de vue,

Si vous n'utilisez pas Integrated security = SSPI, vous devez coder en dur le nom d'utilisateur et le mot de passe dans la chaîne de connexion, ce qui signifie "relativement peu sûr" pourquoi, car tous les employés ont accès, même les anciens employés pourraient utiliser les informations de manière malveillante.

Sathishkumar
la source
1
La chaîne de connexion n'est pas nécessairement visible pour aucun employé.
underscore_d