Exchange delegation federation для чего нужен

Сотрудничество до установки Exchange 2010 и федеративного делегирования

В более ранних версиях Exchange функции общего доступа были ограничены и требовали сложной настройки и обслуживания. Например, чтобы обмениваться сведениями о доступности с пользователями другой организации Exchange, необходимо использовать средство репликации между организациями для репликации общих папок между организациями Exchange. В процессе репликации необходимо создать Служба каталогов Active Directory доверие между организациями, а также управлять учетными данными учетной записи службы.

В организациях используются различные средства, позволяющие отображать получателей в списках адресов Exchange, например средство GALSync, выполняющее синхронизацию получателей между двумя организациями. Настройка доверия, управление учетными данными и репликация на несколько внешних организаций представляли большую сложность и занимали много времени. При создании доверия леса или домена Служба каталогов Active Directory или управлении учетными данными также необходимо было принимать во внимание факторы безопасности. Требовалось также открывать дополнительные порты в брандмауэрах между двумя организациями или устанавливать виртуальную частную сеть (VPN).

Благодаря внедрению веб-служб Exchange, службы доступности и роли сервера клиентского доступа в Exchange Server 2007 репликация сведений о занятости из общих папок не требовалась. Тем не менее, для обеспечения доступа к сведениям о занятости во внешних организациях все еще требовалась репликация сведений о доверии, учетных данных и глобальных списков адресов.

При установке общего доступа к папкам «Календарь» и «Контакты» также было необходимо назначить пользователям в доверенных организациях разрешения на доступ к этим папкам. Для этого требовалось создать между двумя организациями доверие Служба каталогов Active Directory, принимая во внимание дополнительные факторы безопасности.

Федеративное делегирование

Федеративное делегирование в Exchange 2010 позволяет пользователям обмениваться данными с получателями во внешних федеративных организациях благодаря установке доверия федерации и созданию связей организации между организациями Exchange 2010. Организации также могут использовать политики общего доступа, чтобы пользователи могли создавать индивидуальные отношения общего доступа с получателями в других организациях. Федеративное делегирование использует шлюз Microsoft Federation Gateway — облачную службу, предоставляемую корпорацией Майкрософт, — в качестве брокера доверия между двумя федеративными организациями. Чтобы включить федеративное делегирование, организации, которым необходимо иметь общий доступ к данным, должны установить единовременное доверие федерации со шлюзом Microsoft Federation Gateway и настроить друг с другом связь организации или политики общего доступа.

Важно!
При отключении идентификатора федеративной организации для организации Exchange 2010 все функции федерации будут отключены в организации.

Дополнительные сведения о шлюзе Microsoft Federation Gateway и доверии федерации см. в следующих разделах:

Федеративное делегирование предоставляет пользователям два способа обмена данными календаря и контактными данными с внешними получателями: организационные связи и политики общего доступа.

Организационные связи

Связи организации позволяют устанавливать федеративное делегирование с другой федеративной организацией для обмена данными календаря о доступности между пользователями в обеих организациях. Организационные связи — это двусторонние отношения между организациями. Вместо сложной настройки доверия леса или домена Служба каталогов Active Directory между двумя организациями (для которой также может потребоваться открытие нескольких портов в брандмауэрах в обеих организациях или установка виртуальной частной сети) необходимо только установить одно доверие федерации со шлюзом Microsoft Federation Gateway и настроить идентификатор для каждой федеративной организации перед настройкой связи организации друг с другом.

Требования для организационных связей

Ниже приведены требования для организационных связей.

В каждой организации Exchange существует сервер клиентского доступа Exchange 2010.

Примечание.

Пользователи Office Outlook 2007 не могут указывать SMTP-адреса внешних получателей для отображения сведений о доступности. Получателей необходимо выбирать в глобальном списке адресов, который требуется синхронизировать с внешней организацией. Пользователи Outlook 2007 с почтовыми ящиками на серверах почтовых ящиков Exchange 2007 с пакетом обновления 2 (SP2) могут использовать Office Outlook Web Access на сервере клиентского доступа Exchange 2007 с пакетом обновления 2 (SP2).

Создание организационных связей

После создания связи организации с внешней организацией ее пользователи смогут получить доступ к сведениям о доступности пользователей вашей организации. Репликация сведений глобального списка адресов не требуется. С помощью этой конфигурации пользователи Outlook 2010 и Office Outlook Web App могут просто вводить SMTP-адрес внешнего получателя при планировании собраний.

При создании связи организации можно указать один из трех уровней доступа к сведениям о доступности календаря:

без доступа к сведениям о доступности;

Чтобы пользователи определенной организации могли получать сведения о доступности пользователей внешней организации или чтобы включить односторонний обмен сведениями об их доступности с внешней организацией, администратору внешней организации необходимо создать связь организации с этой организацией. Однако администратор внешней организации может указать другой уровень доступа к сведениям, отличный от указанного в вашей организации. В случае одностороннего обмена данными администратор внешней организации может настроить связь своей организации таким образом, что сведения о доступности пользователей не будут доступны пользователям вашей организации, а сведения о доступности пользователей вашей организации будут доступны пользователям внешней организации, в зависимости от параметров связи вашей организации.

Примечание.

