Compartir vía

Federación

  • Artículo

Se aplica a: Exchange Server 2013

A menudo, los trabajadores de la información necesitan colaborar con destinatarios externos, proveedores, asociados y clientes, y comparten la información de disponibilidad (conocida como disponibilidad de calendario). La federación en Microsoft Exchange Server 2013 ayuda con estos esfuerzos de colaboración. Federación hace referencia a la infraestructura de confianza subyacente que es compatible con el uso compartido federado, un método sencillo para que los usuarios compartan la información de calendario con los destinatarios en otras organizaciones federadas externas. Para obtener más información acerca del uso compartido federado, consulte Compartir.

Importante

Esta característica de Exchange Server 2013 no es totalmente compatible con Office 365 operado por 21Vianet en China y pueden aplicarse ciertas limitaciones en las características. Para obtener más información, consulte Office 365 Operado por 21Vianet.

Terminología básica

En la lista siguiente se definen los componentes principales asociados a la federación en Exchange 2013.

  • identificador de aplicación (AppID): número único generado por el sistema de autenticación de Microsoft Entra para identificar organizaciones de Exchange. AppID se genera automáticamente al crear una confianza de federación con el sistema de autenticación de Microsoft Entra.

  • token de delegación: token de lenguaje de marcado de aserción de seguridad (SAML) emitido por el sistema de autenticación de Microsoft Entra que permite que otra organización federada confíe en los usuarios de una organización federada. Un token de delegación contiene la dirección de correo electrónico del usuario, un identificador inmutable e información asociada con la oferta para la que se emitió el token para acción.

  • organización federada externa: una organización externa de Exchange que ha establecido una confianza de federación con el sistema de autenticación de Microsoft Entra.

  • uso compartido federado: un grupo de características de Exchange que aprovechan una confianza de federación con el sistema de autenticación Microsoft Entra para trabajar entre organizaciones de Exchange, incluidas las implementaciones entre locales de Exchange. Juntas, estas características se usan para realizar solicitudes autenticadas entre los servidores en nombre de los usuarios en varias organizaciones de Exchange.

  • dominio federado: dominio autoritativo aceptado que se agrega al identificador de organización (OrgID) de una organización de Exchange.

  • cadena de cifrado a prueba de dominio: cadena criptográficamente segura que usa una organización de Exchange para proporcionar una prueba de que la organización posee el dominio usado con el sistema de autenticación Microsoft Entra. La cadena se genera automáticamente cuando se usa el Asistente para Habilitar confianzas de federación o se puede generar con el cmdlet Get-FederatedDomainProof.

  • Directiva de uso compartido federado: directiva de nivel de organización que permite y controla el uso compartido de información de calendario por parte del usuario y de persona a persona.

  • federación: un acuerdo basado en confianza entre dos organizaciones de Exchange para lograr un propósito común. Con la federación, ambas organizaciones desean que aserciones de autenticación de una organización sean reconocidas por la otra.

  • confianza de federación: relación con el sistema de autenticación de Microsoft Entra que define los siguientes componentes para su organización de Exchange:

    • Espacio de nombres de cuenta

    • Identificador de aplicación (AppID)

    • Identificador de organización (OrgID)

    • Dominios federados

    Para configurar el uso compartido federado con otras organizaciones federadas de Exchange, se debe establecer una confianza de federación con el sistema de autenticación Microsoft Entra.

  • Organización no federada: organizaciones que no tienen establecida una confianza de federación con el sistema de autenticación de Microsoft Entra.

  • identificador de organización (OrgID): define cuál de los dominios autorizados aceptados configurados en una organización está habilitado para la federación. Solo los destinatarios que tienen direcciones de correo electrónico con dominios federados configurados en orgID son reconocidos por el sistema de autenticación Microsoft Entra y pueden usar características de uso compartido federado. Este "OrgID" es una combinación de una cadena predefinida y el primer dominio aceptado seleccionado para la federación en el Asistente para Habilitar confianzas de federación. Por ejemplo, si especifica el dominio federado contoso.com como el dominio principal SMTP de su organización, el espacio de nombres de la cuenta FYDIBOHF25SPDLT.contoso.com se creará automáticamente como el "OrgID" para la confianza de generación.

  • relación de organización: una relación uno a uno entre dos organizaciones federadas de Exchange que permite a los destinatarios compartir información de disponibilidad (disponibilidad del calendario). Una relación de organización requiere una confianza de federación con el sistema de autenticación Microsoft Entra y reemplaza la necesidad de usar confianzas de dominio o bosque de Active Directory entre organizaciones de Exchange.

  • Microsoft Entra sistema de autenticación: un servicio de identidad gratuito basado en la nube que actúa como agente de confianza entre organizaciones federadas de Microsoft Exchange. Es responsable de emitir tokens de delegación para los destinatarios de Exchange cuando solicitan información a los destinatarios en otras organizaciones federadas de Exchange. Para obtener más información, consulte Microsoft Entra id.

