Вопрос:
При попытке подключения к экземпляру SQL Server 2008 с помощью Management Studio я получаю следующую ошибку:
Ошибка входа. Вход от ненадежный домен и не может быть использован с проверкой подлинности Windows. (Microsoft SQL Server, ошибка: 18452)
Я могу войти с помощью SQL Authentication без проблем. Я получаю эту ошибку внезапно. Я включил аутентификацию смешанного режима.
Есть ли у кого-нибудь опыт?
Дополнительная информация:
64-разрядная версия SQL
Enterprise Edition
В Windows 2003 Server
Лучший ответ:
Проблема была вызвана отсутствующим сервером Active Directory, который, конечно же, не смог аутентифицировать учетную запись Windows. Благодарим вас за помощь.
Ответ №1
Другая причина, по которой это может произойти (только что случилось со мной)… истекает срок действия пароля пользователя. Я не понимал этого до тех пор, пока не попытался удалиться от фактического сервера, и мне было предложено изменить мой пароль.
Ответ №2
Для меня это произошло, когда я редактировал пустой файл drivers/etc/hosts и добавил запись для локального веб-сайта, но пренебрегал добавлением 127.0.0.1 localhost
Ответ №3
“Проблема была вызвана отсутствующим сервером Active Directory, который, конечно же, не смог аутентифицировать учетную запись Windows”
Это не “конечно”, потому что, если AD недоступен, аутентификация Kerberos возвращается к NTLM (учетные данные учетной записи домена кэшируются локально, можно войти в систему с ним, даже если AD/Kerberos недоступен). Я предполагаю, что вы возможно, 2 одновременных условия для этого отказа:
- SQL Server не является локальным (на другом компьютере)
- Доверие настроено только “Kerberos”
или другой конкретной конфигурации сети безопасности/сервера/AD/машины
Ответ №4
У меня была эта проблема для экземпляра сервера на моей локальной машине, и я обнаружил, что это было потому, что я указывал на 127.0.0.1 с чем-то другим, кроме “localhost” в моем файле hosts. В моем случае можно исправить эту проблему двумя способами:
- Очистить оскорбительную запись, указывающую 127.0.0.1 в файле хостов
- используйте “localhost” вместо другого имени, которое в файле hosts указывает на 127.0.0.1
* Это работало только для меня, когда я запускал экземпляр sql-сервера в своем локальном поле и пытался получить доступ к нему с того же компьютера.
Ответ №5
Для всех, кто сталкивается с этим, у меня было это в файле hosts:
127.0.0.1 localhost 127.0.0.1 customname
и мне нужно было это:
127.0.0.1 localhost 127.0.0.1 localhost customname Ответ №6
Убедитесь, что вы не подключены к VPN на другом доменепользователь. Или, наоборот, убедитесь, что вы подключены, если это то, что требуется.
Ответ №7
попробуйте использовать другой действительный логин с помощью команды RUNAS
runas /user:domainuser «C:Program FilesMicrosoft SQL Server90ToolsBinnVSShellCommon7IDEssmsee.exe» runas /user:domainuser «C:WINDOWSsystem32mmc.exe /s «C:Program FilesMicrosoft SQL Server80ToolsBINNSQL Server Enterprise Manager.MSC»» runas /user:domainuser isqlw Ответ №8
Для меня это произошло потому, что я не добавлял учетную запись, чтобы иметь роли, которые я хотел использовать для самой базы данных SQL. А также из-за неудачных попыток пароля через учетную запись блокировки проблемы копирования.
Ответ №9
Хорошо, полностью ответ от меня. Я получал эту ошибку из среды разработки, размещенной на виртуальной машине 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 минут, посмотрев несколько снимков экрана, которые я ему отправил. Проблема в том, что часы контроллеров домена были установлены неправильно! Не мог поверить. Серверы настроены для сети только для хоста, поэтому для синхронизации часов с ним нет Интернета. Это также объясняет, почему возврат к предыдущему снимку, когда я знаю, что система работает, не решила проблему.
Изменить: установка гостевых дополнений на сервере синхронизирует гостевые часы с хостом.
Ответ №10
В драйвере jTDS, указанном USENTLMV2, по умолчанию установлено значение false. Установка этого значения в “true” в моем программном обеспечении db (DBVisualizer) решила его.
Ответ №11
Другой сценарий, где вы можете увидеть это, – это когда вы пытаетесь подключиться к другому SQL-серверу из сеанса SSMS, который уже был зарегистрирован при изменении пароля. Последовательность событий может выглядеть примерно так:
- RDP к серверу-A (ваш SQL-сервер), откройте SSMS и войдите в систему
- RDP для сервера-B в том же домене и сменить пароль
- Вернитесь к сеансу RDP на сервере-A и через SSMS попытайтесь добавить еще одну БД в существующую группу доступности AlwaysOn. При подключении к репликам вы получаете “недоверенный домен” -login-error
Чтобы решить проблему, просто выйдите из системы и зайдите в
Ответ №12
Я пытаюсь войти в SQL Server 2008 из учетной записи домена. SQL Server 2008 размещен на другом компьютере рабочей группы, который не является частью домена. Как ни странно, на сервере рабочей группы, где работает SQL Server 2008, мне пришлось перейти в System Properties | Имя компьютера (вкладка) | Изменить (кнопка) | Изменение имени компьютера | Подробнее… (кнопка) и введите “Первичный DNS-суффикс этого компьютера” (он был пустым, поэтому введите нужный суффикс для вашей сети) и установите флажок “Изменить первичный DNS-суффикс при изменении членства в домене”. Это позволило завершить процесс проверки подлинности Windows при входе в SQL Server 2008.
Ответ №13
Мне пришлось использовать netonly, чтобы заставить это работать на современных Windows:
runas /netonly /user:domainuser «C:Program Files (x86)Microsoft SQL Server110ToolsBinnManagementStudiossms.exe»
Ответ №14
Другая причинa > кто-то изменил пароль для пользователя SQL по умолчанию
это случилось со мной пару минут назад, переключившись на новый контроллер домена…
Ответ №15
чтобы обеспечить аутентификацию Windows, оба компьютера должны находиться в одном домене. чтобы позволить студиям управления передавать текущие учетные данные и аутентифицироваться в ящике sql
Ответ №16
Для меня мне нужно отключить (сменить рабочую группу/домен) из Домена и снова подключиться.
Ответ №17
Я заменил соединительную строку и начал работать
от
main_sqlconnection = New SqlConnection(«Data Source=Server1SQLEXPRESS;Initial Catalog=Master;Trusted_Connection=True»)
к
main_sqlconnection = New SqlConnection(«Data Source=Server1SQLEXPRESS;Initial Catalog=Master;User ID=ARM;Password=1;»)
Я создал учетную запись User ID=User;Password=1; в Microsoft SQL Server Management Studio: нажмите “Безопасность” и добавьте нового пользователя.
Ответ №18
И еще одна возможная причина:
В новой созданной локальной учетной записи на сервере БД были установлены: “Пользователь должен изменить пароль при следующем входе”.
Ответ №19
Сначала вам нужно включить учетную запись sa и войти в свою студию управления SQL с учетной записью sa (пожалуйста, выберите SQl Server authentication).
После входа в систему с учетной записью sa перейдите к security, щелкните правой кнопкой мыши на logins, выберите new login, выберите SQL Server authentication, создайте имя пользователя (no / или любые другие специальные символы, просто имя), затем дайте ему пароль, подтвердите пароль и внизу этой страницы выберите свою базу данных по умолчанию.
Перейдите к logins, щелкните правой кнопкой мыши пользователя, которого вы создали, и нажмите properties.
Перейдите в Server Roles и выберите роли, которые вы хотите предоставить создаваемому пользователю.
Нажмите OK и вернитесь к login properties, нажмите User Mapping, дважды щелкните по базе данных, к которой вы хотите сопоставить этого пользователя, и выберите членство в роли базы данных для этой базы данных в нижнем окне.
Ответ №20
Вот что укрепило это для меня:
Свойства сетевого подключения
Нажмите “Протокол Интернета 4 (TCT/IPv4)”.
Нажмите кнопку “Свойства”.
Нажмите кнопку “Дополнительно”.
Выберите вкладку “DNS”.
Удалите текст в “DNS-суффиксе для этого соединения”.
Ответ №21
Я также не смог удаленно подключиться к SQL-серверу. И SQL-сервер, и удаленный сервер, где находятся в одном домене. За несколько дней до этого меня попросили сменить пароль.
Перезагрузка как SQL-сервера, так и удаленного сервера, на котором я пыталась получить доступ к SQL-серверу, сделала трюк для меня.
Ответ №22
В нашем случае именно разработчик запускал пул приложений под своей учетной записью и имел reset свой пароль, но забыл изменить его в пуле приложений. Duh…
Ответ №23
В моем случае сервер был отключен в контроллере домена. Я зашел в COMPUTERS OU в Active Directory, щелкнул правой кнопкой мыши на сервере, включил его, затем сделал gpupdate/force с SQL-сервера. Это заняло минутку, но, в конце концов, она работала.
Ответ №24
В моем случае в файле хоста имя машины жестко закодировано с более старым IP-адресом.
Я заменяю старый IP-адрес новым, проблема решена.
Расположение хост файла
WindowsDrive:WindowsSystem32DriversEtcхостов
Сделанные изменения
159.xx.xx.xxx Имя_каталога
Ответ №25
Ничто из этого не помогло мне. Мне нужно было:
В SQL Server Management Studio на экране входа в систему выберите Функции → В разделе “Сеть” измените сетевой протокол на “Именованные каналы”.
Кроме того, что мне нужно было сделать, чтобы заставить его работать с параметром <default>, было отключить беспроводную сеть (машина также была подключена к проводному языку).
Ответ №26
Мое исправление заключалось в том, чтобы изменить файл web.config, чтобы он соответствовал моему новому имени сервера для SQL Connection (ИТ-безопасность только что переименовала netdom в моем окне разработки.
Ответ №27
У меня была неправильная запись в файле hosts в C:WindowsSystem32driversetc
[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 Ответ №28
Я исправил эту проблему на машине, отключив проверку проверки петли:
- Отредактируйте реестр Windows: Пуск → Выполнить > Regedit
- Перейдите к: HKLMSystemCurrentControlSetControlLSA
- Добавьте значение DWORD под названием “DisableLoopbackCheck”
- Установите это значение в 1
Ответ №29
Я использовал псевдоним для экземпляра SQL Server, который указывал на “127.0.0.1”.
Вместо этого он заменил его на “localhost”.
