Qual é a diferença entre Segurança Integrada = Verdadeira e Segurança Integrada = SSPI?


531

Eu tenho dois aplicativos que usam a Segurança Integrada. Um atribui Integrated Security = truena cadeia de conexão e o outro define Integrated Security = SSPI.

Qual é a diferença entre SSPIe trueno contexto da Segurança Integrada?


70
A resposta aceita não é a melhor, também não é totalmente correta. Integrated Security = Trueou SSPInão são iguais. Integrated Security=true;não funciona em todos os provedores SQL, lança uma exceção quando usado com o OleDbprovedor. Então, basicamente Integrated Security=SSPI;é o preferido, pois trabalha com o SQLClient& OleDBprovider. Eu adicionei uma resposta para melhor esclarecimento.
Pranav Singh

3
O @PranavSingh tem a ideia certa; esta pergunta está incompleta, a menos que você especifique qual provedor está usando. Diferentes fornecedores aceitam e / ou convertem várias strings em estados internos.
Mark

Embora sejam iguais, acredito que havia um documento muito antigo em um dos sites, na época eu era curioso como você, que dizia que se você está desenvolvendo para Windows Mobile (não o que você vê hoje, os dispositivos antigos que eu não se lembra do sufixo do sistema operacional, pois nunca tive um), você deve usar o SSPI e a senha do usuário juntos. mas como nunca escrevi um e não me lembro da fonte desse documento, não posso garantir.
deadManN

Respostas:


436

Segundo a Microsoft, eles são a mesma coisa.

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


28
Originalmente, acho que havia uma diferença entre "True" usado NTLM e "SSPI" usado Kerberos, mas agora eles são intercambiáveis.
SqlRyan

5
Não verificar último comentário, mas se for verdade, deve ser como a resposta, mas não o comentário
Johnny_D

20
@RodneyFoley desculpe, meus testes confirmam que esta resposta está correta e que seu comentário não está. Talvez tenha funcionado dessa maneira uma vez, mas não funciona agora, e você não pode fornecer nenhuma referência a um documento da Microsoft que suporte sua opinião.
precisa saber é o seguinte

3
Concordo com Kirk. Usuário / senha é ignorado quando SSPI especificado - .net 4.0, servidor SQL 2012.
Alex des Pelagos

3
Então, se eles "são a mesma coisa" porque é SSPI "fortemente recomendado" em vez de "verdadeiro" ou "sim Essa é a razão pela qual eu vim para esta pergunta ...?
Zé Carlos

171

Integrated Security=true;não funciona em todos os provedores SQL, lança uma exceção quando usado com o OleDbprovedor.

Então, basicamente Integrated Security=SSPI;é o preferido, pois trabalha com o SQLClient& OleDBprovider.

Aqui está o conjunto completo de sintaxes de acordo com o MSDN - Sintaxe de seqüência de conexão (ADO.NET)

! [Sintaxe de autenticação do Windows


73

Usando autenticação do Windows

Para conectar-se ao servidor de banco de dados, é recomendável 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 valores-chave a seguir com o provedor de dados. NET Framework para SQL Server:

 Integrated Security = true;
 Integrated Security = SSPI;

No entanto, apenas o segundo funciona com o provedor de dados .NET Framework OleDb . Se você definir Integrated Security = truepara ConnectionString, uma exceção será lançada.

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

Trusted_Connection = yes;

Fonte: MSDN: Trabalhando com seqüências de conexão


33

Muitas perguntas obtêm respostas se usarmos .Net Reflectorpara ver o código real de SqlConnection:) truee sspisão as mesmas:

internal class DbConnectionOptions

...

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

...

EDIT 20.02.2018 Agora, no .Net Core, podemos ver seu código aberto no github! Procure pelo método ConvertValueToIntegratedSecurityInternal:

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


2
Essa parte do código é propriedade apenas para um caso explicável por nome ConvertValueToIntegratedSecurityInternal. Essa propriedade é usada somente quando provedor está no SqlClientmodo em SqlClient, SSPIe truesão os mesmos, mas não quando o cliente é OleDbou OracleClient. Eu esclarei que no stackoverflow.com/a/23637478/704008 com referência de msdn
Pranav Singh

Voto negativo pela razão de Pranav aqui.
Scott

21

Segurança Integrada = Falso: 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 cadeia de conexão e usar o Integrated Security


13

Deixe-me começar com Integrated Security = false

false O ID do usuário e a senha são especificados na cadeia 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, eSSPI .

Se User IDe Passwordsão especificados e segurança integrada está definida para true, em seguida, User IDe Passwordserá ignorado e Segurança Integrada será usado


7

Observe que as cadeias de conexão são específicas para o que e como você está se conectando aos dados. Eles estão se conectando ao mesmo banco de dados, mas o primeiro está usando o .NET Framework Data Provider para SQL Server. Segurança Integrada = True não funcionará para o OleDb.

  • Fonte de dados = .; Catálogo inicial = aspnetdb; Segurança integrada = True
  • Fornecedor = SQLOLEDB; Fonte de Dados = .; Segurança Integrada = SSPI; Catálogo Inicial = aspnetdb

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



2

No meu ponto de vista,

Se você não usar o Integrated security = SSPI, precisará codificar o nome de usuário e a senha na cadeia de conexão, o que significa "relativamente inseguro" porque, porque todos os funcionários têm acesso, mesmo que ex-funcionários possam usar as informações de maneira maliciosa.


1
A cadeia de conexão não é necessariamente visível para nenhum funcionário.
Sublinhado #
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.