Microsoft Entra sistema de autenticación

El sistema de autenticación Microsoft Entra, un servicio gratuito basado en la nube ofrecido por Microsoft, actúa como agente de confianza entre la organización local de Exchange 2013 y otras organizaciones federadas de Exchange 2010 y Exchange 2013. Si desea configurar la federación en su organización de Exchange, debe establecer una confianza de federación única con el sistema de autenticación Microsoft Entra, para que pueda convertirse en un asociado de federación con su organización. Con esta confianza en vigor, los usuarios autenticados por Active Directory (conocidos como proveedores de identidades) emiten tokens de delegación del Lenguaje de marcado de aserción de seguridad (SAML) mediante el sistema de autenticación de Microsoft Entra. Estos tokens de delegación permiten a los usuarios de una organización federada de Exchange ser de confianza de otra organización federada de Exchange. Con el Microsoft Entra sistema de autenticación que actúa como agente de confianza, las organizaciones no tienen que establecer varias relaciones de confianza individuales con otras organizaciones y los usuarios pueden acceder a recursos externos mediante una experiencia de inicio de sesión único (SSO). Para obtener más información, consulte Microsoft Entra id.

Confianza de federación

Para usar las características de uso compartido federado de Exchange 2013, debe establecer una confianza de federación entre la organización de Exchange 2013 y el sistema de autenticación de Microsoft Entra. El establecimiento de una confianza de federación con el sistema de autenticación de Microsoft Entra intercambia el certificado de seguridad digital de la organización con el sistema de autenticación de Microsoft Entra y recupera el certificado del sistema de autenticación de Microsoft Entra y los metadatos de federación. Puede establecer una confianza de federación mediante el Asistente para habilitar la confianza de federación en el Centro de administración de Exchange (EAC) o el cmdlet New-FederationTrust en el Shell de administración de Exchange. El Asistente para habilitar la confianza de federación crea automáticamente un certificado autofirmado y se usa para firmar y cifrar tokens de delegación desde el sistema de autenticación de Microsoft Entra que permiten que las organizaciones federadas externas confíen en los usuarios. Para obtener más información sobre los requisitos de certificado, vea Requisitos de certificado para la federación más adelante en este tema.

Al crear una confianza de federación con el sistema de autenticación de Microsoft Entra, se genera automáticamente un identificador de aplicación (AppID) para la organización de Exchange y se proporciona en la salida del cmdlet Get-FederationTrust. El sistema de autenticación de Microsoft Entra usa AppID para identificar de forma única la organización de Exchange. También la usa la organización de Exchange para proporcionar una prueba de que su organización posee el dominio para su uso con el sistema de autenticación de Microsoft Entra. Esto se realiza al crear un registro de texto (TXT) en la zona Sistema de nombres de dominio (DNS) público para cada dominio federado.

Identificador de organización federada

El identificador de organización federada (OrgID) define los dominios aceptados autoritativos configurados en la organización de que están habilitados para la federación. Solo los destinatarios que tienen direcciones de correo electrónico con dominios aceptados configurados en orgID son reconocidos por el sistema de autenticación de Microsoft Entra y pueden usar características de uso compartido federado. Al crear una nueva confianza de federación, se crea automáticamente un OrgID con el sistema de autenticación de Microsoft Entra. Este "OrgID" es una combinación de una cadena predefinida y el dominio seleccionado aceptado como dominio compartido primario en el asistente. Por ejemplo, en el Asistente para editar dominios compartidos habilitados, si especifica el dominio federado contoso.com como dominio compartido primario de su organización, el espacio de nombres de la cuenta FYDIBOHF25SPDLT.contoso.com se creará automáticamente como "OrgID" para la confianza de federación de su organización de Exchange.

