Login Failed for xxx – Кто пытается подключиться к моему SQL Server?

Login Failed for xxx – Кто пытается подключиться к моему SQL Server?

Перевод статьи — Login Failed for xxx – Who’s Keeps Trying to Connect to my Server?

Я недавно решал проблему ошибок подключения к SQL Server, которые возникали каждую секунду. В ошибке фигурировал аккаунт AUTHORITY\ANONYMOUS LOGON, который, обычно, относится к проблеме Kerberos «double hop«. Мы знали, что это был web server, так как ошибка содержала ip адрес.

Date        2/13/2017 10:18:50 PM
Log        SQL Server (Current – 2/11/2017 2:19:00 PM)
Source        Logon
Message
Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON’. Reason: Could not find a login matching the name provided. [CLIENT: xxx.xxx.xxx.xxx]

Date        2/13/2017 10:18:50 PM
Log        SQL Server (Current – 2/11/2017 2:19:00 PM)
Source        Logon
Message
Error: 18456, Severity: 14, State: 5.

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

Нам нужно было получить больше информации и мы обратились к Extended Events. Поиск по событиям login в Extended Events показал, что регистрируются только успешные подключения:

select [name], description, object_type from sys.dm_xe_objects where [name] = 'login'

Тогда мы решили, что раз события регистрируются в логе ошибок, то и событие в Extended Events нам надо искать именно такое (errorlog_written):

CREATE EVENT SESSION [LoginFailureTrace] ON SERVER
ADD EVENT sqlserver.errorlog_written( ACTION(sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.client_pid))
ADD TARGET package0.event_file(SET filename=N'LoginFailureTrace',max_file_size=(128))
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_MULTIPLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO

Нам повезло и мы смогли поймать client_pid:

С помощью данной трассы мы смогли обнаружить проблемный Windows Process ID = 3500 и исправили ситуацию.

Запись опубликована в рубрике Полезно и интересно с метками . Добавьте в закладки постоянную ссылку.

Добавить комментарий

Войти с помощью: