При попытке подключения к экземпляру SQL Server 2008 с помощью Management Studio я получаю следующую ошибку:
Ошибка входа. Вход от ненадежный домен и не может быть использован с проверкой подлинности Windows. (Microsoft SQL Server, ошибка: 18452)
Я могу войти с помощью SQL Authentication без проблем. Я получаю эту ошибку внезапно. Я включил аутентификацию смешанного режима.
Есть ли у кого-нибудь опыт?
Дополнительная информация: 64-разрядная версия SQL Enterprise Edition В Windows 2003 Server
Проблема была вызвана отсутствующим сервером Active Directory, который, конечно же, не смог аутентифицировать учетную запись Windows. Благодарим вас за помощь.
Другая причина, по которой это может произойти (только что случилось со мной)... истекает срок действия пароля пользователя. Я не понимал этого до тех пор, пока не попытался удалиться от фактического сервера, и мне было предложено изменить мой пароль.
Для меня это произошло, когда я редактировал пустой файл drivers/etc/hosts и добавил запись для локального веб-сайта, но пренебрегал добавлением 127.0.0.1 localhost
"Проблема была вызвана отсутствующим сервером Active Directory, который, конечно же, не смог аутентифицировать учетную запись Windows"
Это не "конечно", потому что, если AD недоступен, аутентификация Kerberos возвращается к NTLM (учетные данные учетной записи домена кэшируются локально, можно войти в систему с ним, даже если AD/Kerberos недоступен). Я предполагаю, что вы возможно, 2 одновременных условия для этого отказа:
или другой конкретной конфигурации сети безопасности/сервера/AD/машины
У меня была эта проблема для экземпляра сервера на моей локальной машине, и я обнаружил, что это было потому, что я указывал на 127.0.0.1 с чем-то другим, кроме "localhost" в моем файле hosts. В моем случае можно исправить эту проблему двумя способами:
* Это работало только для меня, когда я запускал экземпляр sql-сервера в своем локальном поле и пытался получить доступ к нему с того же компьютера.
Для всех, кто сталкивается с этим, у меня было это в файле hosts:
127.0.0.1 localhost
127.0.0.1 customname
и мне нужно было это:
127.0.0.1 localhost
127.0.0.1 localhost customname
Убедитесь, что вы не подключены к VPN на другом домене\пользователь. Или, наоборот, убедитесь, что вы подключены, если это то, что требуется.
попробуйте использовать другой действительный логин с помощью команды 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. А также из-за неудачных попыток пароля через учетную запись блокировки проблемы копирования.
Хорошо, полностью ответ от меня. Я получал эту ошибку из среды разработки, размещенной на виртуальной машине 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 минут, посмотрев несколько снимков экрана, которые я ему отправил. Проблема в том, что часы контроллеров домена были установлены неправильно! Не мог поверить. Серверы настроены для сети только для хоста, поэтому для синхронизации часов с ним нет Интернета. Это также объясняет, почему возврат к предыдущему снимку, когда я знаю, что система работает, не решила проблему.
Изменить: установка гостевых дополнений на сервере синхронизирует гостевые часы с хостом.
В драйвере jTDS, указанном USENTLMV2, по умолчанию установлено значение false. Установка этого значения в "true" в моем программном обеспечении db (DBVisualizer) решила его.
Другой сценарий, где вы можете увидеть это, - это когда вы пытаетесь подключиться к другому SQL-серверу из сеанса SSMS, который уже был зарегистрирован при изменении пароля. Последовательность событий может выглядеть примерно так:
Чтобы решить проблему, просто выйдите из системы и зайдите в
Я пытаюсь войти в SQL Server 2008 из учетной записи домена. SQL Server 2008 размещен на другом компьютере рабочей группы, который не является частью домена. Как ни странно, на сервере рабочей группы, где работает SQL Server 2008, мне пришлось перейти в System Properties | Имя компьютера (вкладка) | Изменить (кнопка) | Изменение имени компьютера | Подробнее... (кнопка) и введите "Первичный 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"
Другая причинa > кто-то изменил пароль для пользователя SQL по умолчанию
это случилось со мной пару минут назад, переключившись на новый контроллер домена...
чтобы обеспечить аутентификацию Windows, оба компьютера должны находиться в одном домене. чтобы позволить студиям управления передавать текущие учетные данные и аутентифицироваться в ящике sql
Для меня мне нужно отключить (сменить рабочую группу/домен) из Домена и снова подключиться.
Я заменил соединительную строку и начал работать
от
main_sqlconnection = New SqlConnection("Data Source=Server1\SQLEXPRESS;Initial Catalog=Master;Trusted_Connection=True")
к
main_sqlconnection = New SqlConnection("Data Source=Server1\SQLEXPRESS;Initial Catalog=Master;User ID=ARM;Password=1;")
Я создал учетную запись User ID=User;Password=1; в Microsoft SQL Server Management Studio: нажмите "Безопасность" и добавьте нового пользователя.
И еще одна возможная причина: В новой созданной локальной учетной записи на сервере БД были установлены: "Пользователь должен изменить пароль при следующем входе".
Сначала вам нужно включить учетную запись sa и войти в свою студию управления SQL с учетной записью sa (пожалуйста, выберите SQl Server authentication).
После входа в систему с учетной записью sa перейдите к security, щелкните правой кнопкой мыши на logins, выберите new login, выберите SQL Server authentication, создайте имя пользователя (no / или любые другие специальные символы, просто имя), затем дайте ему пароль, подтвердите пароль и внизу этой страницы выберите свою базу данных по умолчанию.
Перейдите к logins, щелкните правой кнопкой мыши пользователя, которого вы создали, и нажмите properties.
Перейдите в Server Roles и выберите роли, которые вы хотите предоставить создаваемому пользователю.
Нажмите OK и вернитесь к login properties, нажмите User Mapping, дважды щелкните по базе данных, к которой вы хотите сопоставить этого пользователя, и выберите членство в роли базы данных для этой базы данных в нижнем окне.
Вот что укрепило это для меня: Свойства сетевого подключения Нажмите "Протокол Интернета 4 (TCT/IPv4)". Нажмите кнопку "Свойства". Нажмите кнопку "Дополнительно". Выберите вкладку "DNS". Удалите текст в "DNS-суффиксе для этого соединения".
Я также не смог удаленно подключиться к SQL-серверу. И SQL-сервер, и удаленный сервер, где находятся в одном домене. За несколько дней до этого меня попросили сменить пароль. Перезагрузка как SQL-сервера, так и удаленного сервера, на котором я пыталась получить доступ к SQL-серверу, сделала трюк для меня.
В нашем случае именно разработчик запускал пул приложений под своей учетной записью и имел reset свой пароль, но забыл изменить его в пуле приложений. Duh...
В моем случае сервер был отключен в контроллере домена. Я зашел в COMPUTERS OU в Active Directory, щелкнул правой кнопкой мыши на сервере, включил его, затем сделал gpupdate/force с SQL-сервера. Это заняло минутку, но, в конце концов, она работала.
В моем случае в файле хоста имя машины жестко закодировано с более старым IP-адресом. Я заменяю старый IP-адрес новым, проблема решена.
Расположение хост файла
WindowsDrive:\Windows\System32\Drivers\Etc\хостов
Сделанные изменения 159.xx.xx.xxx Имя_каталога
Ничто из этого не помогло мне. Мне нужно было: В SQL Server Management Studio на экране входа в систему выберите Функции → В разделе "Сеть" измените сетевой протокол на "Именованные каналы".
Кроме того, что мне нужно было сделать, чтобы заставить его работать с параметром <default>, было отключить беспроводную сеть (машина также была подключена к проводному языку).
Мое исправление заключалось в том, чтобы изменить файл web.config, чтобы он соответствовал моему новому имени сервера для SQL Connection (ИТ-безопасность только что переименовала netdom в моем окне разработки.
У меня была неправильная запись в файле 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".