Как сбросить пароль sa в Microsoft SQL Server: Windows и Linux

sa, sysadmin, dbo и пароль кластера 1С: не смешивайте уровни

sa — встроенное имя входа уровня экземпляра SQL Server с полномочиями sysadmin. Пользователь dbo внутри базы и роль db_owner — другие сущности. Право администрировать Windows тоже не означает постоянное членство в sysadmin обычного работающего экземпляра.

Встроенный логин мог быть переименован. Поэтому ниже есть проверка по SID, а не только поиск слова sa. Описание модели доступа — в документации Microsoft. Для другого уровня используйте инструкцию о доступе к кластеру 1С.

Три сценария: выберите свой до изменения настроек

Сначала проверьте хранилище секретов, документацию внедрения и действующую группу DBA. Если задача — вернуть возможность обслуживания, она не обязательно требует включения sa. Иногда достаточно восстановить именной административный вход, а sa оставить отключённым.

Шаг 1. Найдите именно тот экземпляр, который обслуживает базу

У одного сервера могут быть экземпляр по умолчанию, именованный экземпляр для 1С и тестовый SQL Express. Перед работами сопоставьте службу, адрес подключения и реальную базу. В PowerShell выполните только просмотр:

Get-CimInstance Win32_Service |
  Where-Object { $_.Name -eq 'MSSQLSERVER' -or $_.Name -like 'MSSQL$*' } |
  Select-Object Name, State, StartName, PathName |
  Format-List

Для экземпляра по умолчанию служба обычно называется MSSQLSERVER, для именованного — MSSQL$ИМЯ. В PowerShell знак доллара в имени удобнее защищать одинарными кавычками. Пример ниже — для условного именованного экземпляра SQL1C на локальном сервере.

$engine = 'MSSQL$SQL1C'
$agent  = 'SQLAgent$SQL1C'
$target = 'localhost\SQL1C'
Get-Service -Name $engine
Get-Service -Name $agent -ErrorAction SilentlyContinue
Get-Command sqlcmd -ErrorAction SilentlyContinue

Отсутствие Agent нормально для редакции, где его нет. Наличие sqlcmd проверьте заранее: скачивать и устанавливать клиент во время аварийного окна неудобно. Значения переменных нельзя переносить на свой сервер без сверки.

Шаг 2. Проверьте действующий административный вход

В SSMS подключитесь с Windows Authentication под согласованной DBA-учётной записью. В открытом запросе проверьте адрес, версию и контекст. Запросы ниже ничего не изменяют:

SELECT
  @@SERVERNAME AS server_name,
  SERVERPROPERTY('InstanceName') AS instance_name,
  SERVERPROPERTY('ProductVersion') AS product_version,
  ORIGINAL_LOGIN() AS original_login,
  IS_SRVROLEMEMBER(N'sysadmin') AS is_sysadmin;

Для описанного далее административного пути ожидается is_sysadmin = 1. Значение 0 или NULL не является разрешением продолжить. Возврат прав за пределами вашей ответственности согласуют с владельцем сервера.

SELECT name, is_disabled, default_database_name
FROM sys.server_principals
WHERE sid = 0x01;

Запишите фактическое имя встроенного логина. Если он переименован, последующие команды должны использовать найденное имя. Не создавайте новую учётную запись с названием sa, чтобы «восстановить» исходную.

Шаг 3. Смените пароль без перезапуска экземпляра

При работающем административном входе используйте штатную команду. В примере указан шаблон: замените содержимое строкового литерала новым уникальным секретом перед выполнением в защищённом редакторе.

-- Выполняется администратором нужного экземпляра.
-- Если встроенное имя входа переименовано, замените [sa].
ALTER LOGIN [sa] WITH PASSWORD = N'<НОВЫЙ_УНИКАЛЬНЫЙ_ПАРОЛЬ>';
GO

Одинарную кавычку внутри SQL-литерала экранируют удвоением; не путайте это с правилами PowerShell или командной оболочки. Не помещайте секрет в параметр -Q общего скрипта, историю команд, заявку или репозиторий. Шаблон с угловыми скобками не является подходящим рабочим паролем.

Обычная смена пароля не требует перезапуска Database Engine. Но старые открытые соединения не заменяют проверку нового входа: создайте отдельное соединение после изменения. Порядок и требования к ALTER LOGIN приведены в справочнике Microsoft.

