Ошибка входа в систему Windows Auth SQL Server 2008: вход из ненадежного домена

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

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

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

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

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

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

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

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

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

127.0.0.1   localhost
127.0.0.1   customname

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

127.0.0.1   localhost
127.0.0.1   localhost   customname

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

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

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

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

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

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

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

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

Я исправил эту проблему на компьютере, отключив настройку проверки обратной связи:

1. Отредактируйте реестр Windows: Пуск -> Выполнить> Regedit.
2. Перейдите к: HKLM \ System \ CurrentControlSet \ Control \ LSA
3. Добавьте значение DWORD с именем DisableLoopbackCheck.
4. Установите это значение на 1

попробуйте использовать другой допустимый логин с помощью команды RUNAS

runas /user:domain\user “C:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\ssmsee.exe” 

runas /user:domain\user “C:\WINDOWS\system32\mmc.exe /s \”C:\Program Files\Microsoft SQL Server\80\Tools\BINN\SQL Server Enterprise Manager.MSC\”" 

runas /user:domain\user isqlw 

Для меня это произошло потому, что я не добавил учетную запись, чтобы иметь роли, которые я хотел бы использовать в самой базе данных SQL. А также из-за неудачных попыток ввода пароля через проблему копирования и вставки, блокирующую учетную запись.

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

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

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

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

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

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

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

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

Вас могут ввести в заблуждение относительно имени пользователя, которое вы используете локально. Так было в Windows 10 Home. Когда я смотрю на пользователей в панели управления, я вижу имя usrpc01 . Однако когда я печатаюnet config workstation , кажется, что имя пользователя - spc01 . Вроде кто-то переименовал пользователя, но внутреннее имя осталось без изменений.

Не зная, как исправить имя пользователя Windows (и имя папки под ним C:\Users, которое также относится к исходному внутреннему имени), я добавил новую учетную запись пользователя на свой сервер БД.

Я пытался войти в SQL Server 2008 из учетной записи домена. SQL Server 2008 размещен на другом компьютере рабочей группы, который не является частью домена. Как ни странно это звучит, на сервере рабочей группы, где работает SQL Server 2008, мне пришлось перейти в Свойства системы | Имя компьютера (вкладка) | Изменить (кнопка) | Изменение имени компьютера | Подробнее ... (кнопка) и введите «Первичный суффикс DNS этого компьютера» (он был пустым, поэтому введите желаемый суффикс для вашей сети) и установите флажок «Изменить основной суффикс DNS при изменении членства в домене». Это позволило завершить процесс проверки подлинности Windows при входе в SQL Server 2008.

Мне пришлось использовать netonly, чтобы заставить это работать в современной Windows:

runas /netonly /user:domain\user "C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\ssms.exe"

Другая причина> кто-то изменил пароль для пользователя SQL по умолчанию

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

У меня была неправильная запись в файле hosts под C:\Windows\System32\drivers\etc

[Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.

Убедитесь, что у вас есть запись, как показано ниже

127.0.0.1   localhost
127.0.0.1   localhost   servername

Я использовал псевдоним для экземпляра SQL Server, который указывал на «127.0.0.1». Вместо этого изменение на localhost помогло.

Если ваш Sql Server работает на сервере, который не является частью домена, и в строке подключения вы используете полное доменное имя (например, xyz.mypc.com) с Integrated Security = True, вам, возможно, придется переключиться на использование IP-адрес, MachineName (SERVER01) или точка (.), если он размещен локально.

Это сработало для меня, использование fqdn привело к указанной выше ошибке.

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

Для меня я должен отключиться (сменить рабочую группу / домен) от домена и снова подключиться.

И еще одна возможная причина: у новой созданной локальной учетной записи на сервере БД был установлен флаг: «Пользователь должен сменить пароль при следующем входе в систему».

Вот что исправило для меня: Свойства сетевого подключения Нажмите: «Протокол Интернета версии 4 (TCT / IPv4)». Нажмите кнопку «Свойства». Нажмите кнопку «Дополнительно». Выберите вкладку «DNS». Удалите текст в «DNS-суффиксе для этого подключения».

Мне тоже не удалось удаленно подключиться к SQL-серверу. И SQL-сервер, и удаленный сервер находятся в одном домене. А за несколько дней до этого меня попросили сменить пароль. Перезапуск SQL-сервера и удаленного сервера, с которого я пытался получить доступ к SQL-серверу, помог мне.

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

В моем случае сервер был отключен в контроллере домена. Я вошел в подразделение КОМПЬЮТЕРЫ в Active Directory, щелкнул правой кнопкой мыши на сервере, включил его, затем выполнил gpupdate / force с SQL-сервера. Это заняло некоторое время, но, наконец, это сработало.

В моем случае в файле хоста имя машины жестко закодировано со старым IP-адресом. Заменил старый IP на новый, проблема решена.

Расположение файла хоста

WindowsDrive: \ Windows \ System32 \ drivers \ etc \ hosts

Внесенные изменения 159.xx.xx.xxx MachineName

У меня ничего из вышеперечисленного не сработало. Что мне нужно было сделать, так это: в SQL Server Management Studio на экране входа в систему выберите «Параметры» >> В разделе «Сеть» измените сетевой протокол на «Именованные каналы».

Кроме того, чтобы заставить его работать с <default>настройкой , мне нужно было отключить беспроводную сеть (машина также была подключена к проводной сети).

Мое исправление состояло в том, чтобы изменить файл web.config, чтобы он соответствовал моему новому имени сервера для SQL Connection (IT Security только что переименовал netdom в моем окне разработки.