Quelle est la différence entre Integrated Security = True et Integrated Security = SSPI?
-
22-07-2019 - |
Question
J'ai deux applications qui utilisent Integrated Security. L'une attribue Integrated Security = true
à la chaîne de connexion et l'autre ensembles Integrated Security = SSPI
.
Quelle est la différence entre SSPI
et true
dans le contexte de la sécurité intégrée?
La solution
Selon Microsoft , ils sont la même chose.
Lorsque
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 actuel sont utilisées pour l'authentification.
Les valeurs reconnues sontvrai
,faux
,oui
,non
etsspi
(fortement recommandé), ce qui équivaut àtrue
.
Autres conseils
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 à la fois avec SQLClient
& amp; fournisseur OleDB
.
Voici l'ensemble des syntaxes selon MSDN - Syntaxe des chaînes de connexion (ADO.NET)
Utilisation de l'authentification Windows
Pour vous 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 = true
pour ConnectionString, 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;
De nombreuses questions obtiennent des réponses si nous utilisons .Net Reflector
pour afficher le code actuel de SqlConnection
:)
true
et sspi
sont identiques:
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 code source ouvert sur github! Recherchez la méthode ConvertValueToIntegratedSecurityInternal:
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 vrai
, faux
, oui
, non
et SSPI
.
Si ID utilisateur
et Mot de passe
sont spécifiés et que Sécurité intégrée est défini sur true
, puis ID utilisateur
et Mot de passe
sera ignoré 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 la première utilise le fournisseur de données .NET Framework pour SQL Server. Sécurité intégrée = 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 Visual Studio Server Explorer.
- Qu'est-ce que sspi ?
- Syntaxe des chaînes de connexion
True n'est valide que si vous utilisez la bibliothèque .NET SqlClient. Ce n'est pas valable lorsque vous utilisez OLEDB. Où SSPI est bvaid dans les deux cas, vous utilisez la bibliothèque .net SqlClient ou OLEDB.
À mon avis,
Si vous n'utilisez pas la sécurité intégrée = 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écurisé". pourquoi, parce que tous les employés ont accès, même les ex-employés peuvent utiliser les informations de manière malveillante.