Тот же путь в SSMS: где находятся пароль и состояние логина

В Object Explorer выберите нужный сервер → Security → Logins → найденное встроенное имя входа → Properties. На странице General задаются пароль и подтверждение; на странице Status отдельно управляется разрешением входа. В русской локализации это «Безопасность», «Имена входа», «Свойства», «Общие» и «Состояние».

Перед сохранением ещё раз проверьте имя сервера в заголовке подключения. После сохранения не закрывайте единственный рабочий административный сеанс до проверки отдельного нового подключения.

Смена пароля не включает отключённый sa и не меняет режим аутентификации

Для SQL-входа нужны подходящий режим аутентификации и разрешённый логин. Отдельно проверьте, используется ли только Windows Authentication:

SELECT SERVERPROPERTY('IsIntegratedSecurityOnly') AS windows_only;
SELECT name, is_disabled
FROM sys.server_principals WHERE sid = 0x01;

windows_only = 1 означает режим только Windows. Если организации нужен SQL-вход, смену режима согласуют отдельно и выполняют с предусмотренным перезапуском. Если он не нужен — не включайте смешанный режим только ради контрольного входа sa.

-- Только если использование встроенного логина действительно согласовано:
ALTER LOGIN [sa] ENABLE;
GO

Этот пример не является обязательным продолжением смены пароля. При переходе со встроенной аутентификации на смешанную отключённый sa сам не включается. Microsoft отдельно описывает режимы и включение логина.

До ротации найдите, кто использует эти реквизиты

• 1С. Проверьте свойства каждой клиент-серверной базы и технический SQL-логин, которым платформа подключается к СУБД.
• Интеграции. Обмены, отчётность, BI, выгрузки и внешние обработчики могут иметь собственные строки подключения.
• Эксплуатация. Резервирование, мониторинг, задания и сценарии обслуживания могут использовать отдельное хранилище секретов.
• Пулы соединений. Приложение может некоторое время работать через уже открытый сеанс и отказать только при новом подключении.

Составьте перечень зависимостей с владельцами. Не собирайте открытые пароли в одной общей таблице. Для новой схемы предпочтительны отдельные учётные записи с обоснованными правами; миграцию с sa планируют и проверяют отдельно.

Модельная ситуация: пароль обновили в SQL, но не в свойствах базы 1С. Пользователи ещё работают, а после перезапуска рабочих процессов платформа перестаёт подключаться. Поэтому контрольный тест должен проверять новое соединение, а не только открытый отчёт.

Если все административные входы потеряны: подготовьте окно

Далее — восстановление для отдельного SQL Server на Windows. Для FCI, Always On, управляемого облачного сервиса или контейнера сначала нужен план, учитывающий оркестратор и роль узла. Не останавливайте кластерный ресурс как обычную локальную службу по этой памятке.

1. Подтвердите полномочия, локальный административный доступ и консоль сервера на случай потери удалённого соединения.
2. Запишите версию, службу, параметры запуска, исходное состояние Agent, перечень баз и приложений.
3. Проверьте резервные копии пользовательских и системных баз, ключи и сертификаты шифрования. Потеря доступа не повод пересоздавать master.
4. Остановите приложения и автоматизацию по согласованному порядку. Ограничьте административные подключения до нужного узла.
5. Установите критерии возврата: экземпляр запускается обычно, базы доступны, восстановлен именной DBA-вход.

Без доступа к серверу ОС этот путь не применяется. Это восстановление владельцем инфраструктуры, а не удалённая команда для обхода чужой аутентификации.

Windows: однопользовательский запуск и восстановление DBA-входа

Выполняйте в повышенной PowerShell-сессии на самом узле. Ниже используется условный SQL1C. Для экземпляра по умолчанию замените службу на MSSQLSERVER, Agent на SQLSERVERAGENT, а адрес подключения на localhost.

$engine = 'MSSQL$SQL1C'
$agent  = 'SQLAgent$SQL1C'
# Зафиксируйте исходный Status перед остановкой.
Get-Service -Name $engine
Get-Service -Name $agent -ErrorAction SilentlyContinue
# Если Agent существует и работает, сначала остановите его:
Stop-Service -Name $agent -ErrorAction Stop
net.exe stop $engine
if ($LASTEXITCODE -ne 0) { throw 'Database Engine не остановлен' }
net.exe start $engine /mSQLCMD
if ($LASTEXITCODE -ne 0) { throw 'Однопользовательский запуск не выполнен' }

