Ошибка: невозможно создать контекст SSPI

Когда кто-то пытается подключиться к экземпляру SQL Server, появляется ошибка:

Невозможно сгенерировать контекст SSPI.

Вчера у нас было отключение (я не знаю, как сказать это выражение на английском), и мне пришлось закрыть наши серверы.

Ища ответы, я нашел это:

Проблема с подключением к SQL Server 2008: невозможно создать контекст SSPI

Но это не помогает мне, потому что они работают нормально до вчерашнего дня. Я не хочу ничего менять. Но если придется, я это поменяю.

Obs: Я не могу перезапустить сервер сейчас.

Изменить: так как я мой ответ, у нас не было никаких ошибок.

«Невозможно сгенерировать контекст SSPI» - общая ошибка. Это может быть вызвано многими проблемами, такими как отключенный пароль, смещение тактовой частоты, разрешения доступа к Active Directory, сбой регистрации имени участника-службы и т. Д. И т. Д.

Нет решения этой проблемы. Единственное «решение» - это выяснить причину, согласно KB811889 и / или Устранению ошибок Kerberos . Применение того или иного решения из случайных интернет-ресурсов, без понимания причины, может или не может решить проблему, может или не может вызвать разочарование, может или не может нанести безвозвратный ущерб.

Мы изменили на SQL SERVICE userтот, который " Domain Admin".

Я провел несколько исследований, чтобы понять, почему это происходит. В нем говорится, что когда вы закрываете службу, вам нужна учетная запись с привилегиями, создающая новое имя участника-службы (при повторном включении). Если вы запустите службу без нее, она отобразится в НЕВОЗМОЖНО СОЗДАТЬ КОНТЕКСТ SSPI.

мы меняем привилегии нашей системной учетной записи.

Надеюсь, это кому-нибудь поможет.

У нас возникла эта проблема после того, как мы взяли базу данных у PROD и восстановили ее в QA. Наше приложение называло три базы данных на трех серверах, и, кроме того, не было сложным.

Оказывается, поддельное имя участника-службы (SPN) мешало учетной записи службы, под которой должно было выполняться соединение. Мы обнаружили это с помощью Program Files> Microsoft Kerberos Config Manager.

Краткосрочным решением было использование диспетчера конфигурации SQL Server и изменение подключений SQL Server и агента SQL Server с учетной записи службы на «LocalSystem» в разделе «Использовать встроенную учетную запись».

Невозможно сгенерировать контекст SSPI, это может означать именно это. Когда клиент подключается к серверу SQL, он использует метод генерации, который включает полное доменное имя (MsSQLsvr) и порт сервера. Он использует DNS для генерации имени сервера, поэтому, если он разрешает имя неправильно из-за имен CNAME, файла хоста и т. Д., Генерация завершится неудачно. Пингуйте нужный сервер и посмотрите, какой ответ вы получите. Если это не полное доменное имя SQL-сервера, тогда SPN будет сгенерирован неправильно, вызывая эту ошибку.

В некоторых ситуациях вы получите эту ошибку из-за настроек SPN. Например, если вы выполняете тестирование аварийного восстановления на новом сервере, вы можете получить ошибку SSPI при подключении к SQL Server. Еще более странным является то, что вы можете подключиться с помощью SQL Server Management Studio, но не можете подключиться через ODBC или OLEDB. Может быть временный обходной путь, который, вероятно, позволит вам получить доступ к базе данных.

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

Хотя это не гарантируется для всех случаев, скорее всего, вы вернетесь к работе. Это не должно считаться постоянным исправлением. Вы должны решить SPN или другие проблемы в идеальной ситуации. Однако, если у вас есть проблемы со старыми машинами Windows, на которых установлена ​​неподдерживаемая операционная система, или если вы просто проводите тестирование концепции аварийного восстановления, это должно помочь вам в том, чтобы вы оставались включенными или работали.

У меня возникла эта проблема, и она была решена путем удаления записи SPN в атрибутах учетной записи компьютера в AD для сервера

Найдите учетную запись компьютера в AD Users and Computers (расширенный просмотр)

Затем удалите две записи в servicePrincipalName для MSSQLSvc

У меня была похожая проблема. В итоге мне пришлось удалить записи из информации SPN в учетной записи компьютера в ADSIEdit.

После удаления записей я перезапустил службу SQL, и она зарегистрировала имя участника-службы с созданной мной учетной записью ресурса домена. Затем я смог получить доступ к SQL Server удаленно.

Для меня решение было запустить SQL Studio как пользователь домена с этой командой:

runas / user: OtherDomain \ User SSMS.exe

Я столкнулся с этой проблемой совсем недавно. Я работал в качестве учетной записи NT SERVICE, и когда я переключился на учетную запись службы, я больше не мог подключиться, используя SSMS с именем машины или полным доменным именем. Я мог бы связаться с IP-адресом. С некоторыми копаниями я обнаружил, что SPN в Active Directory для экземпляра SQL был зарегистрирован на компьютере. Как только я удалил это, а затем добавил его в учетную запись службы и перезагрузил компьютер SQL, все заработало как надо. Рад предоставить больше деталей, если это необходимо.