Qual é a diferença entre segurança integrada = true e segurança integrada = sspi?

StackOverflow https://stackoverflow.com/questions/1229691

Pergunta

Eu tenho dois aplicativos que usam segurança integrada. Um atribui Integrated Security = true na string de conexão e os outros conjuntos Integrated Security = SSPI.

Qual é a diferença entre SSPI e true No contexto da segurança integrada?

Foi útil?

Solução

De acordo com Microsoft Eles são a mesma coisa.

Quando false, ID do usuário e senha são especificados na conexão. Quando é verdade, as credenciais atuais da conta do Windows são usadas para autenticação.
Os valores reconhecidos são true, false, yes, no, e sspi (fortemente recomendado), que é equivalente a true.

Outras dicas

Integrated Security=true; não funciona em todos os provedores de SQL, ele joga uma exceção quando usado com o OleDb fornecedor.

Então, basicamente Integrated Security=SSPI; é preferido, pois funciona com ambos SQLClient & OleDB fornecedor.

Aqui está o conjunto completo de sintaxes de acordo com MSDN - Sintaxe da string de conexão (ADO.NET)

![Windows Auth Syntax

Usando a autenticação do Windows

Recomenda -se conectar -se ao servidor de banco de dados para usar a autenticação do Windows, comumente conhecida como segurança integrada. Para especificar a autenticação do Windows, você pode usar qualquer um dos dois pares de valor-chave a seguir com o provedor de dados. Framework Net para SQL Server:

 Integrated Security = true;
 Integrated Security = SSPI;

No entanto, apenas o segundo trabalha com o provedor de dados .NET Framework OLEDB. Se você definir Integrated Security = true Para o ConnectionString, uma exceção é lançada.

Para especificar a autenticação do Windows no provedor de dados. Framework Net para ODBC, você deve usar o seguinte par de valor-chave.

Trusted_Connection = yes;

Fonte: MSDN: Trabalhando com strings de conexão

Muitas perguntas recebem respostas se usarmos .Net Reflector Para ver o código real de SqlConnection :) true e sspi são os mesmos:

internal class DbConnectionOptions

...

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

...

Editar 20.02.2018Agora, no .NET Core, podemos ver seu código aberto no Github! Pesquise o método ConvertValuEteGreatedSecurityInternal:

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

Segurança integrada = false: ID do usuário e senha são especificados na conexão. Segurança integrada = true: As credenciais atuais da conta do Windows são usadas para autenticação.

Segurança integrada = sspi: isso é equivalente a verdadeiro.

Podemos evitar os atributos de nome de usuário e senha da string de conexão e usar a segurança integrada

Deixe -me começar com Integrated Security = false

false O ID do usuário e a senha são especificados na string de conexão.
true As credenciais da conta do Windows são usadas para autenticação.

Os valores reconhecidos são true, false, yes, no, e SSPI.

Se User ID e Password são especificados e a segurança integrada está definida como true, então User ID e Password será ignorado e a segurança integrada será usada

Observe que as seqüências de conexão são específicas para o que e Como as você está se conectando aos dados. Eles estão se conectando ao mesmo banco de dados, mas o primeiro está usando o provedor de dados do .NET Framework para o SQL Server. Segurança integrada = true não funcionará para o OLEDB.

  • Fonte de dados =.; Catálogo inicial = aspnetdb; segurança integrada = true
  • Provedor = sqloledb; fonte de dados =.; Segurança integrada = sspi; catálogo inicial = aspnetdb

Em dúvida, use as conexões de dados do Visual Studio Server Explorer.

True é válido apenas se você estiver usando a biblioteca .NET SQLCLIENT. Não é válido ao usar OLEDB. Onde o SSPI é BVAID em ambos você está usando a biblioteca .NET SQLCLIENT ou OLEDB.

No meu ponto de vista,

Se você não usar segurança integrada = sspi, precisará codificar o nome de usuário e a senha na sequência de conexão, o que significa "relativamente inseguro" por que, porque, todos os funcionários têm o acesso até o ex-funcionário, pode usar as informações maliciosamente.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top