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

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

donc fondamentalement Integrated Security=SSPI; est préférable car fonctionne à la fois avec SQLClient et OleDB fournisseur.

voici le jeu complet de syntaxes selon MSDN - syntaxe de chaîne de connexion (ADO.NET)

Utilisant L'Authentification Windows

pour se connecter au serveur de base de données est recommandé d'utiliser L'authentification Windows, généralement connu sous le nom de sécurité intégrée. Pour spécifier l'authentification Windows, vous pouvez utiliser l'une des deux paires clé-valeur avec le fournisseur de données. Cadre NET pour le serveur SQL:

 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 = true pour la chaîne de connexion, une exception est lancée.

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

Trusted_Connection = yes;

Source: MSDN: travailler avec des chaînes de connexion

plusieurs 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(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! Recherche de Convertvaluetointegrated Security Internal method:

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

sécurité intégrée = False : ID utilisateur et mot de passe sont spécifiés dans la connexion. Sécurité intégrée = true : les identifiants de compte Windows actuels sont utilisés pour l'authentification.

Integrated Security = SSPI : ceci est équivalent à true.

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

commençons par Integrated Security = false

false le nom D'Utilisateur et le mot de passe sont spécifiés dans la chaîne de connexion.

true les justificatifs D'identité de Compte Windows sont utilisés pour l'authentification.

les valeurs reconnues sont true , false , yes , no , et SSPI .

si User ID et Password sont spécifiés et la sécurité intégrée est définie à true , puis User ID et 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. Ceux-ci se connectent à la même base de données, mais le premier utilise .NET Framework Data Provider pour SQL Server. Integrated Security=True ne fonctionnera pas pour OleDb.

• Source De Données=.; Catalogue Initial = aspnetdb;sécurité intégrée =True
• Provider=SQLOLEDB; Data Source=.;Intégré Sécurité=SSPI; catalogue Initial = aspnetdb

en cas de doute utiliser les connexions de données Visual Studio Explorer.

• Qu'est-ce que sspi ?
• Syntaxe Des Chaînes De Connexion

True n'est valide que si vous utilisez la bibliothèque SqlClient. Il n'est pas valide en cas d'utilisation D'OLEDB. Où SSPI est bvaid dans les deux, soit vous utilisez la bibliothèque SqlClient. net, soit OLEDB.

, À mon point de vue,

si vous n'utilisez pas Integrated security=SSPI,alors vous avez besoin de hardcode le nom d'utilisateur et le mot de passe dans la chaîne de connexion qui signifie" relativement peu sûr " pourquoi parce que, tous les employés ont l'accès même l'ex-employé pourrait utiliser l'information maliciously.