Tengo dos aplicaciones que usan seguridad integrada. Uno asigna Integrated Security = true en la cadena de conexión, y el otro establece Integrated Security = SSPI.Diferencia entre seguridad integrada = Seguridad verdadera e integrada = SSPI
¿Cuál es la diferencia entre SSPI y true en el contexto de la seguridad integrada?
De acuerdo con Microsoft son lo mismo.
Cuando
false, el ID de usuario y la contraseña se especifican en la conexión. Cuando es verdadero, las credenciales actuales de la cuenta de Windows se usan para la autenticación.
valores reconocidos sontrue,false,yes,no, y (muy recomendable), que es equivalente atrue.
Originalmente, creo que había una diferencia en que NTLM "verdadero" y "SSPI" usaban Kerberos, pero ahora son intercambiables. – SqlRyan
Gracias por la respuesta. ¿Alguna razón por la que funciona con una y no la otra? De hecho, si lo recuerdo correctamente, el error que obtuve cuando utilicé "verdadero" fue sobre algún controlador (en un servidor de Windows 2003 con SQL Server Express). JD. –
No revisé el último comentario, pero si es verdadero, debería ser una respuesta, pero no el comentario –
Empezaré con Integrated Security = false
false ID de usuario y contraseña se especifican en la cadena de conexión.
true Las credenciales de cuenta de Windows se utilizan para la autenticación.
valores reconocidos son true, false, yes, no, y SSPI.
Si User ID y Password se especifican y seguridad integrada se ajusta a true, entonces User ID y Password serán ignorados y seguridad integrada se utilizará
Uso de la autenticación de Windows
Para conectarse a la Se recomienda utilizar el servidor de base de datos para usar la Autenticación de Windows, comúnmente conocida como seguridad integrada. Para especificar la autenticación de Windows, puede usar cualquiera de los siguientes dos pares clave-valor con el proveedor de datos. NET Framework para SQL Server:
Integrated Security = true;
Integrated Security = SSPI;
Sin embargo, sólo el segundo trabaja con el proveedor de datos de .NET Framework OleDb. Si establece Integrated Security = true para ConnectionString, se lanza una excepción.
Para especificar la autenticación de Windows en el proveedor de datos. NET Framework para ODBC, debe usar el siguiente par clave-valor.
Trusted_Connection = yes;
gracias, obtenía un extraño error en un script VBS con '= true', cambiándolo a' = SSPI' lo arreglaba. –
Integrado de Seguridad = False: ID de usuario y contraseña se especifican en la conexión. Seguridad integrada = verdadera: las credenciales actuales de la cuenta de Windows se usan para la autenticación.
Seguridad integrada = SSPI: esto es equivalente a verdadero.
Podemos evitar el nombre de usuario y contraseña de los atributos de la cadena de conexión y utilizar la seguridad integrada
Muchas preguntas obtener respuestas si usamos .Net Reflector para ver el código real de SqlConnection :) true y son los mismos:
internal class DbConnectionOptions
...
internal bool ConvertValueToIntegratedSecurityInternal(string stringValue)
{
if ((CompareInsensitiveInvariant(stringValue, "sspi") || CompareInsensitiveInvariant(stringValue, "true")) || CompareInsensitiveInvariant(stringValue, "yes"))
{
return true;
}
}
...
EDITAR 20/02/2018 Ahora en .Net Core podemos ver su código abierto en github! método de búsqueda de ConvertValueToIntegratedSecurityInternal:
Tenga en cuenta que las cadenas de conexión son específicos de lo y cómo se está conectando a los datos. Estos se están conectando a la misma base de datos, pero el primero es usar .NET Framework Data Provider para SQL Server. Integrated Security = True no funcionará para OleDb.
En caso de duda use las conexiones de datos de Visual Studio Server Explorer.
+1 para el enlace informativo de msdn. –
Integrated Security=true; no funciona en todos los proveedores de SQL, se produce una excepción cuando se utiliza con el proveedor OleDb.
Así que básicamente se prefiere Integrated Security=SSPI; ya que funciona con el proveedor SQLClient & OleDB.
Aquí está el conjunto completo de sintaxis según MSDN - Connection String Syntax (ADO.NET)
Gracias por eso Mucho, esto realmente me molestaba ya que mi cadena de conexión SQL .net no funcionaba cuando lo usé para un paquete DTSX. Cambié True por SSPI y funcionó. Tu respuesta explica por qué, y la respuesta aceptada no funciona. – zeocrash
verdadera sólo es válida si está utilizando la biblioteca .NET SqlClient. No es válido cuando se usa OLEDB. Donde SSPI es bvaid en ambos está utilizando .net SqlClient library o OLEDB.
https://social.msdn.microsoft.com/Forums/en-US/b61c092b-48c8-4bc7-b26b-47b41ea72b69/is-there-a-difference-bt-integrated-security-true-and-integrated-security -sspi? forum = adodotnetdataproviders –
En mi punto de vista,
Si no utiliza seguridad integrada = SSPI, entonces usted necesita para codificar el nombre de usuario y contraseña en la cadena de conexión que significa "relativamente inseguros" por qué, porque, todos los empleados tienen la acceso incluso ex empleado podría utilizar la información maliciosamente.
La cadena de conexión no es necesariamente visible para ningún empleado. –
La respuesta aceptada no es la mejor, tampoco es totalmente correcta. 'Integrated Security = True' o' SSPI' no son las mismas. 'Integrated Security = true;' no funciona en todos los proveedores SQL, arroja una excepción cuando se usa con el proveedor 'OleDb'. Así que básicamente 'Integrated Security = SSPI;' es preferible ya que funciona con el proveedor 'SQLClient' y' OleDB'.He agregado una respuesta para una mejor aclaración. –
@PranavSingh tiene la idea correcta, esta pregunta está incompleta a menos que especifique qué _proveedor_ está utilizando. Diferentes proveedores aceptan y/o traducen varias cadenas en estados internos. – Mark
Aunque son lo mismo, creo que había un documento muy antiguo en uno de los sitios web, en el momento en que tenía curiosidad por ti, que decía si estás desarrollando para Windows Mobile (no lo que ves hoy, los dispositivos antiguos que no recuerdo el sufijo de OS ya que nunca tuve uno), debe usar SSPI y Contraseña de usuario juntos. pero como nunca escribí uno, y no recuerdo el origen de ese documento, no puedo garantizarlo. – deadManN