Чтобы запретить обмен данными о своей занятости с другими пользователями, пользователи могут изменить запись «Разрешение по умолчанию» в приложении Outlook. Для этого пользователям необходимо перейти на вкладку Свойства календаря > Разрешения, выбрать разрешение По умолчанию, а затем в списке Уровень разрешений выбрать значение Нет. Сведения о занятости не будут отображаться для внутренних и внешних пользователей даже при существовании организационной связи с внешней организацией. Организационная связь учитывает установленные пользователем разрешения.

При создании организационной связи Exchange 2010 подключается к веб-службе автообнаружения, опубликованной внешней организацией, чтобы получить конечную точку службы доступности. Можно также указать вручную конечную точку службы доступности внешней организации при создании связи.

Чтобы создать организационную связь с внешней организацией, можно использовать мастер создания организационной связи в консоли управления Exchange или командлет New-OrganizationRelationship в командной консоли Exchange.

Дополнительные сведения о создании организационной связи см. в разделе Создание организационного отношения.

Политики общего доступа

В отличие от связей организации, которые позволяют обмениваться только сведениями о доступности с получателями в других федеративных организациях Exchange, политики общего доступа позволяют пользователям устанавливать обмен данными календаря и контактными данными с пользователями различных внешних организаций на индивидуальном уровне. Политики общего доступа позволяют пользователям обмениваться сведениями о доступности и контактными данными (включая папки «Календарь» и «Контакты») с получателями в других внешних федеративных организациях. Получатели, находящиеся в нефедеративной внешней организации или не в организации Exchange, благодаря политикам общего доступа могут обмениваться данными календаря на индивидуальном уровне с анонимными пользователями путем публикации календаря в Интернете.

При использовании политик общего доступа администратору не требуется управлять отношениями взаимодействия пользователей. Вместо этого пользователи сами решают, с какими внешними получателями им необходимо взаимодействовать. С помощью Outlook 2010 или Outlook Web App пользователи могут пригласить внешних получателей в других федеративных доменах для общего доступа к папкам «Календарь» или «Контакты» друг друга. Пользователи также могут предоставлять анонимный доступ к своим данным календаря любому лицу, имеющему доступ к Интернету. При использовании политик общего доступа администратору необходимо только управлять объемом обмениваемых данных и типом пользователей, с которыми пользователи его организации могут обмениваться данными. При необходимости можно отключить политику общего доступа пользователя или группы.

Политики общего доступа назначаются пользователям почтовых ящиков. Политика общего доступа по умолчанию разрешает обмен сведениями о доступности со всеми внешними федеративными доменами. После создания доверия федерации со шлюзом Microsoft Federation Gateway и настройки идентификатора федеративной организации пользователи могут приглашать пользователей в любой внешней федеративной организации для обмена данными календаря и контактными данными.

Важно!
Чтобы участвовать в федеративном делегировании, организации внешнего пользователя также необходимо установить доверие федерации со шлюзом Microsoft Federation Gateway и настроить идентификатор федеративной организации.

Чтобы разрешить доступ к данным календаря пользователя получателям в организациях нефедеративного домена, например членам семьи, друзьям или пользователям не в организациях Exchange, необходимо создать отдельную политику общего доступа, разрешающую анонимный доступ к календарю с помощью службы публикации календаря в Интернете. Дополнительные сведения см. в разделе Включение публикации календаря в Интернете.

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

Общий доступ к календарю (только сведения о занятости)

При создании приглашения на общий доступ пользователи могут выбрать сведения, которыми необходимо обмениваться, если это действие разрешено в политике общего доступа пользователя. Например, для организации Fabrikam и других организаций в федеративном домене создается политика общего доступа со следующими параметрами.

Общий доступ к календарю (сведения о занятости, тема и местоположение) для внешних пользователей в домене Fabrikam.com;

Пользователи, к которым применяется эта политика, могут обмениваться сведениями о доступности с другими организациями федеративного домена, а также некоторыми дополнительными сведениями с приглашенными пользователями Fabrikam.com.

Дополнительные сведения о создании политики общего доступа см. в разделе Создание политики общего доступа.

Дополнительные сведения о применении политики общего доступа к пользователям см. в разделе Применение политики общего доступа к почтовым ящикам.

Требования для политик федеративного общего доступа

Ниже приведены требования для политик общего доступа между организациями в федеративных доменах.

В каждой организации Exchange существует сервер клиентского доступа Exchange 2010.

Требования для политик нефедеративного общего доступа

Ниже приведены требования для политик общего доступа между организациями в нефедеративных доменах или анонимного доступа на индивидуальном уровне.

В организации Exchange, в которой открыт общий доступ к данным календаря пользователей, существует сервер клиентского доступа Exchange 2010.

Сравнение организационных связей и политик общего доступа

Несмотря на то что связи организации и политики общего доступа позволяют обмениваться сведениями о доступности с внешними пользователями, они используются в различных сценариях. Связи организации создаются для взаимодействия с внешними федеративными организациями и позволяют обмениваться только сведениями о доступности. Политики общего доступа определяют тип данных календаря и контактных данных, которыми пользователи организации могут обмениваться с пользователями внешних федеративных организаций, нефедеративных организаций Exchange, организаций, отличных от Exchange, а также с анонимными пользователями.

В следующей таблице приведены различия между связями организации и политиками общего доступа.

