#c# #.net #asp.net #sql-server-2005 #ado.net
#c# #.net #asp.net #sql-server-2005 #ado.net
Вопрос:
Если в строке подключения указан Trusted_Connection=true режим аутентификации SQL Server, повлияет ли это на производительность моего веб-приложения?
Ответ №1:
Не уверен на 100%, что вы имеете в виду:
Trusted_Connection=True;
Использует учетные данные Windows и на 100% эквивалентно:
Integrated Security=SSPI;
или
Integrated Security=true;
Если вы не хотите использовать интегрированную безопасность / доверенное соединение, вам необходимо явно указать идентификатор пользователя и пароль в строке подключения (и исключить любую ссылку на Trusted_Connection или Integrated Security )
server=yourservername;database=yourdatabase;user id=YourUser;pwd=TopSecret
Только в этом случае используется режим аутентификации SQL Server.
Если присутствует какой-либо из этих двух параметров ( Trusted_Connection=true или Integrated Security=true/SSPI ), то для аутентификации на SQL Server используются учетные данные Windows текущего пользователя, и любой user iD= параметр будет проигнорирован и не будет использоваться.
Для справки см. сайт Строк подключения к SQL Server 2005 с множеством примеров и пояснений.
Предпочтительным и рекомендуемым способом выполнения операций является использование аутентификации Windows, но это может привести к небольшой задержке, поскольку SQL Server должен будет проверять подлинность ваших учетных данных в Active Directory (обычно). Я понятия не имею, насколько велика может быть эта небольшая задержка, и я не нашел никаких ссылок на это.
Подводя итог:
Если вы укажете либо Trusted_Connection=True; , либо Integrated Security=SSPI; , либо Integrated Security=true; в строке подключения
==> ТОГДА (и только тогда) происходит проверка подлинности Windows. Любые user id= настройки в строке подключения будут проигнорированы.
Если вы НЕ укажете ни один из этих параметров,
==> тогда у вас НЕ выполняется проверка подлинности Windows (будет использоваться режим проверки подлинности SQL)
Комментарии:
1. Вы имеете в виду, что если я использую аутентификацию SQL Server, отличную от аутентификации Windows, я не могу использовать Trusted_Connection=true?
2. Извините, я имею в виду, что если я хочу использовать Trusted_connection = true, то я должен использовать режим аутентификации Windows? Могу ли я использовать режим аутентификации SQL Server с Trusted_connection = true?
3. Марк, я хочу подтвердить тебе, что 1. если я использую режим аутентификации SQL Server, то я не могу использовать Trusted_connection = true, 2. если я использую режим аутентификации Windows, то я могу выбрать, использовать Trusted_connection = true или нет?
4. 1.) ДА, 2.) НЕТ — trusted_connection= true означает проверку подлинности Windows, а для проверки подлинности Windows требуется Trusted_Connection=true. Если вы укажете «trusted_connection=True» ==> у вас установлена аутентификация Windows; если вы ее не укажете, у вас не установлена аутентификация Windows
5. Вы имеете в виду, что если я использую аутентификацию Windows, я должен использовать trusted_connection= True? У меня возникла эта путаница, потому что я использую аутентификацию Windows в одном из своих проектов и одновременно не указываю trusted_connection = True. 🙂
Ответ №2:
При использовании доверенных подключений имя пользователя и пароль игнорируются, поскольку SQL Server использует аутентификацию Windows.
Комментарии:
1. Вы имеете в виду, что если я использую аутентификацию SQL Server, отличную от аутентификации Windows, я не могу использовать Trusted_Connection=true?
2. Если вы используете доверенное соединение, Sql Server не заботится об идентификаторе пользователя и пароле, указанных в строке подключения. Sql Server использует учетные данные текущего процесса. Если вы хотите использовать аутентификацию Sql Server, вы должны удалить доверенное соединение из строки подключения
3. Спасибо! Если я не нахожусь в среде на основе active directory, возможно ли использовать Trusted_connection = true?
4. Вы не можете использовать доверенное соединение с аутентификацией Sql Server. Они являются взаимоисключающими.
5. Нет. Нет различий между AD, локальной учетной записью пользователя или домашней группой.
Ответ №3:
Вероятно, это приведет к некоторым потерям производительности при создании соединения, но поскольку соединения объединены в пул, они создаются только один раз, а затем используются повторно, поэтому для вашего приложения это не будет иметь никакого значения. Но, как всегда: измерьте это.
Обновить:
Существует два режима аутентификации:
- Режим проверки подлинности Windows (соответствующий доверенному соединению). Клиенты должны быть членами домена.
- Режим аутентификации SQL Server. Клиенты отправляют имя пользователя / пароль при каждом подключении
Комментарии:
1. Вы имеете в виду, что при первом установлении соединения с SQL Server будут дополнительные затраты на производительность? И почему? (мое предыдущее понимание заключается в том, что доверенное соединение повысит производительность, поскольку оно «надежное» — может сэкономить время, обойдя некоторые затраты на аутентификацию). Поправьте меня, если я ошибаюсь.
2. Да, но для того, чтобы стать
trusted, необходимо выполнить несколько обменов между клиентом и сервером. Установление квитирования SSPI будет происходить медленнее, чем однократная отправка имени пользователя / пароля туда и обратно.3. Кроме того, запрос Active Directory требует дополнительных затрат.
4.
Trusted_Connection=True;означает аутентификацию Windows.5. А аутентификация Windows означает Active Directory.
Ответ №4:
Если ваше веб-приложение настроено на выдачу себя за клиента, то использование доверенного соединения потенциально окажет негативное влияние на производительность. Это связано с тем, что каждый клиент должен использовать другой пул соединений (с учетными данными клиента).
Большинство веб-приложений не используют олицетворение / делегирование и, следовательно, не имеют этой проблемы.
Смотрите эту статью MSDN для получения дополнительной информации.