Не удаётся создать SSPI контекст в SQL Server

Схема: ошибка cannot generate SSPI context при подключении к SQL Server

Ошибка «The target principal name is incorrect — cannot generate SSPI context» в SQL Server появляется при попытке установить соединение с удалённого хоста с использованием учётной записи Windows. Это общий сигнальный текст, который может маскировать несколько причин: некорректный или устаревший пароль, рассинхронизация часов, неправильно зарегистрированный SPN, или отсутствие прав на доступ к Active Directory.

Ниже — упрощённый план действий, подробные инструкции и дополнения для разных ролей (DBA, администратор AD, служба поддержки).

Причины и признаки

Неправильный или просроченный пароль учётной записи сервиса SQL.
Отсутствие или дублирование SPN (Service Principal Name) для сервиса MSSQL.
Проблемы с Kerberos (какие-то билеты недействительны). Используется NTLM вместо Kerberos.
Рассинхронизация времени между сервером SQL и контроллерами домена (drift часов).
Нехватка прав у учётной записи сервиса для регистрации SPN.
Проблемы с кэшем билетов на клиенте или сервере.

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

Быстрая проверка (5 минут)

Попробуйте подключиться под локальной учётной записью SQL (не Windows) — если работает, проблема в Kerberos/AD.
На сервере SQL выполните перезапуск сервисов SQL Server и SQL Server Agent — иногда помогает временно.
На клиенте и сервере проверьте системное время и часовой пояс. Разница >5 минут может привести к ошибке Kerberos.
Выполните klist purge на клиенте и/или сервере, чтобы очистить кэш Kerberos-билетов.

Пошаговое устранение

1. Проверка и изменение учётной записи службы SQL

Если служба SQL запускается под учётной записью домена, убедитесь, что у этой учётной записи есть право регистрировать SPN, либо используйте учётную запись с такими правами на время диагностики.

Временно можно сменить учётную запись сервиса на учётную запись, имеющую права Domain Admin, выполнить необходимые операции с SPN, а затем вернуть минимально необходимые права. При этом помните про принцип минимальных привилегий.

Шаги для удаления/проверки SPN через Active Directory Users and Computers:

Откройте Active Directory Users and Computers в расширенном виде.

Снимок окна Active Directory Users and Computers, расширенный режим

Найдите записи servicePrincipalName для учётной записи MSSQL Service.
Удалите некорректные или дублирующиеся записи MSSQLSvc.
Закройте консоль и попробуйте подключиться снова.

Дополнительно: управлять SPN можно через setspn. Примеры:

# Показать зарегистрированные SPN для учётной записи
setspn -L DOMAIN\SqlServiceAccount

# Удалить конкретный SPN
setspn -D MSSQLSvc/sqlserver.domain.local:1433 DOMAIN\SqlServiceAccount

# Зарегистрировать SPN безопасно (проверяет дубли)
setspn -S MSSQLSvc/sqlserver.domain.local:1433 DOMAIN\SqlServiceAccount

Примечание: используйте -S, чтобы setspn проверял на дублирование перед созданием.

2. Проверка пароля и состояния учётной записи

Ошибка часто возникает из‑за того, что пароль учётной записи службы был изменён, а служба не была перезапущена. Также возможен сценарий с истёкшим паролем.

Действия:

Выйдите и снова войдите в систему под соответствующей учётной записью (если это интерактивная сессия).
Проверьте в AD, не истёк ли пароль, и при необходимости смените/обновите его.
После смены пароля перезапустите службы SQL Server, чтобы они использовали новые креденшалы.

3. Изменение прав в Active Directory через ADSIEdit

Если сервисная учётная запись не может записать SPN в AD, можно скорректировать права доступа для неё через ADSIEdit:

Запустите adsiedit.msc через окно Выполнить.

Окно ADSIEdit.msc с деревом домена

В дереве разверните Domain [YourDomainName] → DC=RootDomainName → CN=Users.
Найдите CN=[YourAccountName] → Свойства → Security (Безопасность) → Advanced (Дополнительно).
Выберите любую запись SELF → Edit → Open Permission Entry.
Убедитесь, что Principal = SELF, Type = Allow, Applied to = This object only.
В списке прав включите Read servicePrincipalName и Write servicePrincipalName.
Примените изменения и закройте.
Перезапустите сервисы SQL, связанные с этой учётной записью.

Важно: изменение прав в AD следует делать осторожно и только после подтверждения, что проблема действительно в правах.