Сравнение связей организации и политик общего доступа

Требует доверия федерации для вашей организации

Да, при общем доступе с другими организациями в федеративном домене. Нет, при использовании политик общего доступа через Интернет.

Рекомендуется, чтобы внешний домен был федеративным

Да, при общем доступе с другими организациями в федеративном домене. Нет, при использовании политик общего доступа через Интернет.

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

Разрешает общий доступ к папкам календаря со сведениями о доступности

Разрешает общий доступ к папкам календаря со сведениями о доступности, включая тему и текст

Разрешает общий доступ к контактам

Да, при общем доступе с другими организациями в федеративном домене. Нет, при использовании политик общего доступа через Интернет.

Требует отправки пользователями приглашения на общий доступ внешним получателям

Предоставляет способ доступа

Сервер клиентского доступа подключается к серверу клиентского доступа внешней организации и получает сведения о доступности внешнего пользователя по запросу.

Сервер клиентского доступа подключается к серверу клиентского доступа внешней организации и выполняет подписку на папки «Календарь» и «Контакты» пользователя внешней организации в федеративном домене. При использовании политик общего доступа через Интернет внешние пользователи получают доступ к ограниченному или общедоступному URL-адресу на сервере клиентского доступа.

Может применяться ко всем внешним доменам

Нет (двустороннее отношение между организациями Exchange 2010)

Предоставляет пользователям различные способы общего доступа с внешними получателями

Да (на основе применяемой политики общего доступа)

Отключает общий доступ для некоторых пользователей

Да (необходимо указать группу безопасной рассылки для организационной связи)

Да (необходимо отключить применяемую политику общего доступа)

Требует, чтобы почтовый ящик располагался на сервере почтовых ящиков Exchange 2010

Требования к брандмауэру для федеративного делегирования

Чтобы использовать функции федеративного делегирования, необходимо настроить для серверов клиентского доступа в организации исходящий доступ к Интернету по протоколу HTTPS. Необходимо разрешить исходящий доступ по протоколу HTTPS (порт 443 для TCP) для всех серверов клиентского доступа Exchange 2010 в организации.

Чтобы разрешить внешней организации получать доступ к сведениям о доступности пользователей вашей организации, необходимо опубликовать один сервер клиентского доступа в Интернете. Для этого требуется настройка для сервера клиентского доступа исходящего доступа в Интернет с помощью протокола HTTPS. Серверы клиентского доступа на сайтах Служба каталогов Active Directory, на которых не опубликован сервер клиентского доступа в Интернете, могут использовать серверы клиентского доступа на других сайтах Служба каталогов Active Directory, которые доступны в Интернете. Серверы клиентского доступа, которые не опубликованы в Интернете, должны иметь внешний URL-адрес виртуального каталога веб-служб, настроенного с помощью URL-адреса, отображаемого для внешних организаций.

Сосуществование с Exchange 2007

В организации, включающей в себя серверы Exchange 2010 и Exchange 2007, пользователи, имеющие почтовые ящики на сервере почтовых ящиков Exchange 2007, могут использовать связи организации для обмена сведениями о доступности с получателями внешних организаций в федеративном домене. На сервере почтовых ящиков должна быть установлена система Exchange 2007 с пакетом обновления 2 (SP2), а также требуется существование по меньшей мере одного сервера клиентского доступа Exchange 2010 в организации Exchange. Чтобы использовать связи организации, можно развернуть один сервер клиентского доступа Exchange 2010 в организации. Такое решение будет более отказоустойчивым по сравнению с решениями, требующими синхронизации сведений о доступности и глобальных списков адресов.

При использовании Outlook 2010 или Outlook Web App для планирования собрания на сервере Exchange 2007 пользователь почтового ящика на сервере Exchange 2007 может просматривать сведения о доступности пользователя внешней организации. Сведения о доступности для почтовых ящиков Exchange 2007 отображаются для получателей во внешней организации.

Политики общего доступа назначаются пользователям почтовых ящиков Exchange 2010. Политики общего доступа можно использовать только для почтового ящика, размещенного на сервере почтовых ящиков Exchange 2010. Только пользователи Outlook 2010 и Outlook Web App могут создавать и принимать приглашения на общий доступ.

Совместная работа с Exchange 2003

В организации, включающей в себя серверы Exchange 2010 и Exchange 2003, пользователи, имеющие почтовые ящики на сервере Exchange 2003, могут использовать связи организации для обмена сведениями о доступности с получателями внешних организаций в федеративном домене. На сервере почтовых ящиков должна быть установлена система Exchange Server 2003 с пакетом обновления 2 (SP2), а также требуется существование по меньшей мере одного сервера клиентского доступа и сервера общих папок Exchange 2010 в организации Exchange 2003. Сервер клиентского доступа выступает в роли прокси-сервера для всех входящих и исходящих запросов на сведения о доступности и используется для настройки свойств связей организации. Сервер общих папок содержит и управляет репликами данных общих папок Exchange 2003 для доступа к сведениям о доступности другими федеративными организациями Exchange 2010.

Внутренние и внешние пользователи почтовых ящиков Exchange могут просматривать сведения о доступности в организации Exchange 2003 с помощью приложений Outlook 2003, Outlook 2007, Outlook 2010 или Outlook Web App. Политики общего доступа назначаются только пользователям почтовых ящиков Exchange 2010. Для использования политик общего доступа почтовые ящики должны размещаться на сервере почтовых ящиков Exchange 2010. К почтовым ящикам, размещенным на серверах Exchange 2003, политики общего доступа применить невозможно.

