Добро пожаловать в мой блог! Изначально он не задумывался как блог CRM разработчика, но жизнь сама внесла нужные коррективы. Тут я публикою все свои наблюдения относительно обозначенных в заголовке систем. Если Вы найдете в нем что-то интересное для Вас, как для заказчика, то буду рад сотрудничать с Вами! В моей компетенции 100% задач по MS CRM 3.0/4.0/2011:
MVP 2010, 2011
- Консалтинг
- Проектирование
- Разработка
- Обучение
MVP 2010, 2011
Проблема внутренней (доменной) авторизации в CRM 2011/2013 при включенном IFD
Запись от Артем Enot Грунин размещена 20.06.2014 в 12:31
Обновил(-а) Артем Enot Грунин 20.06.2014 в 13:55
Обновил(-а) Артем Enot Грунин 20.06.2014 в 13:55
Недавно я столкнулся с интересным глюком при настройке Internet Faced Deployment в CRM 2011 (аналогичный опыт есть и с 2013).
Настройка выполнялась строго по официальной инструкции (ныне включена в состав Implementation Guide), однако на финальном шаге - настройке IFD возникала проблема: переставала работать авторизация по внутреннему адресу системы.
Для тех кто не погружен в предметную область, я дам некоторые комментарии. Исторически сложилось, что публикация внутренних ресурсов во внешнюю сеть - это всегда геморрой. Причин тому несколько. В основном - интегрированные внутренние системы, взаимодействие с которыми может быть затруднено в случае доступа снаружи, и авторизация, которая внутри и снаружи может выполняться по разному (опять же в контексте работы с интегрированными системами).
Различные системы, например CRM и SharePoint, используют для реализации задачи различные подходы. В случае с SharePoint, для внешнего доступа, как правило, создается отдельный веб-сайт со своими настройками, который подключен к той же базе что и основной. Далее, через специальное решение типа Reverse Proxy он публикуется во внешнюю сеть. При этом рекомендуется использовать для внутреннего и внешнего доступа одно и то же имя.
В случае с CRM, использование одного и того же имени для внутреннего и внешнего доступа невозможно. Так как веб приложение у CRM одно, а не два, система понимает откуда идет запрос на основании запрашиваемого URL. Дополнительно, отличаются сами форматы этих адресов. Для внутреннего доступа используется формат:
а для внешнего:
Иными словами, если URL не совпал с внутренним, система парсит его как внешний, так что все что соответствует маске *.domain система пытается парсить как имя организации.
Теперь к практике. Внутреннее имя системы (вне зависимости от того собираетесь вы использовать IFD/Claims авторизацию, или нет) задается в параметрах развертывания системы, которые доступны через Deployment Manager:
Прошу вас обратить внимание, что по умолчанию в них указан порт. В данном случае это порт по умолчанию.
Начиная с CRM 2011, IFD конфигурация возможна только при использовании HTTPS, поэтому адреса служб будут выглядеть как-то так:
Если писать их по аналогии с адресами по умолчанию.
Вот тут-то и кроется опасность: при включении и настройке IFD, нельзя указывать порт по умолчанию 443 во внутреннем имени сервиса.
Порт требуется указывать, только если система развернута на не стандартном порту, например:
В противном случае,порт требуется не указывать:
Если же вы повторите мою ошибку, внутренний адрес будет восприниматься некорректно: система будет пытаться авторизовать пользователя через форму, при этом имя сервера будет восприниматься как имя организации.
Если в вашей конфигурации уже есть эта проблема, не забудьте после выполнения настройки перезагрузить IIS на сервере CRM и обновить метаданные конечных точек в консоли ADFS.
Настройка выполнялась строго по официальной инструкции (ныне включена в состав Implementation Guide), однако на финальном шаге - настройке IFD возникала проблема: переставала работать авторизация по внутреннему адресу системы.
Для тех кто не погружен в предметную область, я дам некоторые комментарии. Исторически сложилось, что публикация внутренних ресурсов во внешнюю сеть - это всегда геморрой. Причин тому несколько. В основном - интегрированные внутренние системы, взаимодействие с которыми может быть затруднено в случае доступа снаружи, и авторизация, которая внутри и снаружи может выполняться по разному (опять же в контексте работы с интегрированными системами).
Различные системы, например CRM и SharePoint, используют для реализации задачи различные подходы. В случае с SharePoint, для внешнего доступа, как правило, создается отдельный веб-сайт со своими настройками, который подключен к той же базе что и основной. Далее, через специальное решение типа Reverse Proxy он публикуется во внешнюю сеть. При этом рекомендуется использовать для внутреннего и внешнего доступа одно и то же имя.
В случае с CRM, использование одного и того же имени для внутреннего и внешнего доступа невозможно. Так как веб приложение у CRM одно, а не два, система понимает откуда идет запрос на основании запрашиваемого URL. Дополнительно, отличаются сами форматы этих адресов. Для внутреннего доступа используется формат:
Код:
https://server.domain/oranization
Код:
https://oranization.server.domain
Теперь к практике. Внутреннее имя системы (вне зависимости от того собираетесь вы использовать IFD/Claims авторизацию, или нет) задается в параметрах развертывания системы, которые доступны через Deployment Manager:
Прошу вас обратить внимание, что по умолчанию в них указан порт. В данном случае это порт по умолчанию.
Начиная с CRM 2011, IFD конфигурация возможна только при использовании HTTPS, поэтому адреса служб будут выглядеть как-то так:
X++:
CRM.FIXRM.COM:443
Вот тут-то и кроется опасность: при включении и настройке IFD, нельзя указывать порт по умолчанию 443 во внутреннем имени сервиса.
Порт требуется указывать, только если система развернута на не стандартном порту, например:
X++:
CRM.FIXRM.COM:444
Если же вы повторите мою ошибку, внутренний адрес будет восприниматься некорректно: система будет пытаться авторизовать пользователя через форму, при этом имя сервера будет восприниматься как имя организации.
Если в вашей конфигурации уже есть эта проблема, не забудьте после выполнения настройки перезагрузить IIS на сервере CRM и обновить метаданные конечных точек в консоли ADFS.
Всего комментариев 0