Если Agent отсутствует, его строку остановки пропускают. Имя SQLCMD регистрозависимо в применимых сценариях. Ограничение имени клиентской программы уменьшает конкуренцию за единственное подключение, но не является защитой: клиент может представиться таким именем.

Используйте заранее проверенный клиент sqlcmd. Для локального именованного экземпляра можно явно выбрать shared memory, если протокол включён:

sqlcmd -S "lpc:localhost\SQL1C" -E -d master

Подключение должно идти под полномочиями локального администратора, с которыми выполнен повышенный запуск. В единственном сеансе восстановите согласованную именную DBA-запись. CONTOSO и DBARecovery ниже — обозначения примера, не готовое имя вашей организации:

-- Сначала подтвердите, к какому экземпляру подключились.
SELECT @@SERVERNAME, ORIGINAL_LOGIN();
GO
-- Только для заранее согласованной существующей учётной записи Windows:
IF SUSER_ID(N'CONTOSO\DBARecovery') IS NULL
    CREATE LOGIN [CONTOSO\DBARecovery] FROM WINDOWS;
GO
ALTER SERVER ROLE [sysadmin] ADD MEMBER [CONTOSO\DBARecovery];
GO
EXIT

После этого верните обычный режим, проверьте именной вход и меняйте sa штатно, если это остаётся задачей. Принцип восстановления подтверждён руководством Microsoft; ограничения single-user — в отдельном описании режима. Синтаксис учётной записи и членства — CREATE LOGIN и ALTER SERVER ROLE.

Верните многопользовательский режим до запуска приложений

Для показанного запуска с временным параметром net start остановите службу и запустите её обычно:

net.exe stop $engine
if ($LASTEXITCODE -ne 0) { throw 'Экземпляр не остановлен' }
net.exe start $engine
if ($LASTEXITCODE -ne 0) { throw 'Обычный запуск не выполнен' }
Get-Service -Name $engine

Если -m добавляли постоянно через SQL Server Configuration Manager, сначала удалите именно добавленный параметр, сохранив остальные. Обычный перезапуск не удалит постоянную настройку автоматически. Здесь не требуется -f: минимальная конфигурация решает другую проблему и не добавляется «на всякий случай».

Восстановите Agent только в исходном согласованном состоянии, затем мониторинг и приложения. Временные административные права пересмотрите после проверки постоянного DBA-доступа. Не удаляйте последний рабочий вход ради формального закрытия заявки.

Linux: отдельная штатная процедура восстановления

Установите, что это экземпляр на Linux под systemd, а не SQL Server в контейнере или кластерный ресурс. Проверьте сервис и установленную утилиту:

systemctl status mssql-server --no-pager
sudo /opt/mssql/bin/mssql-conf --help

В текущем руководстве Microsoft для забытого sa на Linux приведена остановка сервиса и повторный запуск интерактивной настройки. Выполняйте её в согласованное окно, сверяя выпуск и параметры существующей установки:

sudo systemctl stop mssql-server
sudo /opt/mssql/bin/mssql-conf setup
# После успешного завершения мастера проверьте фактическое состояние:
systemctl status mssql-server --no-pager

Мастер может задавать вопросы о редакции и условиях использования — не меняйте лицензионный вариант без основания. Проверьте требования своего пакета и при необходимости верните службу штатным способом. Не переносите сюда полномочия локального администратора Windows или команды net start.

Официальная процедура Linux отделяет сброс sa от пересоздания системных баз. Не используйте force-setup ради обычной ротации: он относится к другому, разрушительному сценарию. Для контейнера сначала определите persistent volume и инструкцию конкретного образа; создание нового пустого контейнера не восстанавливает старую базу.

sqlcmd, сертификат и адрес: проверьте клиент до аварии

Существуют варианты sqlcmd на ODBC и Go. Проверяйте установленную версию и её справку; не смешивайте параметры из разных примеров. Для просмотра пути и доступных ключей:

Get-Command sqlcmd | Select-Object Source, Version
sqlcmd -?