Установка организационной связи и политики общего доступа

В этом примере пользователь является администратором компании Contoso, Ltd. Эта организация заключила соглашение с компанией Fabrikam, Inc. по разработке совместно выпускаемого и реализуемого продукта. В целях сотрудничества этих организаций пользователи в отделах маркетинга и разработки обеих компаний должны обмениваться сведениями о доступности. Такое сотрудничество не должно доставлять затруднения пользователям.

Компания Contoso также сотрудничает с компанией Litware, Inc. В этом сотрудничестве принимает участие только ограниченная небольшая группа пользователей. Пользователям обеих организаций требуется установить между собой организационные связи. Необходимо разрешить общий доступ к сведениям о доступности и контактным данным. Необходимо запретить общий доступ к другим сведениям календаря.

Кроме того, пользователям Contoso необходимо обмениваться данными календаря с членами семей для координации другой деятельности, которой они управляют в приложении Outlook.

Для получения общего доступа не требуется:

создавать доверие леса или домена Служба каталогов Active Directory;

В этом сценарии выполните следующие шаги.

Чтобы настроить федеративное делегирование с компаниями Fabrikam и Litware, необходимо создать доверие федерации со шлюзом Microsoft Federation Gateway (если оно не создано). Для обмена данными с членами семей пользователей Contoso создавать доверие федерации не требуется. Эту процедуру необходимо выполнить однократно, чтобы использовать функции федерации Exchange 2010. Чтобы выполнить эту процедуру, необходимо использовать сертификат X.509, выданный центром сертификации, которому доверяет шлюз Microsoft Federation Gateway. Дополнительные сведения см. в разделе Создание доверия федерации.

Чтобы проверить, установлена ли федерация в компании Fabrikam, используйте командлет Get-FederationInformation.

Чтобы проверить, установлена ли федерация в компании Litware, используйте командлет Get-FederationInformation.

Установите виртуальный каталог публикации на сервере клиентского доступа. Дополнительные сведения см. в разделе Set-OwaVirtualDirectory.

После создания связи организации с компанией Fabrikam, Inc. и политики общего доступа для пользователей компаний Litware, Inc. и Contoso будут доступны следующие функции.

Все пользователи смогут просматривать сведения о доступности пользователей отделов маркетинга и разработки компании Fabrikam.

Как настроить trusted federation Microsoft Exchange Server. Federation. Федерация. Первая часть.

Эти все настройки делались на почтовых серверах одного домена, пусть будет roga.ru . На kopyta.ru тоже самое проделать.

Под федерацией подразумевается базовая инфраструктура отношений доверия, поддерживающая федеративный общий доступ, — простой способ обмена данными календаря с получателями во внешних федеративных организациях.

Доверие федерации работает на базе бесплатного облачного сервиса Microsoft Federation Gateway . Шлюз Microsoft Federation Gateway действует как промежуточный орган, с которым все организации Exchange должны установить однократное доверие, прежде чем они смогут взаимодействовать друг с другом. После однократного установления доверия шлюз Microsoft Federation Gateway выдает пользователям маркеры SAML , которые запрашивают информацию о пользователях из федеративной организации Exchange. Затем этим токенам доверяют федетированные партнеры, и они содержат информацию об адресе электронной почты пользователя, неизменном (постоянном) номере и действии, для которого выдается токен.
Если мы представим приведенное выше описание, все организации Exchange будут доверены шлюзу Microsoft Federation Gateway, но он не позволит ему взаимодействовать друг с другом, пока между двумя организациями Exchange не будет установлено доверительное отношение 1:1 «Отношение организации» . Отношения организации соединяют 2 организации Exchange и позволяют им обмениваться данными, определенными политиками общего доступа.

Настройка федерации (Federation trust).

• Виртуальные каталоги автообнаружения и EWS должны быть опубликованы в Интернете (или, если между вашими организациями существует внутреннее соединение, они должны быть доступны в обоих направлениях).
• Доверие федерации должно иметь аутентификацию WSSecurity в виртуальных каталогах EWS и Autodiscover.

Если не включена не включена аутентификация WSSecurity то надо включить ,а затем выполните сброс IIS.

После того, как они будут готовы, мы можем продолжить настройку доверия федерации.

Доверие федерации

• Чтобы заработало доверие федерации, нам нужно сгенерировать самозаверяющий сертификат с уникальным идентификатором ключа субъекта. Этот сертификат будет использоваться для подписи и шифрования токенов делегирования (также можно использовать сторонний сертификат подписи, но зачем, если мы можем использовать бесплатный самозаверяющий сертификат с более длительным сроком действия).

Первая команда генерирует уникальный SKI, вторая генерирует сертификат

Следующая команда создает доверие Федерации, но мы пока не можем связаться с MFG.

Чтобы иметь возможность общаться с MFG, мы должны доказать, что домены, которые будут определены в идентификаторе организации федерации, принадлежат нам. Это достигается путем добавления HASHES в виде записей TXT в наш DNS.
Хэши можно собрать с помощью следующих команд. Домен FYDIBOHF25SPDLT.roga.ru используется для создания пространства имен для связи между организациями, и, честно говоря, я не уверен, что этот хэш должен быть на месте, но я поместил его туда, чтобы убедиться, что он работает.

