У меня нет доступа к настройкам Active Directory и нет доступа для изменения чего-либо на связанном сервере.
Из всего, что я прочитал, похоже, что это означает, что я не могу использовать Kerberos - что является большой проблемой, потому что я не знаю, как использовать связанный сервер без него.
Есть ли способ подключиться к связанному серверу без Kerberos? (или какой-то способ включить Kerberos без администратора в AD?)
Точное описание проблемы
Когда я подключаюсь к связанному серверу сидя перед моим сервером, работает нормально; но когда я пытаюсь подключиться к связанному серверу с любого другого компьютера (делегируя через мой сервер), выдает ошибку:
Ошибка входа в систему для пользователя NT AUTHORITY \ ANONYMOUS LOGON. (Microsoft SQL Server, ошибка: 18456)
Кажется, что это "проблема двойного прыжка, "и обычным решением является включение Kerberos, для которого требуется доступ к AD и связанному серверу.
Я получаю ту же ошибку, когда устанавливаю безопасность "Сделано с использованием текущего контекста безопасности входа, "и я не могу использовать"Сделано с использованием этого контекста безопасности"потому что, похоже, используется SQL-аутентификация (которая не включена на связанном сервере) вместо NTLM
Это действительно случай ограниченного делегирования (т. Е. «Двойной прыжок»). Нет настройки, которую можно изменить, чтобы это работало. Если бы он существовал, это было бы по определению ошибкой, поскольку это нарушило бы политику домена по ограничению делегирования только доверенным учетным записям. Поэтому, если вы не внесете изменения в AD, чтобы пометить SQL Server «посередине» как доверенный для делегирования, вам не удастся выполнить двойной прыжок. И любая другая работа, которую я предлагаю вам, даст мне возможность помочь вам нарушить политику вашего домена. Поскольку кажется, что вы понимаете техническую проблему, я бы рекомендовал вам стучать в нужные двери: к хозяевам вашего домена и / или заинтересованным сторонам ваших требований.
для использования связанного сервера без Kerberos единственный вариант - это логины SQL. если это не вариант, вам действительно стоит попробовать исправить аутентификацию Kerberos.
Вы должны выяснить, какая учетная запись запускает службу sql server. если это учетная запись домена, вам следует попросить кого-нибудь зарегистрировать SPN для пользователя.
если у вас есть доступ к любому серверу Windows 2008 в домене с пользователем домена, вы должны запустить эту команду CMD, чтобы проверить, что уже зарегистрировано (доступ для чтения разрешен).
setspn -l [sqlservicedomainaccount]
вы должны проверить setspn -l sqlmachinename и посмотреть, зарегистрирован ли он, а также sqlserviceaccount. Поскольку в этом реестре не должно быть дублирующихся элементов, вам сначала нужно удалить, а затем зарегистрировать новый.
Затем попросите кого-нибудь в сети зарегистрировать этот spn (так как службу необходимо перезапустить после регистрации, вы должны сделать это только во временном окне)
Выбрано ли в диалоговом окне связанного сервера в разделе безопасности «Использовать текущий контекст безопасности для входа»?
Настроена ли ваша учетная запись Windows на сервере, к которому вы пытаетесь подключиться?
Вы можете использовать процедуру sp_addlinkedsrvlogin для сопоставления имени входа Windows на узле SQL Server с именем входа SQL на удаленном сервере. Это не работает для групп Windows.