Назад | Перейти на главную страницу

Не удается настроить Kerberos для служб Reporting Services

Контекст

Я пытаюсь настроить Kerberos в домене для двойной аутентификации. Итак, вот машины и их роли:

Я хочу мое client01 подключиться к server01 и настроить источник данных, расположенный на server02 с использованием интегрированной безопасности. Так как NTLM не может передавать учетные данные так далеко, мне нужно настроить Kerberos, чтобы включить двухэтапную аутентификацию. Служба отчетов запускается учетной записью службы сетевой службы и настраивается только с RSWindowsNegotiate варианты аутентификации.

Проблема

Я не могу передать client01 учетные данные для server02 при настройке источника данных на server01. Поэтому я получаю ошибку:

Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.

Итак, я продолжил dc01 и делегировал полное доверие к любой услуге server01 но это не устранило проблему. Хочу заметить, что я не настраивал SPN для server01 поскольку служба Reporting Service запускается сетевой службой, и из того, что я читал в Интернете, когда службы Reporting Services запускаются с сетевой службой, SPN автоматически регистрируются. Моя проблема в том, что даже если я хочу настроить SPN вручную, я не знаю, где мне их устанавливать. На dc01 или на server01?

Поэтому я пошел немного дальше и попытался отследить эту проблему. Насколько я понимаю Kerberos, когда я пытаюсь подключить источник данных, в сети должно произойти следующее:

client01 ---- AS_REQ ---> dc01
         <--- AS_REP ---- 

client01 ---- TGS_REQ ---> dc01
         <--- TGS_REP ----

client01 ---- AP_REQ ---> server01
         <--- AP_REP ----

server01 ---- TGS_REQ ---> dc01
         <--- TGS_REP ----

server01 ---- AP_REQ ---> server02
         <--- AP_REP ----

Итак, я захватил мою локальную сеть с помощью Wireshark, но всякий раз, когда я пытаюсь настроить источник данных из client01 на server01 передать мои верительные грамоты server02мой клиент никогда не отправляет AS_REQ или TGS_REQ в KDC на dc01.

Вопросы

Так может ли кто-нибудь сказать мне, следует ли мне настраивать SPN и на каком компьютере это нужно настраивать?

Также почему client01 никогда не запрашивайте TGT или TGS для моего KDC. Как вы думаете, что-то не так с ролью DC dc01?

SPN должны быть настроены на компьютере или пользовательском объекте, представляющем удостоверение службы. Если рассматриваемая служба на server01 работает под сетевой службой, вы должны убедиться, что для учетной записи компьютера, представляющей server01, настроены правильные SPN. Вы можете проверить это, запустив "setspn -l server01". Саму команду можно запустить из любого места, так как она будет взаимодействовать с контроллером домена и проверять атрибут LDAP объекта serviceprincipalname. Таким образом, вы можете запустить ее из dc01, server01 или из любого другого места, если у вас есть двоичный файл setspn.exe. можно увидеть весь синтаксис, запустив "setspn /?"

Если они не настроены (как проверено приведенной выше командой), вы должны добавить их, используя тот же двоичный файл, но с другим синтаксисом. Пример синтаксиса для переключателя "-A", который добавляет значения путем запуска "setspn -A http/server01 server01". В этом примере предполагается, что порт, под которым работает служба, - 80 или 443.

Вы должны быть осторожны, чтобы убедиться, что SPN не зарегистрировано где-либо еще в лесу AD, поскольку SPN должно быть уникальным. переключатель "-Q" может проверять наличие SPN где угодно, когда вы делаете что-то вроде "setspn -F -Q http/server01".

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

Всегда очищать кеш DNS на клиенте "ipconfig /flushdns"и кеш Kerberos"klist purge"перед выполнением трассировки сети для устранения неполадок. Это покажет трафик разрешения имен для местоположения KDC и попытается получить билет, если он не кэширован локально.

http://msdn.microsoft.com/en-us/library/cc281253.aspx выглядит как хороший ресурс по SSRS. Для получения помощи Kerberos в устранении неполадок см. Сообщения блога askds, предназначенные для Kerberos, начиная с http://blogs.technet.com/b/askds/archive/2008/06/13/understanding-kerberos-double-hop.aspx. Тогда просмотрите http://blogs.technet.com/b/askds/archive/2008/05/29/kerberos-authentication-problems-service-principal-name-spn-issues-part-1.aspx и другие статьи по своему усмотрению.

DC01 будет выдавать билеты при условии, что служба KDC запущена и может найти соответствующий SPn, зарегистрированный в его базе данных, и при условии, что он не дублируется где-либо еще в лесу. Значение должно быть уникальным. "setspn -x -f"можно просмотреть, чтобы проверить, не повторяется ли интересующее значение в лесу.