Добавляем записи внешний DNS.

После того как запись по всем DNS расползется настраиваем дальше.

Устанавливаем Federated Organization Identifier. Он определяет, какие домены наших организаций будут включены для федерации и какое доверие федерации будет использоваться.
Перед установкой идентификатора Федерации мы получаем следующие результаты

Get-FederationInformation -DomainName roga.ru

Идентификатор федеративной организации

Если ошибки при прохождении теста . Проверить интернет на почтовых серверах . Должен быть доступ

Сначала включаем и выключаем WebServicesVirtualDirectory и AutodiscoverVirtualDirectory

Step-by-Step guide to create federated sharing between on-premises Exchange 2013 and Office 365 Organization

Recently I was working on a project for a customer and I thought to share the problem and solution so in future it will help my blog readers.

Problem

My client has an on-premises Microsoft exchange 2013. Recently they are acquiring a company. This company is using Office 365. The both companies like to see calendar free/busy information when they schedules meetings etc.

Solution

Exchange 2013 offers a feature called “federation trust”. Federation trust will create trust relationship between on-premises exchange server and Azure active directory authentication system. Then it can use to create federated sharing with other federated organizations to share calendar free/busy information. The same method can use to create federated sharing between on-premises exchange server and office 365.

What you need?

Before start the configuration we need to have following ready,
1) Exchange administrator Privileges for on-premises exchange setup
2) Global administrator privileges for Office 365 portal
3) Access to DNS Zones to add TXT record for the on-premises exchange domain ( it is public dns entry )
4) Auto discovery should be fully functioning with on-premises exchange setup. If you got problem with it need to fix before start this configuration as you will end up with one way calendar free/busy info sharing.

Configuration on on-premises Exchange 2013

1) Log in to EAC as exchange administrator
2) Go to organization > sharing

3) Then click on enable (if you not using any federation trusts already) and start the federation trust wizard. It is straight forward setup and once wizard completes click on close.
4) Then under the federation trust click on modify

5) In new window Sharing-Enabled Domains, next to step 1 click on brows
6) In Select Accepted Domains, select the primary domain name of the on-premises exchange setup and click OK
7) This will create a federation trust with Azure AD authentication system. Please make note of the TXT record in the windows. Then add it to DNS zone (it should resolve via public dns). Make sure this record is created correctly as you will not be able to verify domain ownership with Azure AD authentication system. Sometime DNS propagation can take up to 24 hours and it’s all depend on your DNS provider. Once record is created click on Update
8) Once it’s done it will looks like following. It creates unique federation trust namespace and will register with Azure AD authentication system.

9) If you got additional domains, click on + mark to add. Once done click on update and exit from the window.

10) Now we need to add office 365 domain and allow them to see the free busy information. To do that on same sharing window, under the Organization sharing click on + mark

11) In new window, fill the info about the office 365 domain and set the sharing permissions as you desired. But I highly recommend to use same permissions in both ends to avoid issues. Of policies mismatch it may work on one-way only. Once changes are done click on save.

12) That’s it, it completes the federation trust setup on on-premises exchange 2013 end.

Configuration on Office 365 end

1) Log in to Office 365 portal and click on exchange admin center

2) In EAC go to the Organization

3) Under the organization sharing click on + to add on-premises exchange domain

4) In new window add the info about on-premises domain and also set sharing permissions, once done click on save.

Now it’s all done, it’s time for testing.
Some time you may notice the even after setup office 365 users may not be able to see the calendar free/busy info while it work from the other end. So best way to start troubleshooting this problem is to follow this troubleshoot link https://support.microsoft.com/en-us/help/10092/troubleshooting-free-busy-issues-in-exchange-hybrid-environment

But I have notice sometime you need to restart IIS on on-premises exchange 2013 CAS to get this working.

Hope this help and if you have any questions feel free to contact me on [email protected]

Name already in use

OfficeDocs-Exchange-Test-pr.ru-ru / Exchange-Server-2013 / federation-exchange-2013-help.md

• Go to file T
• Go to line L
• Copy path
• Copy permalink

• Open with Desktop
• View raw
• Copy raw contents Copy raw contents

Copy raw contents

Copy raw contents

title: ‘Федерация: Exchange 2013 Help’ TOCTitle: Федерация ms:assetid: 0046e2eb-6940-4941-bd5b-cbe6bffa3b94 ms:mtpsurl: https://technet.microsoft.com/ru-ru/library/Dd335047(v=EXCHG.150) ms:contentKeyID: 50487335 ms.date: 04/30/2018 mtps_version: v=EXCHG.150 ms.translationtype: HT

Применимо к: Exchange Server 2013

Последнее изменение раздела: 2016-12-09

Информационным работникам часто необходимо взаимодействовать с внешними получателями, поставщиками, партнерами и клиентами, а также обмениваться с ними сведениями о доступности (доступности в календаре). Наличие федерации в системе Microsoft Exchange Server 2013 способствует этому взаимодействию. Под федерацией подразумевается базовая инфраструктура отношений доверия, поддерживающая федеративный общий доступ, — простой способ обмена данными календаря с получателями во внешних федеративных организациях. Дополнительные сведения о федеративном общем доступе см. в разделе Общий доступ.