A pesar de que habitualmente es el dominio SMTP principal en la organización de Exchange, este dominio no tiene que ser un dominio aceptado en su organización de Exchange y no requiere un registro de texto (TXT) con prueba de propiedad del Sistema de nombres de dominio (DNS). El único requisito es que los dominios aceptados seleccionados para ser federados se limiten a un máximo de 32 caracteres. El único propósito de este subdominio es servir como espacio de nombres federado para que el sistema de autenticación de Microsoft Entra mantenga identificadores únicos para los destinatarios que solicitan tokens de delegación saml. Para obtener más información acerca de los símbolos de SAML, consulte Símbolos y notificaciones de SAML

Puede agregar o quitar los dominios aceptados desde la confianza de generación en cualquier momento. Además, si desea habilitar o deshabilitar todas las funciones de uso compartido de federación en su organización, todo lo que tiene que hacer es habilitar o deshabilitar OrgID para la confianza de federación.

Importante

Si cambia OrgID, los dominios aceptados o AppID que se usó para la confianza de generación, todas las funciones de uso compartido de federación se verán afectadas en su organización. Esto también afecta las organizaciones de Exchange federadas externas, incluidos Exchange Online y las configuraciones de implementación híbrida. Le recomendamos que notifique a todos los socios federados externos sobre los cambios en estas configuraciones de confianza de federación.

Ejemplo de federación

Dos organizaciones de Exchange, Contoso, Ltd. y Fabrikam, Inc., quieren que sus usuarios puedan compartir información de disponibilidad del calendario entre sí. Cada organización crea una confianza de federación con el sistema de autenticación de Microsoft Entra y configura su espacio de nombres de cuenta para incluir el dominio usado para el dominio de dirección de correo electrónico del usuario.

Los empleados de Contoso usan uno de los siguientes dominios de dirección de correo electrónico: contoso.com, contoso.co.uk, o contoso.ca. Los empleados de Fabrikam usan uno de los siguientes dominios de dirección de correo electrónico: fabrikam.com, fabrikam.org, o fabrikam.net. Ambas organizaciones se aseguran de que todos los dominios de correo electrónico aceptados se incluyan en el espacio de nombres de la cuenta para su confianza de federación con el sistema de autenticación Microsoft Entra. En lugar de requerir un bosque complejo de Active Directory o una configuración de confianza del dominio entre los organizaciones, ambas organizaciones configuran una relación de la organización con la otra para permitir el uso compartido de disponibilidad de calendario.

La siguiente figura ilustra la configuración de federación entre Contoso, Ltd. y Fabrikam, Inc.

Ejemplo de uso compartido federado

Confianzas de federación y uso compartido federado.

Requisitos de certificados para la federación

Para establecer una confianza de federación con el sistema de autenticación de Microsoft Entra, se debe crear e instalar un certificado autofirmado o un certificado X.509 firmado por una entidad de certificación (CA) en el servidor de Exchange 2013 que se usa para crear la confianza. Se recomienda encarecidamente usar un certificado autofirmado, que se crea e instala automáticamente mediante el Asistente para habilitar la confianza de federación en el EAC. Este certificado solo se usa para firmar y cifrar los tokens de delegación usados para el uso compartido federado y solo se requiere un certificado para la confianza de federación. Exchange 2013 distribuye automáticamente el certificado a todos los demás servidores de Exchange 2013 de la organización.

