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

J’ai deux applications qui utilisent la sécurité intégrée. L’un affecte Integrated Security = true dans la chaîne de connexion et l’autre définit Integrated Security = SSPI .

Quelle est la différence entre SSPI et true dans le contexte de la sécurité intégrée?

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

Lorsque la valeur est 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 du compte Windows actuelles sont utilisées pour l’authentification.
Les valeurs reconnues sont true , false , yes , no et sspi (fortement recommandé), ce qui équivaut à true .

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

Donc, fondamentalement, Integrated Security=SSPI; est préférable car fonctionne avec les deux fournisseurs SQLClient et OleDB .

Voici l’ensemble des syntaxes selon MSDN – Syntaxe de la chaîne de connexion (ADO.NET)

Syntaxe d'authentification Windows

Utiliser l’authentification Windows

Pour se connecter au serveur de firebase database, 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, seule la seconde fonctionne avec le fournisseur de données .NET Framework OleDb . Si vous définissez Integrated Security = true pour ConnectionSsortingng, 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: Travailler avec des chaînes de connexion

De nombreuses questions obtiennent des réponses si nous utilisons .Net Reflector pour voir le code réel de SqlConnection 🙂 true et sspi sont les mêmes:

 internal class DbConnectionOptions ... internal bool ConvertValueToIntegratedSecurityInternal(ssortingng ssortingngValue) { if ((CompareInsensitiveInvariant(ssortingngValue, "sspi") || CompareInsensitiveInvariant(ssortingngValue, "true")) || CompareInsensitiveInvariant(ssortingngValue, "yes")) { return true; } } ... 

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

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

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

Sécurité intégrée = SSPI: cela équivaut à vrai.

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

Commençons 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 , no et SSPI .

Si User ID et le Password sont spécifiés et que la sécurité intégrée est définie sur true , User ID et le Password seront ignorés et la sécurité intégrée sera utilisée

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

  • Source de données =; Initial Catalog = aspnetdb; Integrated Security = 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.

  • Qu’est ce que c’est SSPI ?
  • Syntaxe des chaînes de connexion

True n’est valide que si vous utilisez la bibliothèque .NET SqlClient. Il n’est pas valide lorsque vous utilisez OLEDB. Où SSPI est bvaid dans les deux soit vous utilisez la bibliothèque .net SqlClient ou OLEDB.

De mon sharepoint 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”. Parce que tous les employés peuvent accéder aux informations de manière malveillante.