SQL Server возвращает ошибку "Ошибка входа для пользователя" NT AUTHORITY\ANONYMOUS LOGON ". в приложении Windows

Приложение, которое работает без проблем (и не занималось активной разработкой, сделанной на нем примерно через 6 месяцев или около того), недавно начало не работать с базой данных. Администраторы операций не могут сказать, что могло измениться, что могло бы вызвать проблему.

Клиентское приложение использует стробированную строку соединения с Integrated Security = True, но когда приложения пытаются создать соединение с базой данных, она выдает SQLException, в котором говорится: "Ошибка входа для пользователя" NT AUTHORITY\ANONYMOUS LOGON ".

Я могу войти в базу данных через Management Studio в этой учетной записи без проблем. Все, что я видел для этой проблемы, относится к проектам ASP.NET, и, по-видимому, это "проблема с двойным хопом", которая является клиентским приложением, лучше всего не проблема. Любая помощь будет принята с благодарностью.

Изменить

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

Ведущая теория: Сервер был перезапущен примерно неделю назад и не смог зарегистрировать имя участника-службы (SPN). Невозможность зарегистрировать SPN может привести к тому, что интегрированная проверка подлинности вернется в NTLM вместо Kerberos.

Ответ 1

Если ваша проблема связана со связанными серверами, вам нужно посмотреть на несколько вещей.

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

Во-вторых, вашей учетной записи службы должны быть доверены делегирование. Поскольку вы повторно изменили свою учетную запись службы, я подозреваю, что это преступник. (http://technet.microsoft.com/en-us/library/cc739474 (v = ws.10).aspx)

Вы упомянули, что у вас могут быть проблемы с SPN, поэтому не забудьте установить SPN для обеих конечных точек, иначе вы не сможете увидеть вкладку делегирования в AD. Также убедитесь, что вы находитесь в расширенном представлении в "Active Directory - пользователи и компьютеры".

Если вы еще не видите вкладку делегирования, даже после исправления вашего SPN, убедитесь, что ваш домен находится не в режиме 2000. Если это так, вы можете "повысить уровень функции домена".

Теперь вы можете пометить учетную запись как доверенную для делегирования:

В области сведений щелкните правой кнопкой мыши пользователя, которому вы хотите доверять и нажмите "Свойства".

Перейдите на вкладку "Делегация", выберите "Учетная запись" для делегирования установите флажок, а затем нажмите кнопку "ОК".

Наконец, вам также нужно будет установить все машины как надежные для делегирования.

Как только вы это сделаете, подключитесь к серверу sql и проверьте свои любимые серверы. Они должны работать.

Ответ 2

Во-первых: Моя проблема не такая же, как у вас, но этот пост - первое, что появляется в google для ошибки Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' в то время, когда я это написал. Решение может быть полезно для людей, которые ищут эту ошибку, поскольку я не нашел это конкретное решение в любом месте в Интернете.

В моем случае я использовал Xampp/Apache и PHP sqlsrv, чтобы попытаться подключиться к базе данных MSSQL с использованием проверки подлинности Windows и получил описанную вами ошибку Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. Наконец, я обнаружил, что проблема заключается в том, что сама служба Apache работает под пользователем "LOCAL SERVICE" вместо учетной записи пользователя, в которую я был зарегистрирован. Другими словами, он буквально использовал анонимную учетную запись. Решением было перейти в services.msc, щелкнуть правой кнопкой мыши службу Apache, перейти в "Свойства", перейти на вкладку "Вход в систему" и ввести учетные данные для пользователя. Это соответствует вашей проблеме, связанной с SPN, поскольку ваш SPN настроен для работы от определенного пользователя в домене. Поэтому, если правильный SPN не запущен, проверка подлинности Windows по умолчанию будет неправильным пользователем (вероятно, пользователь "LOCAL SERVICE" ) и даст вам анонимную ошибку.

Здесь, где он отличается от вашей проблемы. Ни один из компьютеров в локальной сети не находится в домене, они находятся только в рабочей группе. Чтобы использовать проверку подлинности Windows с рабочей группой, как компьютер с сервером (в моем случае MSSQL Server), так и компьютер с данными запроса службы (в моем случае Apache), необходимо иметь пользователя с одинаковым именем и идентичным паролем.

Подводя итог, ошибка Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' в обоих наших случаях, по-видимому, вызвана тем, что служба не запущена и/или нет для нужного пользователя. Обеспечение правильного SPN или другой службы выполняется, и под правильным пользователем следует решить анонимную часть проблемы.

Ответ 3

Я думаю, что, должно быть, некоторые изменения в группе AD использовались для аутентификации в отношении базы данных. Добавьте имя веб-сервера в домене формата \webservername $в группу AD, имеющую доступ к базе данных. Кроме того, попробуйте установить атрибут web.config в значение "false". Надеюсь, поможет.

РЕДАКТИРОВАТЬ. Идя тем, что вы отредактировали. Скорее всего, это означает, что протокол аутентификации вашего SQL Server отпал от Kerberos (по умолчанию, если вы использовали встроенную проверку подлинности Windows) в NTLM, Для использования имени участника службы Kerberos (SPN) необходимо зарегистрировать службу каталогов Active Directory. Название участника службы (SPN) - это уникальные идентификаторы для служб, работающих на серверах. Для каждой службы, использующей аутентификацию Kerberos, должен быть установлен SPN, чтобы клиенты могли идентифицировать услугу в сети. Он зарегистрирован в Active Directory под учетной записью компьютера или учетной записью пользователя. Хотя протокол Kerberos по умолчанию, если по умолчанию не удается, процесс проверки подлинности будет проверяться с использованием NTLM.

В вашем сценарии клиент должен делать tcp-соединение и, скорее всего, работает под учетной записью LocalSystem, и SPN не зарегистрирован для экземпляра SQL, поэтому используется NTLM, однако учетная запись LocalSystem наследуется из System Context вместо настоящий контекст, основанный на пользователях, таким образом, потерпел неудачу как "ANONYMOUS LOGON".

Чтобы устранить это, попросите администратора вашего домена вручную зарегистрировать SPN, если ваш SQL Server работает под учетной записью пользователя домена. Следующие ссылки могут помочь вам больше:
http://blogs.msdn.com/b/sql_protocols/archive/2005/10/12/479871.aspx
http://support.microsoft.com/kb/909801

Ответ 4

Одна из моих заданий SQL имела такую же проблему. Он включал загрузку данных с одного сервера на другой. Ошибка произошла из-за того, что я использовал учетную запись службы агента SQL Server. Я создал учетные данные, используя UserId (который использует проверку подлинности Windows), общий для всех серверов. Затем создайте прокси-сервер, используя эти учетные данные. Используется прокси-сервер в задании сервера sql, и он работает нормально.

Ответ 5

Вероятно, вам просто нужно указать имя пользователя и пароль в строке соединения и установить Integrated Security = false

Ответ 6

Попробуйте установить "Integrated Security = False" в строке подключения.

<add name="YourContext" connectionString="Data Source=<IPAddressOfDBServer>;Initial Catalog=<DBName>;USER ID=<youruserid>;Password=<yourpassword>;Integrated Security=False;MultipleActiveResultSets=True" providerName="System.Data.SqlClient"/>

Ответ 7

FWIW, в нашем случае (PHP) веб-сайт, работающий на IIS, показывал это сообщение при попытке подключения к базе данных.

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