SQL Server возвращает ошибку "Ошибка входа пользователя" NT AUTHORITYANONYMOUS LOGON"."в Windows приложения
приложение, которое работает без проблем (и не было активной разработки на нем около 6 месяцев или около того) недавно начал не удается подключиться к базе данных. Администраторы операций не могут сказать, что могло бы измениться, что вызвало бы проблему.
клиентское приложение использует жестко закодированную строку соединения со встроенной безопасностью=True, но когда приложения пытаются создать соединение с базой данных, оно выдает исключение SQLException " ошибка входа для пользователя "NT AUTHORITYANONYMOUS 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