Ситуация, когда в логах SQL Server постоянно мелькают записи Login failed for user '1c83'. Reason: Password did not match, знакома многим системным администраторам 1С. Когда на сервере крутятся десятки или сотни информационных баз, поиск той самой, где при смене пароля «забыли» обновить настройки подключения, превращается в настоящую детективную задачу. Просто перебирать базы вручную — долго и неэффективно, особенно если пользователи не жалуются (например, если пароль неверный в одной из копий для разработки или в базе, где работают только регламентные задания).
В этой статье мы подробно разберем несколько профессиональных способов локализации «виновника» — от настройки Технологического журнала 1С до использования инструментов SQL Server и системного мониторинга.
Это самый точный и надежный метод, который рекомендуют эксперты. Технологический журнал (ТЖ) позволяет зафиксировать исключительные ситуации непосредственно в момент их возникновения на стороне сервера приложений 1С. Когда rphost пытается подключиться к SQL и получает отказ в авторизации, это генерирует событие исключения.
Рассмотрим по шагам, как настроить сбор нужных данных:
C:\Program Files\1cv8\conf).logcfg.xml.EXCP. Нам важно добавить фильтр, чтобы не забивать диск лишней информацией, и обязательно включить свойство ProcessName, которое и содержит имя информационной базы.Пример настройки logcfg.xml:
<config xmlns="http://v8.1c.ru/7.4/config/logcfg">
<log location="C:\LOGS\SQL_AUTH_ERROR" history="2">
<event>
<eq property="Name" value="EXCP"/>
</event>
<property name="all"/>
</log>
</config>
После сохранения файла (перезагрузка службы 1С обычно не требуется, платформа подхватывает изменения «на лету» в течение минуты) проанализируем логи в папке C:\LOGS\SQL_AUTH_ERROR. Нам нужно искать строки, содержащие текст ошибки SQL. В этих строках атрибут ProcessName укажет точное имя базы в кластере 1С.
Если мы подозреваем, что пароль был изменен массово, но в некоторых базах остался старый, мы можем попробовать проанализировать конфигурационные файлы кластера. Основной файл, хранящий параметры информационных баз — 1CV8Clst.lst (или 1CV8Reg.lst в зависимости от версии и режима работы).
Проанализируем структуру этого файла. Он находится в каталоге данных сервера 1С (обычно C:\Program Files\1cv8\srvinfo\reg_1541). Откроем его текстовым редактором и обратим внимание на параметры подключения к СУБД.
Важный нюанс: Пароли в этом файле хранятся в зашифрованном (хешированном) виде. Сравнить их «глазами» напрямую не получится, так как современные версии платформы используют «соль» при генерации хеша. Однако мы можем применить метод эталона:
1CV8Clst.lst.Тем не менее, если баз очень много, ручной поиск в .lst файле малоэффективен по сравнению с ТЖ, но он помогает быстро увидеть, какой именно логин SQL используется в каждой базе (иногда проблема в том, что в одной базе случайно указан не 1c83, а другой пользователь).
Разберем ситуацию со стороны СУБД. SQL Server позволяет настроить расширенные события (Extended Events), чтобы отловить ошибку авторизации. Это «легче» для сервера, чем использование старого SQL Profiler.
Выясним причину через создание сессии мониторинга:
error_reported.error_number = 18456 (это стандартный код ошибки Login Failed).client_app_name и client_hostname.Хотя при неудачном логине SQL не всегда может сопоставить сессию с конкретной базой 1С (так как соединение еще не установлено), он покажет нам динамический порт входящего подключения. Это критически важная информация!
Проанализируем ситуацию далее: зная порт, мы можем зайти на сервер 1С и выполнить команду в PowerShell:
Get-NetTCPConnection -LocalPort [ПОРТ_ИЗ_ЛОГА_SQL]
Это выдаст нам OwningProcess (PID процесса). Обычно это будет один из процессов rphost.exe. Теперь мы знаем, какой именно рабочий процесс «стучится» с неверным паролем. В консоли администрирования 1С можно посмотреть, какие именно информационные базы запущены в рамках этого конкретного процесса rphost. Это значительно сузит круг поиска.
Чтобы не заходить в каждую базу через конфигуратор, воспользуемся консольной утилитой rac. Мы можем выгрузить список всех баз с их параметрами в текстовый файл для удобного поиска.
Рассмотрим команду для получения списка баз:
rac infobase --cluster=[ID_КЛАСТЕРА] summary list
Выгрузив этот список, мы можем быстро просмотреть, у каких баз указан пользователь 1c83. Если в списке есть базы, о которых вы забыли (тестовые, архивные), скорее всего, проблема в них. Также можно написать скрипт на языке 1С, который будет перебирать список баз через МенеджерКластера и пытаться установить соединение, отлавливая ошибки в блоке Попытка...Исключение.
Проанализировав все способы, можно сделать вывод, что самым быстрым и информативным является Технологический журнал с фильтром по событию EXCP. Он сразу дает ответ в виде имени базы (ProcessName). Если же по какой-то причине ТЖ использовать нельзя, связка SQL Extended Events + netstat поможет вычислить конкретный rphost, что также приведет к решению проблемы.
Помните: частые ошибки авторизации на SQL Server могут привести к блокировке учетной записи (если настроены политики безопасности Windows) или к существенному раздуванию логов SQL, что может вызвать деградацию производительности всей системы. Поэтому устранение таких «фантомных» ошибок — важная часть регламентных работ системного администратора 1С.