После штатной смены, когда разрешены SQL Authentication и нужный логин, новый пароль проверяют отдельным сеансом. Укажите реальное DNS-имя и порт, согласованные с сертификатом; SQL-1C и 1433 ниже — только пример:

sqlcmd -S "tcp:SQL-1C,1433" -U sa -d master

Без -P клиент запросит пароль интерактивно, если он не подставлен из окружения SQLCMDPASSWORD. Проверьте это заранее и не считайте соединение с секретом из окружения проверкой вручную введённого нового пароля.

Ошибка доверия сертификату не доказывает неверный пароль. Исправьте цепочку доверия, имя сервера и клиентскую конфигурацию; не добавляйте отключение проверки сертификата в постоянный регламент. Описание вариантов и параметров — в справочнике sqlcmd.

Если вход не появился: проверьте причину, а не повторяйте сброс

Из работающего административного сеанса можно проверить состояние политики и блокировки SQL-логина:

SELECT name, is_disabled,
  LOGINPROPERTY(name, 'IsLocked') AS is_locked,
  LOGINPROPERTY(name, 'IsExpired') AS is_expired,
  LOGINPROPERTY(name, 'PasswordLastSetTime') AS password_last_set
FROM sys.sql_logins
WHERE sid = 0x01;

NULL не нужно автоматически трактовать как «всё хорошо»: значение зависит от свойства, платформы и настроек. Для подтверждённой блокировки используйте документированный вариант ALTER LOGIN с UNLOCK, а не глобальное отключение парольной политики. См. LOGINPROPERTY.

Приёмка: что считать восстановленным доступом

Проверка должна подтверждать целевой процесс, а не только зелёный статус службы:

1. Нужный экземпляр работает в обычном режиме, приложения могут открывать несколько подключений.
2. Именной администратор входит новым сеансом и имеет согласованные права.
3. Если вход sa требовался, новый пароль проверен отдельным подключением; старый не даёт нового входа.
4. Если sa должен оставаться отключённым, это состояние сохранено, а рабочий DBA-вход доступен.
5. В 1С и других зависимостях проверено новое соединение с СУБД, обмен и согласованная короткая операция.
6. Резервирование, мониторинг и Agent вернулись в исходный режим; нет постоянного -m.
7. Секрет записан в защищённое хранилище, временные полномочия и сетевые исключения закрыты.

SELECT @@SERVERNAME AS instance_name,
       ORIGINAL_LOGIN() AS authenticated_login,
       IS_SRVROLEMEMBER(N'sysadmin') AS is_sysadmin,
       SERVERPROPERTY('IsSingleUser') AS is_single_user;

Для обычной работы ожидается is_single_user = 0. Для технического пользователя приложения sysadmin = 0 может быть правильным результатом: проверять нужно согласованные полномочия, не выдавая максимальные права всем.

Возврат при проблеме: настройка доступа не равна восстановлению базы

Не переустанавливайте SQL Server и не восстанавливайте старый master поверх работающего экземпляра только из-за неудачной смены пароля. Это способно затронуть логины, задания, сертификаты и другие системные сведения.

• Не стартует после аварийного запуска: сохраните ERRORLOG, верните исходные параметры запуска и согласованный режим службы.
• Приложение потеряло соединение: сопоставьте новый секрет и его запись в приложении; восстановите согласованную пару реквизитов через работающего администратора.
• Нет административного входа: не закрывайте сохранившийся рабочий сеанс, используйте согласованный канал восстановления.
• Изменились данные: применяйте отдельный план восстановления базы с оценкой потерь, а не «откат пароля».

Если старый пароль неизвестен, обещать его возврат нельзя. Откат здесь — возвращение управляемого состояния, параметров и работоспособности приложения; новый секрет может остаться новым.

Четыре прикладных ситуации после смены подрядчика

Ситуации модельные. Для профилактики ведите паспорт экземпляра, именные административные записи, запасной контролируемый доступ и проверяемое резервирование. Облачное размещение не отменяет разделения ответственности между владельцем платформы, DBA и обслуживающей организацией.

Два материала для согласованной ротации

Сопровождение SQL Server, 1С и облачного размещения

Частые вопросы и первоисточники

Инструкция опирается на ссылки Microsoft по ходу текста. Даты проверки относятся к документации, а не к испытанию вашего сервера. Условные имена, пути и команды перед работой сверяют с установленной версией и согласованным планом.