← На главную

Ситуация, когда после перезагрузки сервера SQL Server перестает пускать пользователя, а служба 1С отказывается подключаться к базе данных, является критической для любого бизнеса. Ошибка 18456 при попытке входа в Microsoft SQL Server Management Studio (SSMS) сигнализирует о проблемах с аутентификацией, которые могут быть вызваны как повреждением системных таблиц, так и изменением прав доступа в операционной системе. В рамках данной статьи мы подробно разберем, как выйти из этой ситуации, даже если стандартные методы сброса пароля не помогают.

Анализируем причины возникновения проблемы

Прежде чем приступать к радикальным мерам, давайте разберем, почему «слетает» доступ. Часто это происходит после некорректного завершения работы (hard reset) или обновлений Windows. Рассмотрим основные факторы:

• Режим восстановления (Recovery): После сбоя SQL Server переводит базы в состояние отката транзакций. Пока этот процесс не завершен, 1С будет выдавать ошибку «Сервер не обнаружен», так как база временно заблокирована.
• Проблемы с учетными записями Microsoft: Если SQL Server устанавливался под локальным пользователем, который связан с учетной записью Microsoft (например, MicrosoftAccount\user@mail.ru), механизм аутентификации через именованные каналы может начать давать сбои.
• Повреждение папки srvinfo: Удаление этой папки в каталоге сервера 1С приводит к очистке списка зарегистрированных баз в консоли администрирования, хотя сами данные в SQL остаются нетронутыми.

Почему стандартный сброс пароля через Single-User Mode может не сработать

Многие системные администраторы пытаются использовать запуск SQL Server с параметром -m (режим одного пользователя) для восстановления доступа. Однако на практике мы часто сталкиваемся с ошибками типа Microsoft ODBC Driver: При входе в систему произошла ошибка.

Проанализируем причину неудачи: режим -m разрешает только одно-единственное подключение. Если в системе активна служба SQL Server Agent или открыта любая консоль мониторинга, они могут перехватить это соединение быстрее, чем вы успеете запустить sqlcmd. Кроме того, драйвер ODBC может некорректно передавать токены авторизации для сложных доменных или «облачных» имен пользователей Windows.

Радикальное, но эффективное решение: Переустановка SQL Server

Если все попытки восстановить доступ к sa или зайти под Windows-авторизацией провалились, рассмотрим проверенный алгоритм восстановления работоспособности через переустановку сервера. Пройдем по шагам этот процесс, чтобы минимизировать риски потери данных.

Шаг 1. Резервное копирование файлов данных

Это самый важный этап. Нам необходимо сохранить физические файлы баз данных. По умолчанию они находятся в папке DATA внутри каталога установки SQL Server. Нам нужны файлы с расширениями:

• .mdf — основной файл данных;
• .ldf — файл лога транзакций.

Важный нюанс: Скопируйте эти файлы в отдельное безопасное место на другом диске или в корень текущего диска. Не оставляйте их в папке программных файлов SQL Server, так как при деинсталляции они могут быть повреждены или заблокированы.

Шаг 2. Полное удаление старого экземпляра

Для корректной работы новой установки необходимо полностью очистить систему. Выполним следующие действия:

1. Через «Панель управления» -> «Программы и компоненты» удаляем Microsoft SQL Server 2016 и все сопутствующие компоненты (Management Studio, Setup Support Files и т.д.).
2. После удаления перезагружаем сервер. Реестр чистить необязательно, но важно убедиться, что службы MSSQLSERVER больше нет в списке активных служб.

Шаг 3. Чистая установка и настройка прав

Устанавливаем SQL Server заново. На этапе настройки выберем Смешанный режим аутентификации (Mixed Mode). Это позволит нам задать пароль для пользователя sa сразу, что застрахует нас от проблем с Windows-авторизацией в будущем.

После завершения установки запустим SQL Server Management Studio. Теперь мы должны беспрепятственно войти под текущим администратором Windows.

Шаг 4. Подключение (Attach) баз данных

Теперь вернем наши базы в строй. Разберем, как правильно подключить файлы .mdf. Рассмотрим ситуацию, когда при попытке подключения из старой папки возникают ошибки доступа. Это происходит из-за того, что у файлов остались идентификаторы безопасности (SID) от предыдущей установки SQL.

Чтобы избежать этого, выполним следующие действия:

1. Переместим файлы базы в новую папку (например, C:\Bases1C\).
2. В SSMS нажмем правой кнопкой на раздел Databases -> Attach....
3. Укажем путь к файлу .mdf. Файл .ldf подтянется автоматически, если он лежит рядом.

Совет: Если SQL Server выдает ошибку "Access Denied", зайдите в свойства папки с базой, перейдите на вкладку "Безопасность" и добавьте пользователя, от имени которого запущена служба SQL Server (обычно это NT Service\MSSQLSERVER), предоставив ему права Full Control.

Шаг 5. Настройка пользователя для 1С:Предприятия

Чтобы сервер 1С мог работать с базой, ему нужны права. Выясним, под каким пользователем работает служба 1С. Обычно это USR1CV8. Выполним настройку в SSMS:

1. Перейдем в раздел Security (Безопасность) -> Logins (Имена входа).
2. Создадим новый логин. Если 1С и SQL на одном сервере, лучше выбрать поиск пользователя в системе (кнопка Search) и найти USR1CV8.
3. В разделе Server Roles (Роли сервера) для упрощения настройки можно временно назначить роль sysadmin, однако для безопасности в промышленной эксплуатации рекомендуется использовать db_owner непосредственно на конкретную базу данных.

Шаг 6. Регистрация базы в консоли администрирования 1С

Если вы ранее удаляли папку srvinfo, список баз в консоли 1С будет пуст. Нам нужно создать описание информационной базы заново:

1. Откроем «Администрирование серверов 1С Предприятия».
2. Создадим новую информационную базу.
3. Укажем имя базы (как оно было раньше), имя сервера SQL и точное имя базы данных в SQL Server, которую мы подключили на шаге 4.
4. Если служба 1С работает от имени USR1CV8, и мы дали этому пользователю права в SQL, то в полях «Пользователь сервера БД» и «Пароль» можно ничего не указывать (при условии использования Windows-аутентификации).

Подведем итог: несмотря на то, что переустановка SQL Server кажется долгой процедурой, в случае полной блокировки доступа и ошибок 18456 это зачастую самый быстрый и надежный способ вернуть систему в рабочее состояние. Главное — всегда иметь под рукой актуальные копии файлов .mdf и .ldf, а также не забывать фиксировать пароли системных учетных записей в надежном месте.