4. Проверка Kerberos и билетов

На клиенте и на сервере выполните:

klist purge
klist tickets

Проверьте, используется ли Kerberos или NTLM для подключения. В логах SQL Server ищите упоминания о Kerberos.
Если Kerberos не используется, проверьте корректность SPN и его отсутствие в дублирующем виде.

5. Дополнительные проверки сети и DNS

Убедитесь, что DNS возвращает правильные A/AAAA записи и что имя сервера совпадает с тем, которое используется в SPN.
Избегайте подключения по CNAME, если SPN зарегистрирован под реальным именем хоста. Для CNAME может потребоваться дополнительная настройка SPN.

Команды и сценарии диагностики (шпаргалка)

Список SPN для учётной записи:

setspn -L DOMAIN\SqlServiceAccount

Поиск дублей SPN (можно выполнить на контроллере домена):

setspn -X

Очистка Kerberos-кэша и просмотр билетов:

klist purge
klist tickets

Проверить, кто зарегистрировал SPN (через AD или командой setspn -L):

setspn -L SqlServiceAccount

Примеры, когда предложенные меры не помогут

Если проблема вызвана аппаратным сбоем сети или проблемами контроллера домена (AD недоступен) — локальные изменения в учётных записях не исправят ситуацию.
Если используется сторонний балансировщик или прокси, который изменяет имя назначения (SNI) — нужно настраивать SPN и на стороне балансировщика.
Если доменная архитектура смешанная и есть рестрикции на запись SPN, понадобятся изменения на уровне политики безопасности AD.

Роль‑ориентированные чек-листы

DBA:

Проверить логи SQL Server (ошибки аутентификации).
Перезапустить службы SQL после изменений учётной записи.
Проверить зарегистрированные SPN через setspn.

Администратор Active Directory:

Проверить права записи servicePrincipalName для учётной записи службы.
Устранить дубли SPN.
Проверить репликацию AD и доступность контроллеров домена.

Служба поддержки/Helpdesk:

Проверить дату/время на клиенте и сервере.
Очистить Kerberos-кэш на клиенте.
Собрать логи и передать DBA/AD-администратору.

Пошаговый план действий (SOP)

Быстрая проверка времени и перезапуск служб.
Проверка состояния учётной записи сервиса (пароль, блокировка, срок действия).
Просмотр и коррекция SPN (setspn).
При необходимости временно дать право на регистрацию SPN, выполнить настройку и вернуть минимальные права.
Проверить Kerberos-билеты и перезапустить сервисы.
Тестирование подключения и мониторинг логов в течение времени простоя.

Диагностическое дерево

flowchart TD
  A[Начало: ошибка SSPI] --> B{Подключение под SQL auth?}
  B -- Да --> C[Проблема с Windows auth — временно используйте SQL auth]
  B -- Нет --> D[Проверить время]
  D --> E{Часы синхронизированы?}
  E -- Нет --> F[Синхронизировать время, перезапустить сервисы]
  E -- Да --> G[Проверить пароль и статус учётной записи]
  G --> H{Пароль/активен?}
  H -- Нет --> I[Сбросить пароль, перезапустить сервисы]
  H -- Да --> J[Проверить SPN 'setspn']
  J --> K{SPN корректен и уникален?}
  K -- Нет --> L[Удалить/создать SPN, перезапустить сервисы]
  K -- Да --> M[Проверить Kerberos билеты 'klist']
  M --> N{Билеты валидны?}
  N -- Нет --> O[Очистить кэш, получить новый билет]
  N -- Да --> P[Если всё верно — обратиться к AD/инфраструктуре]

Критерии приёмки

Удалось подключиться к SQL Server с учётной записью Windows без ошибки cannot generate SSPI context.
SPN зарегистрирован корректно и не дублируется.
Билеты Kerberos доступны и валидны (klist tickets показывает соответствующие записи).
Нет рассинхронизации времени между серверами и контроллерами домена.

Итог и рекомендации

Ошибка cannot generate SSPI context обычно решается последовательной диагностикой: проверить время, пароли, права в AD и SPN. Начните с простых шагов (время, перезапуск, очистка билетов), затем проверьте SPN и права через setspn и ADSIEdit. Если вы не уверены в правах, привлеките администратора AD — изменение прав без понимания последствий может нарушить безопасность.

Если после всех шагов проблема остаётся, соберите логи SQL Server и дамп сетевых вызовов и передайте их команде AD/инфраструктуры.

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

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