Si desea usar un certificado X.509 firmado por una CA externa, el certificado debe cumplir con los siguientes requisitos:

  • CA de confianza: si es posible, el certificado X.509 Secure Sockets Layer (SSL) debe emitirse desde una entidad de certificación de confianza de Windows Live. Sin embargo, puede usar certificados emitidos por CA que actualmente no están certificados por Microsoft. Para obtener una lista actual de CA de confianza, consulte Autoridades de certificación raíz de confianza para confianzas de federación.

  • Identificador de clave de firmante: el certificado debe tener un campo de identificador de clave de firmante. La mayoría de los certificados X.509 emitidos por CA comerciales tienen este identificador.

  • Proveedor de servicios criptográficos (CSP) CryptoAPI: el certificado debe usar un CSP de CryptoAPI. Certificados que usan la criptografía API: Los proveedores de próxima generación (CNG) no se admiten para la federación. Si usa Exchange para crear una solicitud de certificado, se usa un proveedor de CryptoAPI. Para obtener más información consulte criptografía API: Próxima generación .

  • Algoritmo de firma RSA: el certificado debe usar RSA como algoritmo de firma.

  • Clave privada exportable: la clave privada que se usa para generar el certificado debe ser exportable. Puede especificar que la clave privada sea exportable al crear la solicitud de certificado mediante el Asistente para Nuevo certificado de intercambio en el EAC o el cmdlet New-ExchangeCertificate en el Shell.

  • Certificado actual: el certificado debe ser actual. No puede usar un certificado expirado o revocado para crear una confianza de federación.

  • Uso mejorado de claves: el certificado debe incluir el tipo de uso mejorado de clave (EKU) Autenticación de cliente (1.3.6.1.5.5.7.3.2). Este tipo de uso se utiliza para demostrar su identidad en un equipo remoto. Si usa EAC o Shell para generar la solicitud de certificado, este tipo de uso se incluye de forma predeterminada.

Nota:

Debido a que el certificado no se usa con fines de autenticación, no cuenta con requisitos de nombre de asunto o nombre de asunto alternativo. Puede usar un certificado con un nombre de asunto que sea el mismo nombre que el nombre de host, el nombre de dominio o cualquier otro nombre.

Transición a un certificado nuevo

El certificado usado para crear la confianza de federación está designado como el certificado actual. Sin embargo, es posible que necesite instalar y usar periódicamente un nuevo certificado para la confianza de federación. Por ejemplo, es posible que necesite usar un nuevo certificado si el certificado actual caduca o para cumplir con los nuevos requisitos de seguridad o comerciales. Para garantizar una transición sin problemas a un certificado nuevo, debe instalar el certificado nuevo en el servidor de Exchange 2013 y configurar la confianza de federación para designarlo como el nuevo certificado. Exchange 2013 distribuye automáticamente el nuevo certificado a otros servidores de Exchange 2013 de la organización. Según la topología de Active Directory, la distribución del certificado puede tardar varios minutos. Puede comprar el estado del certificado usando el cmdlet Test-FederationTrustCertificate en el Shell.

Después de comprobar el estado de distribución del certificado, puede configurar la confianza de manera que use el nuevo certificado. Luego de cambiar los certificados, el certificado actual se designa como el certificado anterior y el nuevo certificado se designa como el certificado actual. El nuevo certificado se publica en el sistema de autenticación Microsoft Entra y todos los nuevos tokens intercambiados con el sistema de autenticación Microsoft Entra se cifran mediante el nuevo certificado.

Nota:

Este proceso de transición del certificado es usado solamente por la federación. Si usa el mismo certificado para otras características de Exchange 2013 que usan certificados, debe tener en cuenta los requisitos de las características al planear obtener, instalar o cambiar a un certificado nuevo.

Consideraciones de firewall para federación

Las características de federación requieren que los servidores de buzones y de acceso de cliente de la organización tengan acceso de salida a Internet mediante HTTPS. Debe permitir el acceso HTTPS de salida (puerto 443 para TCP) desde todos los servidores de buzones y de acceso de cliente de Exchange 2013 de la organización.

Para permitir que una organización externa tenga acceso a la información de disponibilidad de su organización, debe publicar un servidor de acceso de cliente en Internet. Esto requiere acceso HTTPS de entrada desde Internet al servidor de acceso de cliente. Los servidores de acceso de cliente de los sitios de Active Directory que no tienen un servidor de acceso de cliente publicado en Internet pueden usar servidores de acceso de cliente de otros sitios de Active Directory a los que tengan acceso mediante Internet. Los servidores de acceso de cliente que no se publican en Internet deben tener la URL externa del directorio virtual de servicios que se establece con la URL que es visible a las organizaciones externas.