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

контекст

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

  • client01: Windows 7 как клиент
  • dc01Windows Server 2008 R2 в качестве контроллера домена и DNS
  • server01: Windows Server 2008 R2 в качестве сервера отчетов (основной режим)
  • server02: Windows Server 2008 R2 как ядро ​​базы данных SQL Server

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

вопрос

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

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

Итак, я продолжил dc01 и делегировал полное доверие для любой услуги server01 но это не решило проблему. Я хочу заметить, что я не настроил SPN для server01 поскольку служба отчетов запускается сетевой службой и из того, что я прочитал в Интернете, когда службы отчетов работают с сетевой службой, имена участников-служб автоматически регистрируются. Моя проблема в том, что, даже если я хочу настроить имена участников-служб вручную, я не знаю, где мне нужно их настраивать. На 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,

Вопросы

Так может кто-нибудь сказать мне, если я должен настроить имена участников-служб и на какой машине он должен быть настроен?

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

Источник

1 ответ

Решение

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

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

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

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

Всегда очищать кэш DNS на клиентеipconfig /flushdns"и керберос кеш"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"может быть рассмотрен, чтобы проверить, является ли значение интереса дубликатом в лесу.

Источник
Другие вопросы по тегам