[!IMPORTANT]
Эта возможность Exchange Server 2013 не совместима полностью со службой Office 365, предоставляемой компанией 21Vianet в Китае. Кроме того, возможны некоторые ограничения. Дополнительные сведения о службе Office 365, предоставляемой компанией 21Vianet.

Содержание

Система проверки подлинности Azure AD

Идентификатор федеративной организации

Требования к сертификатам для федерации

Переход на новый сертификат

Рекомендации относительно брандмауэра для федерации

В следующей таблице определяются основные компоненты, связанные с федерацией в системе Exchange 2013.

• идентификатор приложения (AppID)
  Уникальный номер, сгенерированный системой проверки подлинности Azure Active Directory для идентификации организаций Exchange. AppID автоматически создается при создании отношения доверия федерации с системой проверки подлинности Azure Active Directory.

• маркер делегирования
  Это маркер SAML (Security Assertion Markup Language), выдаваемый системой проверки подлинности Azure Active Directory, который позволяет пользователям из одной федеративной организации получать доверие от другой федеративной организации. Маркер делегирования содержит адрес электронной почты пользователя, неизменяемый идентификатор и сведения, связанные с предложением, по которому для действия выпускается маркер.

• внешняя федеративная организация
  Внешняя организация Exchange, которая установила доверие федерации с системой проверки подлинности Azure Active Directory.

• федеративный общий доступ
  Группа функций Exchange, позволяющая отношению доверия с системой проверки подлинности Azure Active Directory работать в различных организациях Exchange, включая нелокальное развертывание Exchange. Совокупность таких функций применяется для создания проверенных на подлинность запросов между серверами от имени пользователей по нескольким организациям Exchange.

• федеративный домен
  Обслуживаемый уполномоченный домен, который добавляется к идентификатору организации (OrgID) для организации Exchange.

• строка шифрования для подтверждения права собственности на домен
  Криптографически стойкая строка, используемая организацией Exchange для доказательства того, что данная организация владеет доменом, используемым с системой проверки подлинности Azure Active Directory. Эта строка создается автоматически при использовании мастера включения доверия федерации. Также ее можно создать с помощью командлета Get-FederatedDomainProof.

• политика федеративного общего доступа
  Политика на уровне организации, согласно которой выполняется включение устанавливаемого пользователями прямого обмена между сотрудниками данными календаря, а также управление этим процессом.

• федерация
  Соглашение на основе доверия между двумя организациями Exchange для достижения общей цели. При наличии федерации для каждой организации необходимо, чтобы утверждения проверки подлинности от одной организации распознавались другой организацией.

доверие федерации
Связь с системой проверки подлинности Azure Active Directory, которая определяет следующие компоненты для организации Exchange:

пространство имен учетных записей;

идентификатор приложения (AppID);

идентификатор организации (OrgID);

Для настройки федеративного общего доступа с другими федеративными организациями Exchange, следует создать отношение доверия федерации с системой проверки подлинности Azure Active Directory.

• нефедеративная организация
  Организация, которая не имеет доверия федерации, установленного с системой проверки подлинности Azure Active Directory.

• идентификатор организации (OrgID)
  Определяет, какие из уполномоченных обслуживаемых доменов, настроенных в организации, включены для федерации. Система проверки подлинности Azure Active Directory распознает только тех получателей, которые имеют адреса электронной почты с федеративными доменами, настроенными в идентификаторе организации, и только они могут использовать такие функции, как федеративный общий доступ. OrgID — это сочетание заданной заранее строки и первого обслуживаемого домена, выбранного для федерации в мастере включения доверия федерации. Например, если вы указали федеративный домен contoso.com как основной SMTP-домен своей организации, в качестве OrgID для доверия федерации будет автоматически создано пространство имен учетных записей FYDIBOHF25SPDLT.contoso.com.

• связь организации
  Отношение «один к одному» между двумя федеративными организациями Exchange, которое позволяет получателям обмениваться сведениями о доступности (доступности календаря). Связь организации требует доверия федерации с системой проверки подлинности Azure Active Directory и устраняет необходимость в использовании леса Active Directory или доверия федерации между организациями Exchange.

• Azure Active Directory система проверки подлинности
  Бесплатная облачная служба идентификации, действующая в качестве брокера отношений доверия между федеративными организациями Microsoft Exchange. Он отвечает за выдачу маркеров делегирования получателям Exchange, когда они запрашивают информацию от получателей в других федеративных организациях Exchange. Дополнительные сведения см. в статье Azure Active Directory.

Система проверки подлинности Azure AD

Система проверки подлинности Azure Active Directory — это бесплатная облачная служба, предоставляемая корпорацией Майкрософт, которая действует как брокер доверия между вашей локальной организацией Exchange 2013 и другими федеративными организациями Exchange 2010 и Exchange 2013. Для настройки федеративного делегирования в организации Exchange необходимо установить единовременное доверие федерации с системой проверки подлинности Azure Active Directory, что позволит ему стать партнером по федерации для организации. Это доверие позволяет пользователям, прошедшим проверку подлинности в службе каталогов Active Directory (поставщики удостоверений), получать маркеры делегирования SAML (Security Assertion Markup Language) с помощью системы проверки подлинности Azure AD. Эти маркеры дают пользователям из одной федеративной организации Exchange возможность получать доверие от другой такой организации Exchange. Когда система проверки подлинности Azure AD выступает в качестве брокера доверия, для организаций не требуется устанавливать несколько отдельных отношений доверия с другими организациями и пользователи могут получать доступ к внешним ресурсам с помощью функции единого входа (SSO). Дополнительные сведения см. в статье Azure Active Directory.

