В чем разница между Integrated Security = True и Integrated Security = SSPI?

у меня есть два приложения, которые используют интегрированную систему безопасности. Один назначает Integrated Security = true в строке подключения, а другие наборы Integrated Security = SSPI.

в чем разница между SSPI и true в контексте комплексной безопасности?

9 ответов


по данным Microsoft это одно и то же.

, когда false, ID пользователя и пароль указаны в соединении. При значении true для проверки подлинности используются текущие учетные данные учетной записи Windows.
Распознанные значения:true, false, yes, no и sspi (настоятельно рекомендуется), что эквивалентно true.


Integrated Security=true; не работает во всех поставщиках SQL, он создает исключение при использовании с OleDb провайдер.

так что в принципе Integrated Security=SSPI; предпочтительнее, так как работает с SQLClient & OleDB провайдер.

вот полный набор синтаксисов в соответствии с MSDN-синтаксис строки подключения (ADO.NET)

![Windows Auth Syntax


Использование Проверки Подлинности Windows

для подключения к серверу баз данных рекомендуется использовать проверку подлинности Windows, обычно известную как встроенная безопасность. Чтобы указать проверку подлинности Windows, можно использовать любую из следующих двух пар ключ-значение с поставщиком данных. NET Framework для SQL Server:

 Integrated Security = true;
 Integrated Security = SSPI;

однако только второй работает с поставщиком данных .NET Framework OleDb. Если вы установите Integrated Security = true для ConnectionString создается исключение.

для указания проверки подлинности Windows в поставщике данных. NET Framework для ODBC следует использовать следующую пару ключ-значение.

Trusted_Connection = yes;

источник: MSDN: работа со строками подключения


многие вопросы получают ответы, если мы используем .Net Reflector чтобы увидеть фактический код SqlConnection :) true и sspi то же самое:

internal class DbConnectionOptions

...

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

...

изменить 20.02.2018 Теперь в .Net Core мы можем увидеть его с открытым исходным кодом на github! Поиск ConvertValueToIntegratedSecurityinternal метод:

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


Integrated Security = False: идентификатор пользователя и пароль указаны в соединении. Integrated Security = true: текущие учетные данные учетной записи Windows используются для проверки подлинности.

Integrated Security = SSPI: это эквивалентно true.

мы можем избежать атрибутов имени пользователя и пароля из строки подключения и использовать интегрированную безопасность


позвольте мне начать с Integrated Security = false

false идентификатор пользователя и пароль в строке подключения.
true учетные данные учетной записи Windows используются для проверки подлинности.

признан значения true, false, yes, no и SSPI.

если User ID и и комплексной безопасности true, потом User ID и Password будет проигнорировано и интегрировано Безопасность будет использоваться


обратите внимание, что строки подключения относятся к что и как вы подключаетесь к данным. Они подключаются к той же базе данных, но первый использует поставщик данных .NET Framework для SQL Server. Интегрированная безопасность=True не будет работать для OleDb.

  • Источник Данных=.; Initial Catalog=aspnetdb; Integrated Security=True
  • Provider=SQLOLEDB; источник данных=.;Комплексная безопасность=SSPI;начальная Каталог=aspnetdb

Если вы сомневаетесь, используйте подключения к данным Visual Studio Server Explorer.


True допустимо только при использовании библиотеки .NET SqlClient. Это недопустимо при использовании OLEDB. Где SSPI bvaid в обоих вы используете библиотеку .net SqlClient или OLEDB.


с моей точки зрения,

Если вы не используете Integrated security=SSPI, то вам нужно жестко закодировать имя пользователя и пароль в строке подключения, что означает "относительно небезопасно", потому что все сотрудники имеют доступ, даже бывший сотрудник может использовать информацию злонамеренно.