Как увидеть строку подключения, используемую для подключения к SQL Server - PullRequest
Новая
       10

Как увидеть строку подключения, используемую для подключения к SQL Server

3 голосов
/ 02 декабря 2009

Есть ли способ узнать, какая строка подключения использовалась для подключения к SQL Server? Или, скорее, какая строка использовалась при неудачной попытке входа в систему.

Много раз я сталкиваюсь со сложными системами, в которых я вижу сбои, вызванные тем, что какой-то сервис не может войти в SQL. Я предполагаю, что строка подключения может быть неправильной, но, поскольку я не могу понять, что это было, у меня часто возникают проблемы с выяснением, у кого на самом деле была эта проблема с подключением, чтобы иметь возможность перенастроить ее и исправить.

Ошибки в журнале просто говорят что-то вроде 2009-12-01 20: 16: 31.05 Ошибка установления соединения SSPI при входе в систему с кодом ошибки 0x8009030c при установлении соединения с интегрированной защитой; соединение было закрыто. [КЛИЕНТ: 10.124.172.65] 2009-12-01 20: 16: 31.06 Ошибка входа: 18452, уровень серьезности: 14, состояние: 1. 2009-12-01 20: 16: 31.06 Вход в систему не выполнен. Логин входит в ненадежный домен и не может использоваться с аутентификацией Windows. [КЛИЕНТ: 10.234.222.13]

Есть ли какой-нибудь аудит, который я мог бы включить, или инструмент, который вынюхивал строку подключения, чтобы я мог выяснить, что не так со строкой, анализируя саму строку?

Ответы [ 2 ]

2 голосов
/ 02 декабря 2009

Не совсем. Строка подключения - это только вопрос между клиентским приложением и клиентскими библиотеками SQL, и нет никаких готовых инструментов, которые можно было бы обнаружить в этом узком месте.

Однако в вашем примере нет необходимости знать строку подключения. Вы знаете, что строка подключения использовала Integrated Security (по определению это «SSPI handshake»), вы знаете, что она пыталась подключиться к серверу, на котором эта ошибка была зарегистрирована, вы знаете причину ошибки (ошибка SEC_E_LOGON_DENIED), и знать, какой клиент пытался подключиться (10.234.222.13). В строке подключения нет абсолютно ничего, что помогло бы устранить эту проблему.

Ошибка, которую вы видите, является ошибкой SSPI, в частности, ошибкой Kerberos / NTLM, и вам следует обратиться к ней, используя инструменты и методологии Kerberos / NTLM. Большинство, если не все, проблем Kerberos / NTLM можно устранить с помощью документа Устранение ошибок Kerberos .

В вашем случае вы, вероятно, найдете одного из распространенных виновников:

  • службы, работающие под локальной учетной записью, пытаются подключиться удаленно.
  • попытка подключения через границы ненадежных доменов
  • (скорее всего) сервисы, работающие с просроченным паролем
0 голосов
/ 02 декабря 2009

Во-первых, не существует централизованного способа сделать это "из коробки".

Однако эти типы проблем являются хорошей частью аргумента в пользу наличия DAL, где вы централизуете все управление соединениями и транзакциями, а также ведение журнала ошибок.

SQL Profiler также может дать вам некоторую информацию - хотя, вероятно, недостаточно для устранения проблемы, он может дать вам подсказку в смысле времени ошибки.

...