Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
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, vea Office 365 operado por 21Vianet.
Terminología básica
En la siguiente lista se definen los componentes principales asociados con la federación en Exchange 2013.
identificador de aplicación (AppID): un número único generado por el sistema de autenticación de Microsoft Entra para identificar organizaciones de Exchange. El 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: un token de lenguaje de marcado de aserción de seguridad (SAML) emitido por el sistema de autenticación de Microsoft Entra que permite a los usuarios de una organización federada confiar en otra 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 de Microsoft Entra para trabajar en organizaciones de Exchange, incluidas las implementaciones de Exchange entre locales. 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: un 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: una cadena criptográficamente segura utilizada por una organización de Exchange para proporcionar la prueba de que la organización es propietaria del dominio utilizado con el sistema de autenticación de 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 de persona a persona establecida por el usuario.
federación: un acuerdo basado en la 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: una 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 de Exchange federadas, se debe establecer una confianza de federación con el sistema de autenticación de Microsoft Entra.
Organización no federada: organizaciones que no tienen una confianza de federación establecida con el sistema de autenticación de Microsoft Entra.
identificador de organización (OrgID): define cuáles de los dominios autoritativos aceptados configurados en una organización están habilitados para la federación. Solo los destinatarios que tienen direcciones de correo electrónico con dominios federados configurados en el OrgID son reconocidos por el sistema de autenticación de Microsoft Entra y pueden utilizar las 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 de Exchange federadas que permite a los destinatarios compartir información de disponibilidad (disponibilidad de calendario). Una relación de organización requiere una confianza de federación con el sistema de autenticación de Microsoft Entra y reemplaza la necesidad de utilizar confianzas de bosque o de dominio de Bosque de Active Directory entre organizaciones de Exchange.
Sistema de autenticación de Microsoft Entra: 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 más información, vea Microsoft Entra ID.
Sistema de autenticación de Microsoft Entra
El sistema de autenticación Microsoft Entra, un servicio gratuito basado en la nube ofrecido por Microsoft, actúa como agente de confianza entre su 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 de Microsoft Entra para que pueda convertirse en un asociado de federación con su organización. Con esta confianza, el sistema de autenticación de Microsoft Entra emite tokens de delegación de Lenguaje de marcado de aserción de seguridad (SAML) a los usuarios autenticados por Active Directory (conocidos como proveedores de identidad). 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 sistema de autenticación Microsoft Entra actuando como agente de confianza, las organizaciones no están obligadas a 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 su organización de Exchange 2013 y el sistema de autenticación de Microsoft Entra. Establecer 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. Para establecer una confianza de federación, use 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, que se usa para firmar y cifrar los tokens de delegación del sistema de autenticación de Microsoft Entra que permiten a las organizaciones federadas externas confiar en los usuarios. Para obtener más información sobre los requisitos de certificado, consulte Requisitos de certificado para la federación más adelante en este tema.
Cuando crea 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 el resultado del cmdlet Get-FederationTrust. El sistema de autenticación de Microsoft Entra utiliza el AppID para identificar de forma única su organización de Exchange. También lo usa la organización Exchange para proporcionar una prueba de que su organización es propietaria del dominio para usarlo con el sistema de autenticación 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 tengan direcciones de correo electrónico con dominios aceptados configurados en el OrgID son reconocidos por el sistema de autenticación de Microsoft Entra y pueden utilizar las 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 Microsoft Entra y configura su espacio de nombres de cuenta para incluir el dominio utilizado para el dominio de dirección de correo electrónico de su 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 estén incluidos en el espacio de nombres de cuenta para su confianza de federación con el sistema de autenticación de 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
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 usado para crear la confianza. Recomendamos encarecidamente el uso de 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 que se usan 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 CA 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 del sujeto: el certificado debe tener un campo de identificador de clave del sujeto. 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 utilizar un CSP 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 el algoritmo de firma.
Clave privada exportable: La clave privada utilizada 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 estar vigente. 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 tokens nuevos intercambiados con el sistema de autenticación Microsoft Entra se cifran con 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.