Для настройки федеративного общего доступа Exchange 2013 следует создать отношение доверия федерации вашей организации Exchange 2013 с системой проверки подлинности Azure AD. Создание отношения доверия федерации с системой проверки подлинности Azure AD обеспечивает обмен цифровыми сертификатами безопасности организации с системой проверки подлинности Azure AD и получение сертификата системы проверки подлинности Azure AD и метаданных федерации. Доверие федерации можно установить с помощью мастера создания доверия федерации в центре администрирования Exchange (EAC) или командлета New-FederationTrust в командной консоли Exchange. Мастер создания доверия федерации автоматически создает самозаверяющий сертификат, который используется для подписывания и шифрования маркеров системы проверки подлинности Azure AD, позволяющих внешним федеративным организациям доверять вашим пользователям. Дополнительные сведения о требованиях к сертификатам см. в подразделе Требования к сертификатам для федерации далее в этом разделе.

При создании доверия федерации с системой проверки подлинности Azure AD автоматически создается идентификатор приложения (AppID) для вашей организации Exchange, который приводится в выходных данных командлета Get-FederationTrust. Идентификатор AppID используется системой проверки подлинности Azure AD для уникальной идентификации организации Exchange. Он также используется организацией Exchange для подтверждения прав владения доменом, используемым для системы проверки подлинности Azure AD. Это достигается путем создания записи ресурса TXT в зоне DNS каждого федеративного домена.

Идентификатор федеративной организации

Идентификатор федеративной организации (OrgID) определяет, какой из уполномоченных обслуживаемых доменов, настроенных в организации, включен для федерации. Система проверки подлинности Azure AD распознает только тех получателей, которые имеют адреса электронной почты с принятыми доменами, настроенными в идентификаторе организации, и только они могут использовать такие функции, как федеративный общий доступ. При создании нового доверия федерации с помощью системы проверки подлинности Azure AD автоматически создается идентификатор OrgID. OrgID — это сочетание заданной заранее строки и обслуживаемого домена, выбранного в качестве основного общего домена в мастере включения доверия федерации. Например, если вы указали в мастере изменения общих доменов федеративный домен contoso.com как основной общий домен своей организации, в качестве OrgID для доверия федерации вашей организации Exchange будет автоматически создано пространство имен учетных записей FYDIBOHF25SPDLT.contoso.com.

Хотя обычно это основной SMTP-домен организации Exchange, он не обязательно должен быть обслуживаемым и не требует записи типа TXT. (Эта запись подтверждает владение и настраивается в службе доменных имен, или DNS.) Единственное требование заключается в том, что длина имен обслуживаемых доменов, выбранных для федерации, не должна превышать 32 символов. Указанный поддомен служит только в качестве федеративного пространства имен для системы аутентификации Azure AD. Он обслуживает уникальные идентификаторы для получателей, запрашивающих маркеры делегирования SAML. Дополнительные сведения о маркерах SAML см. в статье Маркеры и утверждения SAML.

Вы можете добавлять и удалять обслуживаемые домены в доверии федерации в любое время. Чтобы включить или выключить все функции федеративного общего доступа в организации, достаточно включить или выключить OrgID для доверия федерации.

[!IMPORTANT]
При изменении OrgID, обслуживаемых доменов или AppID, используемых для доверия федерации затрагиваются все функции федеративного общего доступа в вашей федерации. Изменения также затрагивают внешние федеративные организации Exchange, включая Exchange Online и гибридные развертывания. Рекомендуется уведомлять всех внешних федеративных партнеров о всех изменениях в параметрах конфигурации доверия федерации.

Две организации Exchange, Contoso, Ltd. и Fabrikam, Inc., хотят, чтобы их пользователи могли обмениваться сведениями о доступности из календарей. В каждой организации создано доверие федерации с системой проверки подлинности Azure AD и настроено пространство имен учетных записей, включающее в себя домен адресов электронной почты пользователей.

Сотрудники Contoso используют один из следующих доменов адресов электронной почты: contoso.com, contoso.co.uk или contoso.ca. Сотрудники компании Fabrikam используют один из следующих доменов адресов электронной почты: fabrikam.com, fabrikam.org или fabrikam.net. В обеих организациях все обслуживаемые домены электронной почты включены в пространство имен учетных записей для создания доверия федерации с системой проверки подлинности Azure AD. Вместо настройки сложного леса Active Directory или доверия доменов организации создают между собой связь организаций для обмена сведениями о доступности.

На следующем рисунке показана конфигурация федерации между компаниями Contoso, Ltd. и Fabrikam, Inc.

Пример федеративного общего доступа

Требования к сертификатам для федерации

