SQL Server возвращает ошибку «Ошибка входа пользователя» NT AUTHORITY\ANONYMOUS LOGON».»в Windows приложения
приложение, которое работает без проблем (и не было активной разработки на нем около 6 месяцев или около того) недавно начал не удается подключиться к базе данных. Администраторы операций не могут сказать, что могло бы измениться, что вызвало бы проблему.
клиентское приложение использует жестко закодированную строку соединения со встроенной безопасностью=True, но когда приложения пытаются создать соединение с базой данных, оно выдает исключение SQLException » ошибка входа для пользователя «NT AUTHORITY\ANONYMOUS LOGON».
Я могу войти в базу данных через Management Studio на этой учетной записи без проблем. Все, что я видел для этого вопроса, для ASP.NET проекты, и это, по-видимому, «проблема двойного прыжка», которая, будучи клиентским приложением, лучше не быть проблемой. Любая помощь будет очень признательна.
редактировать
клиентская машина и серверная машина, а также учетные записи пользователей находятся на одном и том же домен. Это происходит, когда Брандмауэр Windows выключен.
ведущая теория: Сервер был перезапущен около недели назад и не смог зарегистрировать имя участника-службы (SPN). Сбой регистрации SPN может привести к тому, что интегрированная проверка подлинности вернется к NTLM вместо Kerberos.
5 ответов
Если ваша проблема связана с серверами, вы должны смотреть на несколько вещей.
во-первых, ваши пользователи должны иметь делегирование включено, и если единственное, что изменилось, это, вероятно, они делают. В противном случае вы можете снять флажок «учетная запись чувствительна и не может быть делегирована» — это свойства пользователя в AD.
во-вторых, ваша учетная запись(ы) службы должна быть доверена для делегирования. Поскольку вы изменили учетную запись службы, я подозреваю, что это виновник. (http://technet.microsoft.com/en-us/library/cc739474 (v=ws.10).aspx)
вы упомянули, что у вас могут быть некоторые проблемы с SPN, поэтому обязательно установите SPN для обеих конечных точек, иначе вы не сможете увидеть вкладку делегирование в AD. Также убедитесь, что вы находитесь в расширенном виде в «Active Directory-пользователи и компьютеры.»
Если вы все еще не видите вкладку делегирование, даже после исправления SPN, убедитесь, что ваш домен не в режиме 2000. Если это так, вы можете «повысить уровень функции домена.»
на данный момент Вы можете пометить учетную запись как доверенную для делегирования:
в области сведений щелкните правой кнопкой мыши пользователя, которому вы хотите доверять делегирование и щелкните свойства.
перейдите на вкладку делегирование, выберите Учетная запись доверена для делегирования установите флажок и нажмите кнопку ОК.
наконец, Вам также нужно будет установить все машины как доверенные для делегирования.
после этого снова подключитесь к sql server и протестируйте понравившиеся серверы. Они должны работать.
во-первых: моя проблема не такая же, как ваша, но этот пост-первое, что появляется в google для Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON’ ошибка в то время, когда я писал это. Решение может быть полезно людям, ищущим эту ошибку, поскольку я не нашел этого конкретного решения нигде в интернете.
в моем случае я использовал Xampp / Apache и PHP sqlsrv, чтобы попытаться подключиться к базе данных MSSQL с помощью аутентификации Windows и получил Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON’ ошибка, которую вы описали. Я, наконец, нашел проблему быть самой службой Apache, работающей под пользовательской «локальной службой», а не учетной записью пользователя, в которую я вошел. Другими словами, он буквально использовал анонимный аккаунт. Было принято решение ехать в сервис.msc, щелкните правой кнопкой мыши службу Apache, перейдите к свойствам, перейдите на вкладку Вход в систему и введите учетные данные для пользователя. Это соответствует вашей проблеме, связанной с SPN, поскольку ваши SPN настроены для запуска от конкретного пользователя в домене. Поэтому, если правильный SPN не работает, windows аутентификация по умолчанию будет неправильным пользователем (вероятно, пользователем «локальной службы») и даст вам анонимную ошибку.
вот где это отличается от вашей проблемы. Ни один из компьютеров в локальной сети не находится в домене, они находятся только в рабочей группе. Чтобы использовать проверку подлинности Windows с рабочей группой, как компьютер с сервером (в моем случае MSSQL Server), так и компьютер с запросом данных службы (в моем случае Apache) должны иметь пользователя с идентичным именем и идентичный пароль.
подведем итоги: Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON’ ошибка в обоих наших случаях, по-видимому, вызвана службой, не работающей и/или не на правильном пользователе. Обеспечение правильного SPN или другой службы выполняется и под правильным пользователем должно решить анонимную часть проблемы.
Я думаю, что должно было быть некоторое изменение в группе AD, используемой для аутентификации в базе данных. Добавьте имя веб-сервера в формате domain\webservername$ в группу AD, имеющую доступ к базе данных. Кроме того, также попробуйте установить web.атрибут config для «false». Надеюсь, это поможет.
редактировать: исходя из того, что вы отредактировали.. скорее всего, это указывает на то, что протокол проверки подлинности вашего SQL Server откатился от Kerberos(по умолчанию, если вы использовали встроенную аутентификацию Windows) в NTLM. Для использования имени участника-службы Kerberos (SPN) необходимо зарегистрироваться в службе каталогов Active Directory. Имя участника-службы (SPNs) — это уникальные идентификаторы служб, работающих на серверах. Каждая служба, которая будет использовать проверку подлинности Kerberos, должна иметь набор SPN, чтобы клиенты могли идентифицировать службу в сети. Он зарегистрирован в Active Directory под учетной записью компьютера или пользователя. Хотя Протокол Kerberos по умолчанию, если по умолчанию не удается, процесс проверки подлинности будет опробован с помощью NTLM.
в вашем сценарии клиент должен устанавливать tcp-соединение, и он, скорее всего, работает под учетной записью LocalSystem, и для экземпляра SQL не зарегистрирован SPN, поэтому используется NTLM, однако учетная запись LocalSystem наследуется от системного контекста вместо истинного пользовательского контекста, таким образом, не удалось как «анонимный вход».
разрешить этот задать домен администратор вручную зарегистрировать SPN, если SQL Server работает под учетной записью пользователя домена. Следующие ссылки могут помочь вам more:
http://blogs.msdn.com/b/sql_protocols/archive/2005/10/12/479871.aspx
http://support.microsoft.com/kb/909801
у одного из моих заданий SQL была та же проблема. Он участвует uploadaing данных с одного сервера на другой. Ошибка произошла из-за использования учетной записи службы агента sql Server. Я создал учетные данные, используя идентификатор пользователя (который использует аутентификацию окна), общий для всех серверов. Затем создал Прокси, используя эти учетные данные. Используется прокси-сервер в задании sql server, и он работает нормально.
вам, вероятно, просто нужно указать имя пользователя и пароль в connectionstring и установить Integrated Security=false
Sql server nt authority iusr windows 10 что за пользователь
Вопрос
Добрый день.
Антивирусное ПО (Kaspersky Endpoint Security 10 для Windows) в системе мониторинга (KSC10) статистика «наиболее заражающее пользователи» NT AUTHORITY\система более 4 тыс алертов за сутки
пример:
UDS:DangerousObject.Multi.Generic 13 ноября 2017 г. 9:39:03 C:\Windows\31779272.exe неизвестно Результат: Удалено: UDS:DangerousObject.Multi.Generic Пользователь: NT AUTHORITY\система (Системный пользователь) Объект: C:\Windows\31779272.exe
UDS:DangerousObject.Multi.Generic 13 ноября 2017 г. 9:16:56 C:\Windows\33089992.exe неизвестно Результат: Удалено: UDS:DangerousObject.Multi.Generic Пользователь: NT AUTHORITY\система (Системный пользователь) Объект: C:\Windows\33089992.exe
Есть ли какая то возможно ограничить использование учётной записи NT AUTHORITY\система? Сеть доменная.
Ответы
Скорее всего, это у вас компьютеры кто-то по сети заражает: подключается по сети с правами администратора и копирует туда тело вируса (скорее всего, чтобы запустить его либо как службу, либо через WMI). Вариантов заражения тут два: либо производится подключение с правами администратора с заражённой машины, либо через использование уязвимости.
Чтобы найти, кто и откуда это делает по первому варианту, надо анализировать журнал событий безопасность на том компьютере, откуда пришло сообщение тревоги непосредственно перед (в промежутке порядка минуты, полагаю, может больше) временем возникновения тревоги: в событии успешного входа в систему будет указано под какими учётными данными произошло подключение, а если повезёт — то и с какого компьютера. Если подключение производится под учётными данными локального администратора, то, скорее всего, у локального администратора слабый пароль или одинаковый пароль на всех компьютерах. В таком случае поменяйте пароли на сложные и уникальные.
А по поводу использования уязвимостей (прищнаком чего будет отсутствие вхоодо по сети) нужно начать с того, что установить все обновления безопасности на все подверженные атакам компьютеры. Если не поможет (что вряд ли), то придётся анализировать сетевой трафик, чтобы установить источник атаки.
- Предложено в качестве ответа Vector BCO Moderator 18 ноября 2017 г. 21:16
- Помечено в качестве ответа Vector BCO Moderator 18 ноября 2017 г. 21:16
Все ответы
- Предложено в качестве ответа Alexander Rusinov Moderator 13 ноября 2017 г. 20:16
- Изменено Anahaym Moderator 13 ноября 2017 г. 20:58
Мсье, Вам не кажется что подразумевая «лечить систему» можно, а даже нужно, добавить конкретики в столь пафосном посте в столько серьезном триде ? Мы (сообщество микрософт) ведь люди взрослые ? О какой именно системе идет речь ? Системы проверки подлинности ? Системы аутентификации ? Системы шифрования ? Системы подключаемых библиотек azure ?
Мсье, Вам не кажется что подразумевая «лечить систему» можно, а даже нужно, добавить конкретики в столь пафосном посте в столько серьезном триде ? Мы (сообщество микрософт) ведь люди взрослые ? А ваш пост выглядит как «иди почини компьютер», о какой именно системе идет речь ? Системы проверки подлинности ? Системы аутентификации ? Системы шифрования ? Системы подключаемых библиотек ?
Как не прескорбно но лечить нужно ту систему, которая ОС.
Начало положено, есть хотя бы антивирус который хоть частично но отлавливает проблему, хотя судя по лоличеству срабатываний — антивирус ловит только часть проблемы. Вторая же часть живет и здравствует, внутри ОС.
Ограничить пользователя система нельзя да и смысла нет так как это равносильно стрельбе в ногу, с тем же успехом можно выключить ПК.
Из практических советов можно говорить о письмах в поддержку каспера, отключении зараженных машин от сети компании, вплоть до конфискации, и разбор полетов. Как только поймете как лечить — можно дальше предпринимать какие то действия.
Так же стоит помнить о необходимости установки обновлений ОС на оставшихся машинах, обновлении и активации проверок антивируса, включении UAC, смена админских паролей, настройке бекапов критичных сервисов и пр. бестпрактисы которые многие игнорируют.
Дабы попробовать локализовать проблему проверяйте службы, отключая все что не подписано сертификатами МС, проверяйте шедульные задачи, парки автозапуска, ветки реестра автозапуска и пр.
The opinion expressed by me is not an official position of Microsoft
Sql server nt authority iusr windows 10 что за пользователь
Question
Добрый день.
Антивирусное ПО (Kaspersky Endpoint Security 10 для Windows) в системе мониторинга (KSC10) статистика «наиболее заражающее пользователи» NT AUTHORITY\система более 4 тыс алертов за сутки
пример:
UDS:DangerousObject.Multi.Generic 13 ноября 2017 г. 9:39:03 C:\Windows\31779272.exe неизвестно Результат: Удалено: UDS:DangerousObject.Multi.Generic Пользователь: NT AUTHORITY\система (Системный пользователь) Объект: C:\Windows\31779272.exe
UDS:DangerousObject.Multi.Generic 13 ноября 2017 г. 9:16:56 C:\Windows\33089992.exe неизвестно Результат: Удалено: UDS:DangerousObject.Multi.Generic Пользователь: NT AUTHORITY\система (Системный пользователь) Объект: C:\Windows\33089992.exe
Есть ли какая то возможно ограничить использование учётной записи NT AUTHORITY\система? Сеть доменная.
Answers
Скорее всего, это у вас компьютеры кто-то по сети заражает: подключается по сети с правами администратора и копирует туда тело вируса (скорее всего, чтобы запустить его либо как службу, либо через WMI). Вариантов заражения тут два: либо производится подключение с правами администратора с заражённой машины, либо через использование уязвимости.
Чтобы найти, кто и откуда это делает по первому варианту, надо анализировать журнал событий безопасность на том компьютере, откуда пришло сообщение тревоги непосредственно перед (в промежутке порядка минуты, полагаю, может больше) временем возникновения тревоги: в событии успешного входа в систему будет указано под какими учётными данными произошло подключение, а если повезёт — то и с какого компьютера. Если подключение производится под учётными данными локального администратора, то, скорее всего, у локального администратора слабый пароль или одинаковый пароль на всех компьютерах. В таком случае поменяйте пароли на сложные и уникальные.
А по поводу использования уязвимостей (прищнаком чего будет отсутствие вхоодо по сети) нужно начать с того, что установить все обновления безопасности на все подверженные атакам компьютеры. Если не поможет (что вряд ли), то придётся анализировать сетевой трафик, чтобы установить источник атаки.
- Proposed as answer by Vector BCO Moderator Saturday, November 18, 2017 9:16 PM
- Marked as answer by Vector BCO Moderator Saturday, November 18, 2017 9:16 PM
All replies
- Proposed as answer by Alexander Rusinov Moderator Monday, November 13, 2017 8:16 PM
- Edited by Anahaym Moderator Monday, November 13, 2017 8:58 PM
Мсье, Вам не кажется что подразумевая «лечить систему» можно, а даже нужно, добавить конкретики в столь пафосном посте в столько серьезном триде ? Мы (сообщество микрософт) ведь люди взрослые ? О какой именно системе идет речь ? Системы проверки подлинности ? Системы аутентификации ? Системы шифрования ? Системы подключаемых библиотек azure ?
Мсье, Вам не кажется что подразумевая «лечить систему» можно, а даже нужно, добавить конкретики в столь пафосном посте в столько серьезном триде ? Мы (сообщество микрософт) ведь люди взрослые ? А ваш пост выглядит как «иди почини компьютер», о какой именно системе идет речь ? Системы проверки подлинности ? Системы аутентификации ? Системы шифрования ? Системы подключаемых библиотек ?
Как не прескорбно но лечить нужно ту систему, которая ОС.
Начало положено, есть хотя бы антивирус который хоть частично но отлавливает проблему, хотя судя по лоличеству срабатываний — антивирус ловит только часть проблемы. Вторая же часть живет и здравствует, внутри ОС.
Ограничить пользователя система нельзя да и смысла нет так как это равносильно стрельбе в ногу, с тем же успехом можно выключить ПК.
Из практических советов можно говорить о письмах в поддержку каспера, отключении зараженных машин от сети компании, вплоть до конфискации, и разбор полетов. Как только поймете как лечить — можно дальше предпринимать какие то действия.
Так же стоит помнить о необходимости установки обновлений ОС на оставшихся машинах, обновлении и активации проверок антивируса, включении UAC, смена админских паролей, настройке бекапов критичных сервисов и пр. бестпрактисы которые многие игнорируют.
Дабы попробовать локализовать проблему проверяйте службы, отключая все что не подписано сертификатами МС, проверяйте шедульные задачи, парки автозапуска, ветки реестра автозапуска и пр.
The opinion expressed by me is not an official position of Microsoft