Настройка IFD в CRM 2011/2013

[Артем Enot Грунин]

Доброго времени суток, коллеги. Возникла потребность разобраться в настройке внешнего доступа к CRM. Интересует сценарий внешнего развертывания для доступа через Интернет: IFD. Официальный мануал говорит, что для настройки внешнего доступа необходимо сперва настроить внутренний:

1. Complete the steps in the previous section, Implementing Claims-based Authentication - Internal Access.
2. Configure the Microsoft Dynamics CRM Server server for IFD.
3. Configure the AD FS for IFD.
4. Test external claims-based authentication.

Настройка осуществляется с использованием 2 отдельных серверов CRM 2011 (Та же проблема и с 2013) и ADFS 2.1.

Проблема: при настройке сервера на этапе 2, перестает корректно работать CBA для внутреннего доступа настроенная на этапе 1. Подробнее:

1. Выполняется необходимая настройка сервера: настраивается внутреннее имя internalcrm.contoso.com:443 (используется порт по умолчанию, так как он ничем более не занят).

2. Включается CBA, адрес https://internalcrm.contoso.com/Fede...onMetadata.xml возвращает корректный XML где в качестве конечной точки указан https://internalcrm.contoso.com

3. Производится настройка ADFS в соответствии с инструкцией. Без проблем происходит NTLM авторизация в браузере (без формы) я могу заходить на адрес сервера https://internalcrm.contoso.com и адрес организации https://internalcrm.contoso.com/org

4. Производится включение и настройка IFD и вот тут все портится. Оба адреса и внутренний https://internalcrm.contoso.com/Fede...onMetadata.xml и внешний https://auth.contoso.com/FederationM...onMetadata.xml возвращают один и тот же XML где в качестве конечных точек указаны внешние адреса:
https://auth.contoso.com
https://org.contoso.com
https://dev.contoso.com

Теперь я могу зайти по внешнему адресу https://org.contoso.com и смогу авторизоваться через веб форму. Но внутренний адрес https://internalcrm.contoso.com теперь тоже ведет на форму авторизации (что логично, учитывая тот же конфиг) но, в итоге, выдает ошибку "директория не найдена", что тоже логично, так как нет организации с названием "internalcrm", или подходящей точки доступа.

В консоли ADFS тоже возникают какие-то ошибки по поводу несоответствия настроенного Relying Party его изначальному определению.

Вопрос: у кого работает, кто победил?

p.s. Каждая из задач конфигурации выполняется без каких-либо ошибок. Нет проблем с DNS, сертификатами, файрволами и пр. Несмотря на то, что в посте приводятся имена из MSDN, в нашей среде настроены правильные имена. Внешний и внутренний адреса находятся в одном домене - так и задумано, такой же сценарий, насколько я понимаю, дается в MSDN. Возможно, важный момент: у нас нет домена (внутреннего имени?) contoso.local. Исторически так сложилось, что домен изначально назван "contoso.com". Судя по настройкам DNS, которые делаются в статье MSDN это не должно быть причиной ошибки - все адреса, в итоге, заканчиваются на contoso.com. Но... не работает

[MikeR]

Это видео не поможет ?

[Артем Enot Грунин]

Цитата:

Сообщение от MikeR

Это видео не поможет ?

К сожалению, его (в том числе) использовали при настройке. Почему-то во всех блогах и видео мануалах которые мне удалось найти, никто не проверяет как работает внутренний доступ после настройки внешнего. А он, к сожалению, в моем случае и ломается.

Коллеги! Неужели ни у кого не настроен IFD? Посмотрите, пожалуйста, оба ли варианта работают у вас и какие XML отдают внутренняя и внешняя ссылки?

[a33ik]

Старина, можешь мне объяснить зачем тебе оба работающих домена? Мне просто для себя интересно.

[Артем Enot Грунин]

Цитата:

Сообщение от a33ik

Старина, можешь мне объяснить зачем тебе оба работающих домена? Мне просто для себя интересно.

Для того, чтобы внутри не нужно было вводить логин пароль через форму. Форма уместна только снаружи, внтури хотелось бы авторизовываться сразу через NTLM

[Артем Enot Грунин]

Решение найдено с помощью MS Support и лично Alen George. Проблема была в том, что внутренние адреса системы в настройках деплоймента были указаны с портом по умолчанию:

internalcrm.contoso.com:443

Несмотря на то, что это поведение системы по-умолчанию, выяснилось, что ADFS подобное не любит. Если удалить порт (:443) и обновить метаданные в консоли ADFS, оба способа авторизации будут работать корректно.

[a33ik]

Старина, может выложишь себе в блог коротенький пост с картинками для тупых (для меня т.е.).

[Артем Enot Грунин]

Цитата:

Сообщение от a33ik

Старина, может выложишь себе в блог коротенький пост с картинками для тупых (для меня т.е.).

Написал: http://www.axforum.info/forums/blog.php?b=8139