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

Проверяющая сторона ADFS - конфигурация конечной точки

Я работаю над настройкой лабораторной среды с двумя (виртуальными) машинами Windows Server, которые взаимодействуют в конфигурации AD FS.

На своем первом компьютере я хочу настроить доверие проверяющей стороны, но у меня возникают проблемы с настройкой конечных точек. Я попытался http://sts1.sub.domain.com/adfs/ls/, http://adfstest.sub.domain.com/ и другие варианты, но на самом деле я просто не уверен, что там предполагается. Это произвольное значение или оно должно указывать на конкретное место? Если он должен указывать на мое веб-приложение, мне нужно реализовать логику аутентификации в приложении?

Итак, короче: каковы ожидаемые конечные точки доверия проверяющей стороны в этой настройке?

РЕДАКТИРОВАТЬ:
Одна из ошибок, которую я получаю, когда указываю конечную точку на произвольный URL-адрес на стороне приложения (https://adfstest.sub.domain.com/), заключается в следующем:

Веб-агент AD FS для приложений на основе токенов Windows NT обнаружил серьезную ошибку. Файлы cookie, представленные клиентом, не могут быть проверены.

Это условие возникает, когда клиент представляет правильно сформированные файлы cookie, которые не являются действительными. Если известно, что клиент является действующим пользователем, эта ошибка может быть вызвана временной проблемой. Например, свойства доверия (например, сертификаты) могут быть недавно изменены, или статус отзыва может быть недоступен в центре сертификации.

Действия пользователя Поищите в журнале безопасности дополнительные события, которые могут содержать дополнительные сведения. Рассмотрите возможность включения аудита отказов на этом веб-сервере, если он еще не включен.

Эта лаборатория предназначена только для вашего обучения или для некоторого подтверждения концепции, предназначенной для использования в дальнейшем в производстве?

Подход агента на основе токенов, который вы пытаетесь реализовать, - это старый метод, представленный в 2003 R2. Вы уверены, что вам нужно сделать это для производства?

Текущий способ объединения приложений - использование WIF. Видеть http://msdn.microsoft.com/en-us/library/hh987037(v=vs.110).aspx для образца с использованием последней версии WIF.

В этом образце при замене ссылок на

  • http://localhost:13922/wsFederationSTS/Issue с участием http://sts1.sub.domain.com/adfs/ls/ и
  • http://localhost:28503/ с участием http://adfstest.sub.domain.com/ и
  • 1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ1234 с хешем сертификата подписи токена AD FS, видимым при запуске командлета get-adfscertificate в AD FS

Также см http://www.cloudidentity.com/blog/2014/02/12/use-the-on-premises-organizational-authentication-option-adfs-with-asp-net-in-visual-studio-2013/ для и в конце примера использования WIF и AD FS. В этой статье показано использование AD FS на Windows Server 2012 R2, но здесь он идеально подходит.