Не удается создать контекст SSPI

похоже, что ваш компьютер некоторое время не связывался с аутентифицирующим контроллером домена. (Раньше это случалось на моем ноутбуке несколько раз.)

Это также может произойти, если срок действия пароля истек.

У меня была такая же проблема после изменения пользователя, который запускал MSSQLSERVER-Service

для решения неправильных SPNs с SQL Server я использовал этот инструмент

http://www.microsoft.com/en-us/download/details.aspx?id=39046 - Microsoft® Kerberos Configuration Manager для SQL Server

в моем случае это сработало очень хорошо.

Первое, что вы должны сделать, это зайти в логи (Management\SQL Server Logs) и посмотреть, если SQL Server successfully registered the Service Principal Name (SPN). Если вы видите какую-то ошибку (The SQL Server Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service), то вы знаете, с чего начать.

мы видели, что это произошло, когда мы изменили учетную запись, под которой работал SQL Server. Сброс его в локальную системную учетную запись решил проблему. Microsoft также имеет руководство при ручной настройке SPN.

эта ошибка обычно возникает, когда срок действия учетной записи пользователя Windows истек, и он уже вошел в систему со старым паролем. Просто попросите пользователя перезагрузить компьютер и проверить, истек ли срок действия пароля или он изменил пароль. Надеюсь, это поможет!!!!!

Я решил мой Cannot Generate SSPI Context ошибка при использовании диспетчера конфигурации SQL Server. Поскольку у меня есть собственный клиент SQL Server 10.0 на моей машине, соединение с сервером пытается использовать именованные каналы (или общую память?). Другие машины могут запускать мое приложение без проблем. Когда я смотрел на configuration manager, именованные каналы и общая память были включены (хорошо). Однако под псевдонимом имя компьютера было там с принудительным TCP. Так как я не знал, какой эффект это изменит я бы изменил строку подключения в своей программе, чтобы использовать .вместо этого . Зафиксированный.

Если вы размещаете на IIS,убедитесь, что пароль для учетной записи AppPool не изменился.

Если это так, выполните следующие действия:

• перейти к IIS
• нажмите на пулы приложений
• выберите AppPool вашего приложения
• щелкните правой кнопкой мыши на вашем AppPool
• Дополнительные параметры
• личность
• Обновить Пароль
• Перезапустить AppPool

ошибка "не может генерировать контекст SSPI" является очень общей и может произойти по множеству причин. Это просто ошибка покрытия для любой основной ошибки Kerberos / NTLM. Ссылка на статью Gbn в KB является очень хорошей отправной точкой и обычно решает проблемы. Если у вас все еще есть проблемы, я рекомендую выполнить действия по устранению неполадок в Устранение Ошибок Kerberos.

Я также выпустил эту проблему, и администраторы сервера решили ее, следуя тому же решению, что и indu_teja, предложенное в http://www.sqlservercentral.com/Forums/Topic546566-146-1.aspx

решение, предложенное indu_teja, говорит:

Если вы получите эту "ошибку контекста SSPI". Проблемы, с которыми мы сталкиваемся:

1. мы не сможем подключиться к SQL Server удаленно.
2. однако мы сможем подключиться к сервер с локальной учетной записью.

причина: проблема может быть из-за отсутствия надлежащей синхронизации happenign для SPNs в Active directory.

:

1. вам нужно сбросить SPN. Используйте synytax "SET SPN". Вы можете проверить синтаксис в net один раз.
2. измените учетную запись службы sql server с учетной записи домена на локальную учетную запись, перезапустите sql, а затем снова сбросьте учетную запись домена и перезапустите sql server.

У меня была та же проблема, и все, что я сделал, это удалил учетные данные входа пользователя в sql server, используя другой идентификатор пользователя и добавив их обратно.

Я могу решить эту проблему, сбросив домен (серверная машина, которая является сервером домена, но не связана с SQL Server, кроме управления доменом), а затем клиентские машины.

спасибо всем за вашу немедленную поддержку!

имел действительно странный экземпляр этого; все веб-продукты, которые имели строки подключения, содержащие имя компьютера windows SQL server, работали нормально, но продукты, которые имели FQDN с внутренним доменом, прикрепленным, дали ошибку SSPI. т. е. ИМЯ КОМПЬЮТЕРА против ИМЯ КОМПЬЮТЕРА.ДОМЕН (ping всегда работал так, как ожидалось)

Это только дало проблемы, когда новый SQL server использовался и файлы хостов указали как имя компьютера, так и имя_компьютера в качестве FQDN для строка подключения.

решением в этом случае было установить все строки подключения только на имя компьютера, удалив ссылки на домен.

SQL: 2008R2 SQL2012

IIS: 2008R2

вот мой случай. У меня была удаленная машина, на которой размещался SQL Server. С моей локальной машины я пытался получить доступ к экземпляру SQL через некоторый код C#, и я получал эту ошибку. Мой пароль для учетной записи Пользователя на моей машине/домена истек. Я исправил это следующим образом:

1. открыл удаленный компьютер, который попросил меня изменить пароль
2. Я изменил свой пароль в этом приглашении и вошел в удаленный машина!--8-->
3. я "заблокировал" свою локальную машину (используя windows + L ключ, чтобы мне не пришлось полностью подписываться), чтобы я мог вернуться на страницу входа
4. Я вернулся на свой локальный компьютер с новым паролем

все тогда работало нормально.

в моем случае это был отсутствующий SPN, пришлось выполнить эти две команды:

setspn-A MSSQLSvc: ИМЯ_СЕРВЕРА ИМЯ_СЕРВЕРА setspn-A MSSQLSvc: ИМЯ_СЕРВЕРА: 1433 ИМЯ_СЕРВЕРА

другими словами, в моем случае у меня было FQDN там уже правильно, но не только имя NETBIOS, после добавления их он работал нормально. Ну, сначала это не так, но после ожидания 2 минут это произошло.

У меня была эта ошибка-это произошло потому, что мой пароль истек, и мне пришлось его изменить. Я этого не заметил, потому что в некоторых программах я все еще мог войти в систему, и все будет работать нормально (включая windows), но я не мог войти ни на один sql-сервер.

возможно, вы использовали Integrated Security = SSPI в строке подключения. SSPI используется для доверенных соединений с использованием проверки подлинности Windows.следовательно, для правильной работы при проверке подлинности windows Система и сервер баз данных должны находиться в одном домене и использовать один адрес DNS-сервера или в доверенном домене.

Если ваша система и сервер баз данных находятся в одном домене, проверьте адрес DNS-сервера свойств IPV4 в сетевом подключении вашей системы и предоставьте то же самое DNS-сервер используется сервером баз данных.