В нашей среде разработки у нас возникла проблема с нашими настроенными проверяющими сторонами в ADFS 2.0 это сбивает меня с толку. Он действует так, как будто существует черный список идентификаторов.
Прямо сейчас у нас есть 3 разработчика, которые разрабатывают против этого (новая конфигурация Win2kR2 для ADFS, Win7 Pro / VS2010 / MVC2 / C # для разработчиков). ADFS включен Domain2 пока все коробки разработчика включены Domain1. Domain2 трасты Domain1 но не наоборот (не то чтобы это важно). Я создал 3 траста, по одному на каждого разработчика. Конечная точка доверия и идентификаторы одинаковы для каждого разработчика (https://DevBoxFQDN/AppName/). При первоначальной настройке я просто использовал DevA в качестве тестового примера, пока он не заработал. Когда-то это сработало для DevA, Я добавил DevB но сделал это неправильно, добавив DevB's идентификатор для DevA RP. Конечным результатом была попытка аутентификации на DevB's веб-приложение, при перенаправлении обратно в приложение оно перешло в DevA's коробка. Неправильная конфигурация, но я бы назвал это успешным тестовым примером для DevB коробка. Как только я понял это, я удалил DevB's идентификатор из DevA RP и создали как DevB и DevC RP (указывая на https://DevB.FQDN/AppName/ и https://DevC.FQDN/AppName/ как для конечных точек, так и для идентификаторов).
В этот момент произошло нечто странное. Это сработало для DevC просто отлично, как и для DevA. Тем не мение, DevB получает идентификаторы событий 184/364, указывающие, что DevB идентификатор неверный. Долгая отладка и поиск возможных проблем не привели ни к чему полезному. В качестве слепого удара мы просто создали новый виртуальный каталог на DevB коробка для https://DevB.FQDN/AppName2/ (мы буквально просто добавили 2 в конец имени виртуального каталога / приложения - указывает на то же место, что и другой каталог, и имеет те же настройки) и внес такое же изменение в файл web.config для приложения. В ADFS я отредактировал конечную точку и идентификатор, чтобы добавить 2 также. Это изменение, и только это изменение вызывает DevB функционировать должным образом. Таким образом, это развенчивает большинство возможностей, которые, как мы подозревали, не применимы к нам (брандмауэры, испорченные сертификаты / SPN и т. Д.), Которые оставили нам сообщения на форуме. Если мы изменим это обратно, чтобы удалить 2, затем снова ломается. Больше ничего не меняется!
И на всякий случай мы вернули DevB машины обратно к резервной копии на основе образов с того времени, когда она «работала», но не работала DevA РП - без изменений. Таким образом, это говорит мне, что проблема где-то в конфигурации сервера ADFS или что-то среднее, но не в веб-сервере.
Итак, в чем дело? Почему ADFS не будет работать с определенным идентификатором / конечной точкой (просто строковым URL-адресом, насколько я могу судить), но если я просто добавлю 2 к нему во всех случаях он работает? Есть ли черный список / кеш или что-то, что мне нужно очистить?
Регистрируются два события: 184 и 364. 364 не представляет интереса, поскольку просто говорит «что-то пошло не так», но 184 представляет интерес. Подробная информация об ошибке в журнале событий (идентификатор события: 184):
A token request was received for a relying party identified by the key
'https://DevB.FQDN/AppName/', but the request could not be fulfilled
because the key does not identify any known relying party trust.
Key: https://DevB.FQDN/AppName/
This request failed.
User Action
If this key represents a URI for which a token should be issued, verify
that its prefix matches the relying party trust that is configured in
the AD FS configuration database.
И, наконец, я дважды / трижды / пятикратно проверил идентификатор. Это правильно, без опечаток и прочего.
PS: Это перекрестная публикация с форумов Microsoft для этой проблемы.