Осиротевшие пользователи SQL Server после восстановления

Восстановление базы может завершиться успешно, а приложение по-прежнему не получит доступ. Одна из причин: осиротевший пользователь, связанный с SID логина, которого нет на целевом экземпляре. Создание логина с тем же видимым именем не гарантирует получение прежнего SID.

Разделяйте аутентификацию и права базы. Логин задаёт идентичность на уровне экземпляра. Пользователь представляет её внутри конкретной базы и несёт членство в ролях и разрешения. Восстановление возвращает пользователя, но не переносит автоматически все логины и зависимости экземпляра.

Проверяем связь по SID

Запустите запрос чтения в восстановленной базе через административное соединение с достаточной видимостью серверных принципалов.

-- SQL-authenticated, instance-mapped users in the current database.
SELECT dp.name AS DatabaseUser, dp.sid AS DatabaseUserSid,
       dp.authentication_type_desc
FROM sys.database_principals AS dp
LEFT JOIN sys.server_principals AS sp ON sp.sid = dp.sid
WHERE dp.type = 'S'
  AND dp.authentication_type_desc = 'INSTANCE'
  AND dp.principal_id > 4
  AND sp.principal_id IS NULL
ORDER BY dp.name;

Запрос намеренно ограничен SQL-аутентифицированными пользователями, связанными с логинами экземпляра. Он не является универсальной проверкой Windows-групп, автономных пользователей, сертификатов и внешних идентичностей. Пользователь WITHOUT LOGIN не сломан только из-за отсутствия серверного логина.

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

Отдельно изучите предполагаемый целевой логин: SID, состояние включения, тип аутентификации и назначение. Совпадение имени является подсказкой, а не достаточным основанием связать идентичности. В разных окружениях одинаковое имя может принадлежать разным сервисам.

Также отличайте отсутствующее сопоставление от отключённого логина, недоступной базы по умолчанию, неверной строки подключения и отсутствия CONNECT. Одного номера 18456 недостаточно. Используйте серверные подробности ошибки и реальную попытку соединения.

Переназначаем существующего пользователя

Если правильный целевой логин уже существует, измените связь на месте.

-- Run in the restored database only after verifying the intended mapping.
ALTER USER [AppUser] WITH LOGIN = [AppLogin];

AppUser и AppLogin являются примерными именами; замените их проверенной парой. ALTER USER сохраняет существующего принципала базы вместо удаления и создания заново, поэтому связанные разрешения и роли могут остаться на месте.

Удаление ради простого исправления способно потерять явные права либо завершиться отказом из-за владения схемами. Повторное создание того же имени не восстанавливает автоматически все отношения. Не превращайте ремонт связи в случайное перепроектирование доступа.

Если логин действительно требуется создать, решите, сохранять ли исходный SID через утверждённую процедуру миграции. Это может поддержать сопоставление сразу нескольких восстановленных баз. Учётные данные и политики логина переносите установленным безопасным процессом, не вставляя пароли в импровизированный сценарий.

Избегайте автоматического массового сопоставления только по именам. Проверяйте конкретный список исходных и целевых идентичностей, особенно при объединении экземпляров. За одинаковыми названиями могут находиться разные границы доверия.

Подтверждаем связь и полномочия

Проверьте совпадение SID и ожидаемые роли.

SELECT dp.name AS DatabaseUser, sp.name AS MappedLogin,
       dp.sid AS DatabaseUserSid, sp.sid AS LoginSid
FROM sys.database_principals AS dp
JOIN sys.server_principals AS sp ON sp.sid = dp.sid
WHERE dp.name = N'AppUser';

SELECT r.name AS DatabaseRole
FROM sys.database_role_members AS drm
JOIN sys.database_principals AS r ON r.principal_id = drm.role_principal_id
JOIN sys.database_principals AS m ON m.principal_id = drm.member_principal_id
WHERE m.name = N'AppUser';

Список ролей является только частью инвентаризации. Прямые объектные права, разрешения схемы, DENY и владение тоже влияют на доступ. Сравнивайте необходимые права до и после ремонта.

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

Для группы доступности подготовьте логины на каждой реплике, способной стать первичной. Работоспособность текущей первичной не доказывает успешного будущего переключения. Включайте идентичности в учения восстановления и failover вместе с проверкой данных.

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

Сохраните проверенные соответствия и результаты в записи миграции. Дополнительно проверьте фоновые службы, использующие другие логины: успешный веб-запрос не гарантирует работу ночной загрузки. Завершённое восстановление означает доступ нужной идентичности к нужным операциям с сохранением исходных ограничений.

Техническая документация: Microsoft Learn: Troubleshoot orphaned users · Microsoft Learn: ALTER USER.