Не удается создать контекст SSPI
Я работаю над приложением.NET, где я пытаюсь создать сценарии базы данных. При создании проекта я получаю сообщение об ошибке "Не удается создать контекст SSPI". Эта ошибка отображается в окне вывода (внутри экрана VS2008), и процесс сборки завершился неудачно. Пожалуйста, помогите в этом. SQL Server настроен на работу с аутентификацией Windows и работает как сетевой сервис (эти две вещи необходимы для моего проекта).
Пожалуйста, помогите в этом. Эта ошибка не кажется последовательной. В прошлом это было исправлено путем перезагрузки компьютера, изменения системного времени в соответствии с временем домена и некоторыми предложениями в сети. Пожалуйста, помогите в этом.
20 ответов
Это довольно распространенная ошибка с различными причинами: начните здесь с KB 811889
- Какая версия SQL Server?
- А винда на клиенте и сервере?
- Локальный или сетевой экземпляр SQL?
- Домен или рабочая группа? Провайдер?
- Смена пароля
- Ошибки локального журнала Windows?
- Какие-либо другие приложения затрагиваются?
Похоже, ваш компьютер некоторое время не связывался с проверяющим контроллером домена. (Раньше такое случалось на моем ноутбуке несколько раз.)
Это также может произойти, если ваш пароль истекает.
Эта ошибка обычно возникает, когда срок действия учетной записи Windows истек, и он уже вошел со старым паролем. Просто попросите пользователя перезагрузить компьютер и проверить, не истек ли срок действия пароля или он сменил пароль. Надеюсь это поможет!!!!!
У меня возникла такая же проблема после смены пользователя, который запускал MSSQLSERVER-Service
Чтобы решить неправильные имена SPN с SQL Server, я использовал этот инструмент
http://www.microsoft.com/en-us/download/details.aspx?id=39046 - Диспетчер конфигурации Microsoft® Kerberos для 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.
Если вы размещаете на IIS, убедитесь, что пароль для учетной записи AppPool не изменился.
Если это так, выполните следующие действия:
- Перейти в IIS
- Нажмите на пулы приложений
- Выберите AppPool вашего приложения
- Щелкните правой кнопкой мыши на вашем AppPool
- Расширенные настройки
- тождественность
- Обновить пароль
- Перезапустите AppPool
Я решил мой Cannot Generate SSPI Context ошибка при использовании диспетчера конфигурации SQL Server. Поскольку у меня на компьютере установлен собственный клиент SQL Server 10.0, соединение с сервером пытается использовать именованные каналы (или разделяемую память?). Другие машины могли запускать мое приложение без проблем. Когда я посмотрел на диспетчер конфигурации, оба канала были включены (хорошо). Однако под псевдонимом имя компьютера было там с принудительным TCP. Поскольку я не знал, к какому эффекту это приведет, я изменил строку подключения в моей программе, чтобы вместо нее использовать
Ошибка "Невозможно сгенерировать контекст SSPI" является очень общей и может произойти по множеству причин. Это просто ошибка прикрытия для любой основной ошибки Kerberos/NTLM. Ссылка на статью базы знаний Gbn является очень хорошей отправной точкой и обычно решает проблемы. Если у вас все еще есть проблемы, я рекомендую выполнить действия по устранению неполадок в разделе Устранение ошибок Kerberos.
Я также выпустил эту проблему, и администраторы сервера решили ее, следуя тому же решению, что и indu_teja, предложенное в http://www.sqlservercentral.com/Forums/Topic546566-146-1.aspx
Решение, предложенное indu_teja, гласит:
Если вы получаете это "Ошибка контекста SSPI". Проблемы, с которыми мы сталкиваемся:
- Мы не сможем подключиться к SQL Server удаленно.
- Однако мы сможем подключиться к серверу с локальной учетной записью.
ПРИЧИНА: Проблема может быть из-за отсутствия надлежащей синхронизации SPN в Active Directory.
РАЗРЕШАЮЩАЯ СПОСОБНОСТЬ:
- Вам нужно сбросить SPN. Используйте синтаксис "SET SPN". Вы можете проверить синтаксис в сети один раз.
- Измените учетную запись службы сервера sql с учетной записи домена на локальную учетную запись, перезапустите sql, а затем снова выполните сброс с учетной записью домена и перезапустите сервер sql.
В vb.net, если вы используете связанный сервер, проверьте строку подключения. Комплексная безопасность = правда; не работает во всех провайдерах SQL, он генерирует исключение при использовании с провайдером OleDb. Так что в основном Интегрированная безопасность =SSPI; является предпочтительным, поскольку работает как с SQLClient, так и с OleDB. Если вы по-прежнему сталкиваетесь с ошибкой, полностью удалите синтаксис.
Возможно, вы использовали Integrated Security = SSPI в строке подключения. SSPI используется для доверенных соединений с использованием Windows Authentication.hence, чтобы правильно работать в Windows-аутентификации, либо ваша система и сервер базы данных должны быть в одном домене и использовать один и тот же адрес DNS-сервера, либо должны находиться в доверенном домене.
если ваша система и сервер базы данных находятся в одном домене, проверьте адрес DNS-сервера свойств IPV4 в сетевом подключении вашей системы и укажите тот же DNS-сервер, который используется сервером базы данных.
Вот мой случай. У меня была удаленная машина, на которой размещался SQL Server. С моей локальной машины я пытался получить доступ к экземпляру SQL через некоторый код C#, и я получал эту ошибку. Срок действия моего пароля для учетной записи на моем компьютере / домене истек. Я исправил это следующим образом:
- Открыл удаленную машину, которая предложила мне сменить пароль
- Я изменил свой пароль в этом приглашении и вошел на удаленный компьютер
- Я "заблокировал" свою локальную машину (используя
windows+Lключ, чтобы мне не пришлось полностью выходить из системы), чтобы я мог вернуться на страницу входа - Я вернулся на свою локальную машину с новым паролем
Тогда все работало нормально.
У меня была эта ошибка - это произошло потому, что мой пароль истек, и мне пришлось его поменять. Я этого не заметил, потому что в некоторых программах я все еще мог войти в систему, и все работало бы нормально (включая windows), но я не мог войти ни на один sql-сервер.
У меня была такая же проблема, и все, что я делал, это удалял учетные данные пользователя на сервере sql, используя другой идентификатор пользователя, и добавлял их обратно.
В моем случае это был пропущенный SPN, пришлось выполнить следующие две команды:
setspn -a MSSQLSvc: ИМЯ СЕРВЕРА ИМЯ СЕРВЕРА SETPN -a MSSQLSvc: ИМЯ СЕРВЕРА:1433 ИМЯ СЕРВЕРА
Другими словами, в моем случае у меня уже было полное доменное имя, а не только имя NETBIOS, после добавления они работали нормально. Ну, вначале это не так, но после ожидания 2 минуты это сделал.
Я могу решить эту проблему, выполнив следующие команды.
Запустите CMD в режиме администратора
klist.exe -li 0x3e7 => if you see no output or error then continue and from last command try these commands once again.
klist.exe -li 0x3e7 purge
gpupdate /force
gpresult /r /scope computer
klist purge
runas /user:[your domain here]\[your user name here] cmd.exe
klist.exe sessions | findstr /i [your hostname here in the new opened cmd window]
Повторите эти команды в зависимости от указанного условия, а затем перезагрузите компьютер.
Я могу решить эту проблему, сбросив домен (сервер, являющийся сервером домена, но не связанный с SQL Server, кроме управления доменом), за которым следуют клиентские машины.
Спасибо всем за вашу немедленную поддержку!
У нас была эта проблема в тех случаях, когда мы меняли пользователя службы с Domain1\ServiceUser на Domain2\ServiceUser. SPN остаются зарегистрированными в Domain1\ServiceUser и никогда не регистрируются в Domain2\ServiceUser. Мы зарегистрировали имена участников-служб в Domain2\ServiceUser, но проблема осталась. Затем мы удалили имена участников-служб в Domain1\ServiceUser, и проблема была решена.
Если вы выполняете код, не написанный на вашем компьютере, который запускается на компьютере, используемом вашим рабочим партнером, но не на вашем, проверьте файл web.config. Возможно, в каком-то месте должно быть пустое имя вашего коллеги под именем userPrincipalName. Это происходит автоматически, когда мы создаем сервисную ссылку на проект в VS.
Был действительно странный случай этого; Все веб-продукты, в которых были строки подключения, содержащие имя компьютера с Windows-сервером SQL-сервера, работали нормально, но продукты, имевшие полное доменное имя с подключенным внутренним доменом, выдавали ошибку SSPI. то есть COMPUTERNAME vs COMPUTERNAME.DOMAIN (ping всегда работал как положено)
Это ТОЛЬКО создавало проблемы, когда использовался новый сервер SQL и файлы хостов указывали как имя компьютера, так и имя компьютера в качестве полного доменного имени для строк подключения.
Решением в этом случае было установить все строки подключения только на имя компьютера, удалив ссылки на домен.
SQL: 2008R2 SQL2012
IIS: 2008R2