Возможно ли изменить ADFS для использования учетных данных NTLM, если они присутствуют для аутентификации пользователя?

Question

Мы используем CRM 2011 w/ADFS 2.0. Наши пользователи хотели бы, чтобы один URL-адрес использовался как для внутренних, так и для внешних пользователей, но с IFD Config в CRM 2011 это невозможно, если мы также хотим использовать автоматический вход через текущие учетные данные NTLM для пользователей. Возможно ли изменить страницу подписки ADFS, чтобы определить, имеются ли учетные данные NTLM и из правильного домена, и если это так автоматически регистрирует пользователя и перенаправляет его обратно в приложение с помощью правильных токенов ADFS?

Есть ли достаточная площадь поверхности API и правильные типы для того, чтобы мы могли изменить страницу входа в систему таким образом, или закрытие апикинга закрыто до такой степени, что мы не смогли бы сделать это программно?

Комментарий: Мы знаем, что с использованием UAG SP1 мы можем принудительно выполнить вход в систему ADFS с учетными данными NTLM, но наш клиент не планирует развертывание UAG в ближайшее время.

Answer 1

Ваш вопрос для меня не совсем ясен, но в любом случае может быть ответ здесь.

Как описано на странице Authentication Handler Overview, AD FS 2.0 имеет пару механизмов аутентификации. Какой из них выбран, определяется на основе того, что позволяет «запрос на аутентификацию». Речь идет не о HTTP-запросе в браузере пользователя, а о запросе входа, исходящем от полагающейся стороны (CRM 2011 в вашем случае). И нет возврата: для каждого из четырех обработчиков «[I] f вызывается, не передает запрос следующему обработчику».

Так, например, если запрос на вход в систему WS-Federation от CRM до AD FS (отправленный через браузер) говорит о том, что встроенная проверка подлинности Windows прекрасна, и если у вас есть интегрированный обработчик в верхней части списка <localAuthenticationTypes> , то IWA всегда используется для аутентификации пользователя (так что NTLM или Kerberos, в зависимости от возможностей браузера/сервера). Независимо от того, является ли пользователь «внутренним» или «внешним», не имеет значения.

Вы хотите использовать разные методы аутентификации для разных пользователей? Если это так, то единственным источником влияния на выбранный метод аутентификации является источник: теоретически CRM может адаптировать свой запрос на аутентификацию на основе некоторой информации от пользователя или браузера пользователя. Если CRM основан на WIF, вы можете выполнить обработку запросов в WSFederationAuthenticationModule.RedirectingToIdentityProvider Event. Коллеги успешно выполнили манипуляции с входным сигналом WIF в SharePoint, используя этот механизм.

Вы всегда хотите silent Вход в систему (в отличие от получения диалогового окна учетных данных Windows из вашего браузера)? По нашему опыту существуют всевозможные причины, по которым согласование IWA не может убедить сервер в том, что учетные данные Windows клиента действительно действительны, что делает браузер явно запрашивать учетные данные. Наиболее очевидная причина заключается в том, что браузер не может достичь AD сервера, но их больше.