У меня есть служба, работающая на одном сервере (A), который традиционно работает под локальной системной учетной записью. Теперь SQL-сервер переехал с сервера A на новый сервер B.
Я попытался добавить учетную запись компьютера сервера a [domain \ servera $] к серверу SQL на сервере B и дал ему все права, которые он мог бы пожелать (sa), но служба по-прежнему не может подключиться.
Ошибка, которую я нахожу в журнале обслуживания на тот момент, следующая
enbase
ODBC database error:
Connect()
szSqlState = 28000
pfNativeError = 18456
szErrorMsg = [Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
pcbErrorMsg = 100
LoginId = !!UnknownUser!!
ODBCRowNumber = 0
SSrvrLine = 0
SSrvrColumn = 0
SSrvrMsgState = 0
SSrvrSeverity = 0
SSrvrProcname =
SSrvrSrvname =
Я не знаю, почему служба считает, что входит в систему как АНОНИМНЫЙ ВХОД.
Любые идеи?
Обновление: я написал тестовую службу, работающую в локальной системе, которая вызывает это сообщение в профилировщике SQL:
«Не удалось войти в систему для пользователя NT AUTHORITY \ ANONYMOUS LOGON. Причина: проверка доступа к серверу на основе токена не удалась из-за ошибки инфраструктуры. Проверьте предыдущие ошибки».
Обновление: теперь я думаю, что это проблема Kerberos. Kerberos не работает, потому что учетная запись домена, под которой работает SQL, не может зарегистрировать свои имена участников-служб (setspn -L показывает это), и, следовательно, Kerberos нельзя использовать, и используется NTLM, а NTLM не работает для домена \ компьютера $ для некоторых причина.
Наконец, ERRORLOG показывает, что SQL-сервер регистрирует ошибку о невозможности зарегистрировать SPN для службы SQL Server. Думаю, это подтверждает мою теорию.
Обновление: я думаю, что решение состоит в том, чтобы предоставить учетной записи домена, под которой работает SQL Server, доверие для делегирования в AD, чтобы он мог регистрировать свое SPN при запуске SQL Server.
Ошибка входа для пользователя NT AUTHORITY \ ANONYMOUS LOGON
Вы не используете учетную запись компьютера для подключения ...
LoginId = !! UnknownUser !!
Вы не предоставляете правильные учетные данные.
Вы знаете, что то, что внешне известно как DOMAIN \ MACHINE $, внутри NT Authority\Network Service аккаунт, надеюсь :)
Я считаю, что эта проблема была решена путем создания SPN для учетной записи, под которой работает SQL-сервер. Если SPN существует, клиент может пройти проверку подлинности с помощью Kerberos и войти в систему как домен учетной записи домена клиентского компьютера $ \ clientcomputer $, которому может быть предоставлен соответствующий доступ к серверу SQL.