Для использования функций федеративного делегирования Exchange 2010 необходимо создать доверие федерации между организацией Exchange 2010 и шлюзом Microsoft Federation Gateway. При установке доверия федерации со шлюзом Microsoft Federation Gateway происходит обмен цифровыми сертификатами безопасности организации со шлюзом Microsoft Federation Gateway и получение метаданных федерации. Доверие федерации можно установить с помощью мастера создания доверия федерации в консоли управления Exchange (EMC) или командлете New-FederationTrust в командной консоли Exchange. Мастером создания доверия федерации автоматически создается самозаверяющий сертификат, используемый для подписи и шифрования маркеров делегирования, которые позволяют пользователям получать доверие от внешних федеративных организаций. Дополнительные сведения о требованиях к сертификатам см. в подразделе Требования к сертификатам для федерации далее в этом разделе.

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

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

Дополнительные сведения о создании записи TXT см. в разделе Создание TXT-записи для федерации.

В начало

Идентификатор федеративной организации (OrgID) определяет, какой из уполномоченных обслуживаемых доменов, настроенных в организации, включен для федерации. Шлюзом Microsoft Federation Gateway распознаются только те получатели, которые имеют адреса электронной почты с обслуживаемыми доменами, настроенными в идентификаторе OrgID, и они могут использовать функции федеративного делегирования. Когда настраивается идентификатор OrgID, с помощью шлюза Microsoft Federation Gateway создается пространство имен учетных записей, при этом используется первый обслуживаемый домен, добавленный к нему.

Для федеративного делегирования необходимо использовать пространство имен домена для федеративного идентификатора OrgID, которое отличается от основного домена SMTP. Этот домен служит в качестве пространства имен учетных записей для идентификатора организации и не должен использоваться для почтовых ящиков в организации Exchange. Чтобы отличать поддомен, используемый для функции делегирования Exchange, рекомендуется создать поддомен с именем exchangedelegation. Этот поддомен служит только в качестве федеративного пространства имен для шлюза Microsoft Federation Gateway, который обслуживает уникальные идентификаторы получателей, запрашивающих маркеры делегирования SAML. Дополнительные сведения о маркерах SAML см. в статье Маркеры и утверждения SAML.

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

Важно!
Изменение идентификатора OrgID, обслуживаемых доменов или идентификатора AppID, используемых для федерации, повлияет на работоспособность всех функций федерации в организации, а также окажет воздействие на все внешние федеративные организации. Рекомендуется уведомлять всех внешних партнеров по федерации о любых изменениях, вносимых в параметры конфигурации.

Дополнительные сведения о настройке федеративного идентификатора OrgID см. в следующих разделах.

• Управление федерацией
  
  
• Настройка федеративного делегирования
  
  

В начало

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

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

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

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

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

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

• Доверенный центр сертификации   По возможности сертификат X.509 (SSL) должен быть выдан центром сертификации, доверенным службой Windows Live. Тем не менее, можно использовать сертификаты, выданные центрами сертификации, которые в настоящее время не сертифицированы корпорацией Майкрософт. Список доверенных центров сертификации см. в разделе Доверенные корневые центры сертификации для доверия федерации.
  
  
• Идентификатор ключа субъекта   В сертификате должно быть поле идентификатора ключа субъекта. Большинство сертификатов X.509, выпускаемых коммерческими центрами сертификации, имеют такой идентификатор.
  
  
• Поставщик служб шифрования CryptoAPI   В сертификате должен использоваться поставщик CryptoAPI. Сертификаты, в которых используются поставщики служб шифрования Cryptography API следующего поколения CNG (Cryptography Next Generation), не поддерживаются для применения федерации. Если для создания запроса на сертификат применяется сервер Exchange, то используется поставщик CryptoAPI. Дополнительные сведения см. в статье Cryptography API: Next Generation (на английском языке).
  
  
• Алгоритм подписи RSA   В качестве алгоритма подписи в сертификате должен использоваться алгоритм RSA.
  
  
• Экспортируемый закрытый ключ   Закрытый ключ, используемый для создания сертификата, должен быть экспортируемым. При создании запроса на сертификат с помощью мастера создания сертификатов Exchange в консоли управления Exchange или командлета New-ExchangeCertificate в командной консоли можно указать, что закрытый ключ должен быть экспортируемым.
  
  
• Текущий сертификат   Сертификат должен быть действителен. Невозможно использовать истекший или аннулированный сертификат для создания доверия федерации.
  
  
• Расширенное использование ключа   В сертификат должен быть включен тип расширенного использования ключа (EKU) Проверка подлинности клиента (1.3.6.1.5.5.7.3.2). Этот тип использования предназначен для подтверждения идентификатора на удаленном компьютере. Если для создания запроса на сертификат используется консоль управления Exchange или командная консоль, то этот тип использования включается по умолчанию.
  
  

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

В начало

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

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

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

Дополнительные сведения о переходе на новый сертификат см. в разделе Управление федерацией.

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

В начало

© Корпорация Майкрософт (Microsoft Corporation), 2010. Все права защищены. Юридические сведения

---

• English-to-Russian translation

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

Пример федеративного делегирования