Чтобы установить доверие федерации с системой проверки подлинности Azure AD, необходимо создать самозаверяющий сертификат или сертификат X.509, подписанный центром сертификации, и установить его на сервере Exchange 2013, использованном для создания доверия. Настоятельно рекомендуется использовать самозаверяющий сертификат, автоматически создаваемый и устанавливаемый мастером включения доверия федерации в EAC. Он используется только для подписывания и шифрования маркеров делегирования, используемый при федеративном общем доступе. Для доверия федерации достаточно одного сертификата. Exchange 2013 автоматически распространяет сертификат на всех прочих серверах Exchange 2013 в организации.

Для использования сертификата X.509, подписанного внешним центром сертификации, он должен отвечать следующим требованиям.

Доверенный центр сертификации. По возможности сертификат SSL X.509 должен быть выдан центром сертификации, доверенным для службы Windows Live. Тем не менее, можно использовать сертификаты, выданные центрами сертификации, которые в настоящее время не сертифицированы корпорацией Майкрософт. Текущий список доверенных центров сертификации см. в разделе Доверенные корневые центры сертификации для доверия федерации.

Идентификатор ключа субъекта. В сертификате должно быть поле идентификатора ключа субъекта. Большинство сертификатов X.509, выпускаемых коммерческими центрами сертификации, имеют такой идентификатор.

Поставщик служб шифрования CryptoAPI. Для сертификата должен использоваться поставщик CryptoAPI. Сертификаты, для которых используются поставщики CNG (Cryptography API: Next Generation), не поддерживаются в случае применения федерации. Если запрос на получение сертификата создается с помощью Exchange, то используется поставщик CryptoAPI. Дополнительные сведения см. в статье Cryptography API: Next Generation.

Алгоритм подписи RSA В качестве алгоритма подписи в сертификате должен использоваться алгоритм RSA.

Экспортируемый закрытый ключ Закрытый ключ, используемый для создания сертификата, должен быть экспортируемым. При создании запроса на сертификат с помощью мастера создания сертификатов Exchange в центре администрирования Exchange или командлета New-ExchangeCertificate в командной консоли можно указать, что закрытый ключ сертификата должен быть экспортируемым.

Текущий сертификат Сертификат должен быть действителен. Невозможно использовать истекший или аннулированный сертификат для создания доверия федерации.

Расширенное использование ключа В сертификат должен быть включен тип расширенного использования ключа (EKU) Проверка подлинности клиента (1.3.6.1.5.5.7.3.2). Этот тип использования предназначен для подтверждения идентификатора на удаленном компьютере. Если для создания запроса на сертификат используется EAC или командная консоль, то этот тип использования включается по умолчанию.

[!NOTE]
Так как данный сертификат не используется для проверки подлинности, то для него отсутствуют требования к имени субъекта или альтернативному имени субъекта. Можно использовать сертификат с именем субъекта, которое совпадает с именем узла, доменным или любым другим именем.

Переход на новый сертификат

Сертификат, используемый для создания доверия федерации, обозначается в качестве текущего. Однако для доверия федерации может потребоваться периодическая установка и использование нового сертификата. Например, новый сертификат может потребоваться, когда истекает срок действия текущего сертификата или необходимо выполнение требований к ведению бизнеса или обеспечению безопасности. Чтобы обеспечить плавное переключение на новый сертификат, необходимо установить его на сервер Exchange 2013 и настроить доверие федерации для обозначения этого сертификата в качестве нового. Exchange 2013 автоматически распространяет следующий сертификат на другие серверы Exchange 2013 в организации. В зависимости от топологии Active Directory, распространение сертификата может занять некоторое время. Проверить состояние сертификата можно с помощью командлета Test-FederationTrustCertificate в командной консоли.

После проверки состояния распространения сертификата можно настроить доверие для переключения на следующий сертификат. Когда это произойдет, текущий сертификат будет обозначен как предыдущий, а новый — как текущий. Новый сертификат публикуется в системе проверки подлинности Azure AD, а все новые маркеры, которыми выполнен обмен с системой проверки подлинности Azure AD, шифруются с помощью нового сертификата.

[!NOTE]
Этот процесс перехода на новый сертификат используется только в федерации. Если этот же сертификат используется в других компонентах Exchange 2013, применяющих сертификаты, необходимо учитывать требования этих компонентов при планировании получения и установки нового сертификата, а также перехода на новый сертификат.

Рекомендации относительно брандмауэра для федерации

Чтобы использовать функции федерации, необходимо настроить для серверов почтовых ящиков и клиентского доступа в организации доступ к Интернету по протоколу HTTPS. Необходимо разрешить доступ по протоколу HTTPS (порт 443 для TCP) для всех серверов почтовых ящиков и клиентского доступа Exchange 2013 в организации.

Чтобы разрешить внешней организации получать доступ к сведениям о доступности пользователей вашей организации, необходимо опубликовать один сервер клиентского доступа в Интернете. Для этого требуется настройка для сервера клиентского доступа исходящего доступа в Интернет с помощью протокола HTTPS. Серверы клиентского доступа на сайтах Active Directory, на которых не опубликован сервер клиентского доступа в Интернете, могут использовать серверы клиентского доступа на других сайтах Active Directory, которые доступны в Интернете. Серверы клиентского доступа, которые не опубликованы в Интернете, должны иметь внешний URL-адрес виртуального каталога веб-служб, настроенного с помощью URL-адреса, отображаемого для внешних организаций.