Ошибка подключения к SQL Server 2005: не удается создать контекст SSPI

Раньше я иногда получал эту ошибку при подключении к локальному SQL Server с проверкой подлинности Windows. К сожалению, я так и не исправил - исчезло, когда я переустановил окна.

Я думаю, что для исправления использовалась перезагрузка - вы пробовали это? Не совсем лучшее решение, я знаю: P

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

-Эдуд

Попробуйте синхронизировать дату и время с датой вашего домена. Проблема SSPI может быть связана с проблемами аутентификации Active Directory, некоторые из которых связаны с изменением даты и времени. Это очень просто проверить и исправить. Попробуйте!

Существует статья базы знаний Microsoft, в которой рассматриваются многие причины возникновения этой области (KB811889) по следующему URL-адресу: http://support.microsoft.com/kb/811889.

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

Недавно у меня была именно эта проблема, когда я получал эту ошибку только при аутентификации с определенными учетными записями, но не с другими. В конечном итоге то, что было причиной моей проблемы, не было упомянуто ни в одной статье базы знаний или статье, которую я нашел в сети, но методом проб и ошибок я обнаружил, что когда учетная запись, используемая через аутентификацию SSPI для SQL Server (2k8), оказалась в большом количестве групп (в моем случае более 250) вы получите ошибку «Невозможно создать контекст SSPI». Я подозреваю, что это как-то связано с переполнением токена безопасности, который использует Kerberos, и сталкивался с похожими странными проблемами аутентификации для учетных записей пользователей в большом количестве групп.

У меня возникает проблема, когда на моей клиентской машине время установлено иначе, чем на сервере или машине AD (я пытался проверить будущее).

Краткий ответ: вы недавно меняли пользователя, от имени которого работает служба? Произошел сбой системы?

Длинный ответ: Я знаю, что это устарело, но я хочу опубликовать свой опыт, который у меня только что был. Мы часами гуглили и не нашли ничего работающего. В конце концов мы столкнулись с рядом действий, которые могли вызвать это:

Если вы измените пользователя, от имени которого работает сервер Sql (например, из локальной системы в домен usr), и выполните определенные обновления, а сервер не перезагрузится безопасно - вы получите это.

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

Причиной нашей проблемы было то, что мы выполнили обновление и, по-видимому, узнали, что позволять серверу Sql работать как локальную систему - плохая практика, поэтому мы изменили его на пользователя домена. Мы никогда не перезагружались, а перезапускали службу. Через месяц делаем обновления. Не перезагружаемся. Проходит месяц, и из-за разрыва питания происходит неожиданное отключение сервера. Еще через месяц мы обнаруживаем проблему, потому что мы редко подключаемся к этой конкретной базе данных (что интересно, Sql Server 2008 работал нормально ... это был только 2005 год). Или ... по крайней мере, это лучшее, что мы когда-либо встречали.

Нашему администратору не нравится Vista и он любит винить во всем Vista (отказывается позволить нам тестировать Windows 7) ... поэтому он погуглил "sspi vista" или что-то вроде этого (я знаю, что у него были sspi и vista, но могло быть был еще один ... на случай, если вам нужно погуглить, это было хорошо), и наткнулся на статью, которая хорошо объясняла наш сценарий, после того, как у нас была встреча, мы все запомнили эти части и поместили эту картинку вместе.

На этой странице блога MSDN есть кое-что полезное по этому поводу ...

http://blogs.msdn.com/sql_protocols/archive/2006/12/02/understanding-kerberos-and-ntlm-authentication-in-sql-server-connections.aspx

Я исправил это, подключив диск к серверу, на котором запущен MSSQL. Похоже, это породило какое-то доверие, которое позволяет MSSQL подключаться без этой ошибки даже после перезагрузки.

В моем случае проблема была в синхронизации времени в доменной среде Windows 2003.

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

Поэтому, кроме времени на часах, проверьте также и часовые пояса.

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

После повторного открытия аккаунта все заработало.

br Янв