Проверяющая сторона ADFS - конфигурация конечной точки
Я работаю над настройкой лабораторной среды с двумя Windows Server (виртуальными) машинами, которые взаимодействуют в конфигурации AD FS.
- WIN-TORHJGJ7N: Windows Server 2012 под управлением AD FS 2.0. Также контроллер домена.
- ADFSSERVERPROXY: Несмотря на название, на самом деле не настроен как прокси (пока). Самое главное, он содержит веб-приложение, работающее на
https://adfstest.sub.domain.com/, Он защищен агентом Windows FS на основе токенов AD FS, как показано на рисунке ниже. Веб-приложение представляет собой простую программу "hello world", поэтому никакой логики аутентификации на этой стороне нет.
На моей первой машине я хочу настроить доверие проверяющей стороны, но у меня возникают проблемы с настройкой конечных точек. Я старался http://sts1.sub.domain.com/adfs/ls/, http://adfstest.sub.domain.com/ и другие варианты, но на самом деле я просто не уверен, что намеревался пойти туда. Это произвольное значение, или оно должно указывать на конкретное место? Если это должно указывать на мое веб-приложение, мне нужно реализовать логику аутентификации в приложении?
Итак, коротко говоря: что ожидается от конечной точки доверия проверяющей стороны в этой настройке?
РЕДАКТИРОВАТЬ:
Одна из ошибок, которые я получаю, когда указываю конечную точку на произвольный URL на стороне приложения (https://adfstest.sub.domain.com/), это следующее:
Веб-агент AD FS для приложений на основе маркеров Windows NT обнаружил серьезную ошибку. Файлы cookie, которые были представлены клиентом, не могут быть проверены.
Это условие возникает, когда клиент представляет правильно сформированные файлы cookie, которые недействительны. Если известно, что клиент является действительным пользователем, эта ошибка может быть вызвана временной проблемой. Например, свойства доверия (например, сертификаты) могли недавно измениться, или статус отзыва может быть недоступен из центра сертификации.
Действия пользователя Найдите дополнительные события в журнале безопасности, которые могут содержать более подробную информацию. Рассмотрите возможность включения аудита отказов на этом веб-сервере, если аудит еще не включен.
1 ответ
Эта лаборатория только для вашего обучения или для подтверждения концепции, предназначенной для дальнейшего использования в производстве?
Агентский подход на основе маркеров, который вы пытаетесь реализовать, - это метод старой школы, введенный в 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, но здесь она полностью применима.