Ошибка входа в систему для проверки подлинности Windows SQL Server 2008: вход из недоверенного домена

Question

При попытке подключиться к экземпляру SQL Server 2008 с помощью Management Studio появляется следующая ошибка:

Ошибка входа. Логин от ненадежный домен и не может быть использован с аутентификацией Windows. (Microsoft SQL Server, ошибка: 18452)

Я могу войти в систему с использованием SQL-аутентификации без проблем. Я получил эту ошибку внезапно. У меня включена Аутентификация в смешанном режиме.

У кого-нибудь есть опыт с этим?

Дополнительная информация: 64-битная версия SQL Enterprise Edition В Windows 2003 Server

Answer 1

Другая причина, по которой это может произойти (только что случилась со мной) ... это истечение срока действия пароля пользователя. Я не осознавал этого до тех пор, пока не попытался выполнить удаленный доступ к реальному серверу и мне предложили сменить пароль.

Answer 2

Для меня это произошло, когда я отредактировал пустой файл drivers/etc/hosts и добавил запись для локального веб-сайта, но не добавил 127.0.0.1 localhost

Answer 3

Проблема была вызвана неработающим сервером Active Directory, который, конечно, не мог аутентифицировать учетную запись Windows. Спасибо за вашу помощь.

Answer 4

Для всех, кто сталкивался с этим, у меня было это в моем файле hosts:

127.0.0.1   localhost
127.0.0.1   customname

и мне нужно было, чтобы это было:

127.0.0.1   localhost
127.0.0.1   localhost   customname

Answer 5

"Проблема была вызвана неработающим сервером Active Directory, который, конечно, не мог аутентифицировать учетную запись Windows"

Конечно, это не так - потому что если AD недоступен, то аутентификация Kerberos возвращается к NTLM (учетные данные учетной записи домена кэшируются локально, с ним можно войти, даже если AD / Kerberos недоступен). возможно, 2 одновременных условия для этого сбоя:

• SQL Server не является локальным (на другом компьютере)
• Доверие настроено "Только Kerberos"

или другие конкретные настройки безопасности сети / сервера / AD / машины

Answer 6

У меня была эта проблема для экземпляра сервера на моем локальном компьютере, и я обнаружил, что это потому, что я указывал на 127.0.0.1 с чем-то отличным от "localhost" в моем файле hosts Есть два способа исправить эту проблему в моем случае:

1. Очистить ошибочную запись, указывающую на 127.0.0.1 в файле hosts
2. используйте «localhost» вместо другого имени в файле hosts, которое указывает на 127.0.0.1

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

Answer 7

Убедитесь, что вы не подключены к VPN в другом домене \ user . Или, наоборот, убедитесь, что вы подключены , если это то, что требуется.

Answer 8

Ладно, полностью ответь от меня. Я получал эту ошибку из среды разработки, размещенной на VM VirtualBox. Три сервера; SharePoint, SQL DB и контроллер домена. Серверу SharePoint не удалось подключиться к базе данных конфигурации. Я все еще мог подключиться через ODBC для проверки подлинности Sql, используя учетную запись SA, но не проверку подлинности Windows. Но этот пользователь с радостью войдет в систему SSMS на самом сервере sql. Я получил лучшее сообщение об ошибке из ODBC, а также, проверив сообщения о неудачной регистрации на сервере sql:

select text from sys.messages where message_id = '18452' and language_id = 1033

Не могу взять кредит на себя, потому что я обратился за помощью к одному из наших администраторов корпоративных систем, и он диагностировал ее примерно через 5 минут, посмотрев несколько скриншотов, которые я ему прислал. Проблема была в том, что часы контроллера домена были установлены неправильно! Не могу поверить. Серверы настроены для работы только в сети, поэтому у вас нет интернета для синхронизации часов. Это также объясняет, почему откат к более раннему снимку, когда я знаю, что система работала, не решил проблему.

Редактировать: Установка гостевых дополнений на сервере синхронизирует гостевые часы с хостом.

Answer 9

В драйвере jTDS есть настройка USENTLMV2, для которой по умолчанию установлено значение false. Установка этого значения на «true» в моем программном обеспечении БД (DBVisualizer) решила это.

Answer 10

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

1. RDP to Server-A (ваш SQL Server), откройте SSMS и войдите в систему
2. Перейдите на сервер-B в том же домене и измените пароль
3. Возврат к сеансу RDP на сервере A и попытка через SSMS добавить другую БД в существующую группу доступности AlwaysOn. При подключении к репликам вы получаете «недоверенный домен» -login-error

Чтобы решить, просто выйдите из системы и снова войдите в систему