Modelo de permisos de transporte de Exchange 2007

Artículo
06/27/2014

Se aplica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Última modificación del tema: 2007-08-27

En este tema se proporciona información detallada acerca del modelo de permisos de transporte de Microsoft Exchange Server 2007. En Microsoft Exchange Server 2007, "transporte" hace referencia al proceso de transferencia de mensajes de un servidor a otro. Cuando los mensajes se transfieren entre un servidor de buzones y el servidor Concentrador de transporte, se usa el protocolo MAPI. Cuando los mensajes se envían y reciben entre servidores Concentrador de transporte, se usa el Protocolo simple de transferencia de correo (SMTP). En cada sesión de comunicación entre servidores puede haber una fase de autenticación opcional. Las solicitudes de conexión pueden exigir comprobaciones de autorización.

Autenticación es el proceso con el que se trata de identificar al remitente de un mensaje. Si no se lleva a cabo la autenticación o se produce un error de autenticación, la identidad del remitente es anónima. Autorización es el proceso que determina si se debe permitir que el usuario, programa o dispositivo que establece la conexión tenga acceso a datos, funciones o servicios. El acceso depende de la acción solicitada. El proceso de autenticación comprueba la identidad. El proceso de autorización determina el nivel de acceso que se concede.

En Exchange 2007, el servicio Transporte de Microsoft Exchange proporciona los protocolos SMTP y MAPI. En sesiones en que se usan los protocolos SMTP o MAPI, el servicio Transporte de Microsoft Exchange utiliza el modelo de autorización de Microsoft Windows para administrar los permisos de una sesión. En el contexto del transporte de Exchange 2007, la autorización tiene relación con la aceptación de diversos verbos o eventos de protocolo. Por ejemplo, la autorización comprobará los permisos que permiten al remitente enviar un mensaje desde una dirección de correo electrónico concreta o admiten un tamaño de los mensajes concreto. Durante las conversaciones con los protocolos MAPI y SMTP, Exchange 2007 puede realizar la autenticación de la sesión. Una vez que se ha autenticado una sesión, los grupos de permisos disponibles para la sesión pueden cambiar como consecuencia de la autenticación. De esta forma, los mensajes anónimos de Internet y los mensajes enviados por los usuarios autenticados de la organización de Exchange se pueden procesar de manera diferente en función de los distintos grupos de permisos concedidos por la autenticación.

El comportamiento predeterminado del transporte en una función del servidor Transporte perimetral es distinto al de una función del servidor Concentrador de transporte. Esta diferencia no se debe a una variación del código. La causa es la diferencia del conjunto de permisos predeterminado de cada función. Los servidores de Exchange que forman parte del mismo bosque de Active Directory tienen una relación de confianza. Esta relación de confianza quiere decir que los permisos predeterminados configurados durante la instalación permiten el flujo de correo seguro dentro del bosque.

Cada sesión autenticada presenta un token de acceso en el que se muestra el identificador de seguridad de cada grupo al que pertenece la entidad principal de seguridad de autenticación. En la figura 1 se muestra la relación existente entre las pertenencias a grupos mostradas en el token de acceso y los permisos asignados a los grupos para el objeto al que se tiene acceso.

Figura 1 Componentes de autorización de transporte de Exchange 2007

Componentes de la autorización de Transporte de Exchange

Diferencia entre sesiones autenticadas y mensajes autenticados

Un concepto muy importante del modelo de transporte de Exchange 2007 es la diferencia entre las sesiones de transporte autenticadas y los mensajes autenticados. Un mensaje puede estar marcado con metadatos que indiquen si está autenticado o es anónimo. Si un servidor autentica a otro, puede enviar un mensaje y lo marca con metadatos que indican si el mensaje está autenticado o es anónimo. El servidor receptor determina si la marca autenticada es de confianza. Si el servidor receptor confía en el remitente, la marca autenticada se deja como está. Si el servidor receptor no confía en el remitente, invalidará la marca autenticada del servidor remitente y marcará el mensaje con metadatos que indican que el mensaje es anónimo. En una organización de Exchange, el flujo de correo interno de un extremo a otro tiene lugar entre servidores que confían en la marca del mensaje autenticado. Un servidor Transporte perimetral que recibe mensajes de Internet no confía en la marca autenticada de servidores anónimos de Internet. Por lo tanto, el servidor Transporte perimetral marca cada mensaje con metadatos que indican que el mensaje es anónimo antes de enviarlo a un servidor Concentrador de transporte a través de una conexión autenticada.

Funcionamiento del proceso de autenticación y autorización del transporte de mensajes

En Exchange 2007, están disponibles los siguientes mecanismos básicos para autenticar una sesión de SMTP:

Puede usar una cuenta y contraseña de Windows en una sesión MAPI. Si lo prefiere, puede usar la extensión AUTH de SMTP. Se puede usar la autenticación de contraseña de texto sin formato, la autenticación NTLM y la autenticación Kerberos.
Puede usar un certificado X.509, con la extensión STARTTLS de SMTP. En este escenario, el servidor proporciona un certificado como parte de la negociación de Seguridad del nivel de transporte (TLS). De manera opcional, el cliente proporciona también un certificado.
Puede usar un mecanismo de autenticación externo. En la autenticación externa se usa un mecanismo que no forma parte de Exchange, por ejemplo una red protegida físicamente o IPsec. Este método se usa cuando la comunicación tiene lugar a través de rutas IP identificadas en conectores de envío y de recepción.

El servidor de transporte remitente se puede autenticar en el servidor de transporte receptor antes de enviar el mensaje. Una vez que se autentica el remitente, el servidor de transporte receptor aplica al token de acceso de la sesión los permisos concedidos al remitente.

En Exchange 2007, los conectores de envío y de recepción administran el flujo de correo. Los conectores disponen de una lista de control de acceso discrecional (DACL) en la que se definen los permisos asociados al envío y recepción de correo electrónico. Los permisos de los conectores de recepción son muy importantes. La lista DACL del conector de recepción determina los permisos del remitente para los mensajes que se envían a través del conector de recepción. Una vez que se establece una sesión de SMTP con un conector de recepción, la sesión se inicia con un token de acceso anónimo. La autenticación correcta subsiguiente cambia el token de acceso. Si una sesión no se autentica, los grupos de permisos del token de acceso se quedan igual. Si la sesión se autentica, recibe los permisos asignados a la cuenta o función concreta y los permisos asignados a los grupos de seguridad a los que pertenezca la cuenta.

El gráfico de la Figura 2 ilustra cómo los servidores de transporte de Exchange 2007 utilizan la autenticación y autorización en las sesiones de SMTP.

Figura 2 Proceso de autenticación y autorización de las sesiones de SMTP

Diagrama con proceso de autenticación de la sesión SMTP

Configuraciones de autenticación

El conjunto de mecanismos de autenticación configurados para un conector de recepción determina los mecanismos de autenticación disponibles para las sesiones que envían mensajes al conector de recepción. El mecanismo de autenticación configurado para un conector de envío determina el mecanismo de autenticación que usará dicho conector para autenticarse en un host inteligente.

Autenticación de conectores de recepción

Puede configurar más de un mecanismo de autenticación en un conector de recepción. En un conector de recepción, la configuración de autenticación determina el conjunto de mecanismos de autenticación habilitados para el servidor para autenticar las sesiones que envían mensajes al servidor. El servidor de envío determina el mecanismo de autenticación que se utiliza.

En la tabla 1 se muestran los mecanismos de autenticación que se pueden configurar en un conector de recepción. Para configurar el mecanismo de autenticación del conector de recepción, use la ficha Autenticación de las propiedades del conector de recepción en la Consola de administración de Exchange o el parámetro AuthMechanism con el cmdlet Set-ReceiveConnector en el Shell de administración de Exchange.

Tabla 1 Mecanismos de autenticación para los conectores de recepción

Mecanismo de autenticación	Descripción
Ninguno	No se ofrecen opciones de autenticación.
Seguridad del nivel de transporte (TLS)	El conector ofrece STARTTLS a los clientes.
Autenticación de Windows integrada	El conector ofrece AUTH y NTLM GSSAPI a los clientes. GSSAPI permite que los clientes negocien NTLM o Kerberos.
Autenticación básica	El conector ofrece AUTH y LOGIN a los clientes. El nombre de usuario y la contraseña se reciben del cliente como texto no cifrado. Este mecanismo requiere que una cuenta de Windows para validar las credenciales.
Autenticación básica a través de TLS	Es el modificador de directiva de la autenticación básica. El conector ofrece al cliente AUTH y LOGIN una vez que el cliente ha negociado TLS. Este mecanismo requiere también que TLS esté configurado como mecanismo de autenticación.
Autenticación de servidor de Exchange	El conector ofrece EXPS y GSSAPI a los servidores de Exchange en que se estén ejecutando versiones anteriores de Exchange Server y X-ANONYMOUSTLS a los clientes de servidores de Exchange 2007.
Con seguridad externa (por ejemplo, IPsec)	En esta opción se considera que todas las conexiones proceden de otro servidor con autoridad.

Autenticación para conectores de envío de host inteligente

En los conectores de envío, la opción SmartHostAuthMechanism determina cómo se autentica el servidor de envío en el host inteligente de destino. La opción SmartHostAuthMechanism sólo puede tener un valor. Si se configura la opción SmartHostAuthMechanism, la autenticación debe ser correcta para que se envíe el correo. Si el host inteligente no proporciona el mecanismo de autenticación utilizado por el servidor de envío de Exchange 2007, el servidor no enviará mensajes de correo electrónico y la sesión finalizará. Si se proporciona el mecanismo de autenticación utilizado por el servidor de envío de Exchange 2007, pero se produce un error de autenticación, el servidor tampoco enviará mensajes de correo electrónico y la sesión finalizará

En la tabla 2 se muestran los mecanismos de autenticación que se pueden configurar en un conector de envío. Para configurar el mecanismo de autenticación del conector de envío, use el cuadro de diálogo Configurar la autenticación del host inteligente de la ficha Red de las propiedades del conector de envío en la Consola de administración de Exchange o el parámetro SmartHostAuthMechanism con el cmdlet Set-SendConnector en el Shell de administración de Exchange.

Tabla 2 Mecanismos de autenticación para los conectores de host inteligente

Mecanismo de autenticación	Descripción
Ninguno	Se permite el acceso anónimo.
Autenticación básica	El conector debe usar AUTH y LOGIN. Requiere que se proporcione un nombre de usuario y contraseña. La autenticación básica envía las credenciales como texto no cifrado. Todos los host inteligentes en los que se esté autenticando este conector de envío deben aceptar el mismo nombre de usuario y contraseña. Si el parámetro RequireTLS se establece también en `$True`, el conector utiliza TLS antes de enviar las credenciales, pero no se realiza la comprobación del certificado del servidor.
La autenticación básica requiere TLS	Es un modificador de directiva de la autenticación básica. Requiere que el conector use TLS antes de tratar de usar AUTH. Requiere también que el servidor de envío realice la validación del certificado X.509 del servidor de recepción. La validación de certificados incluye la comprobación de la lista de revocación de certificados (CRL) y la comparación de la identidad del servidor con la lista de hosts inteligentes configurados en el conector antes de que intente usar AUTH. Uno de los nombres de dominio completos (FQDN) mencionados como host inteligentes debe estar presente en el certificado del servidor para que la coincidencia de nombres tenga un resultado correcto. Por lo tanto, si el FQDN del host inteligente indica un registro MX, el FQDN de host inteligente mencionado debe estar presente en el certificado.
Autenticación de servidor de Exchange	El conector debe usar EXPS y GSSAPI para los servidores de Exchange en que se estén ejecutando versiones anteriores de Exchange Server, o usar X-ANONYMOUSTLS para los servidores de Exchange 2007.
Con seguridad externa (por ejemplo, IPsec)	La conexión con la red se protege mediante un método externo al servidor de Exchange.

Seguridad de nivel de transporte

El protocolo TLS se describe en RFC 2246. TLS usa certificados X.509. Estos certificados son un tipo de credencial electrónica. TLS se puede usar como se indica a continuación:

Sólo con fines de confidencialidad.
Para la autenticación del servidor con confidencialidad si se valida el certificado del servidor.
Para la autenticación mutua con confidencialidad si se validan los certificados del cliente y del servidor.

Durante la conversación con el protocolo SMTP, el cliente emite el comando SMTP STARTTLS para solicitar que TLS se negocie para esta sesión. El cliente recibe un certificado X.509 del servidor como parte de la negociación del protocolo TLS. La directiva de autenticación del cliente determina si el certificado del servidor de recepción debe ser validado y si se debe aplicar algún otro criterio al certificado, por ejemplo la coincidencia de nombres.

Una parte opcional de la negociación de TLS permite que el servidor de recepción solicite también un certificado del servidor de envío. Si el servidor de envío envía un certificado al servidor de recepción, la directiva local del servidor de recepción determina cómo se valida el certificado y qué permisos se conceden al servidor de envío como consecuencia de la autenticación.

Cuando se usa TLS para la autenticación de servidores, sólo se valida el certificado del servidor de recepción. Si se usa TLS para obtener la autenticación mutua, se deben validar los certificados del servidor de envío y del servidor de recepción.

Cuando TLS se configura en un conector de recepción de Exchange 2007, el servidor debe tener un certificado X.509. Este certificado puede ser un certificado con firma personal o uno firmado por una entidad de certificación (CA). El servidor de Exchange busca un certificado en el almacén local que coincida con el FQDN del conector. El servidor de envío selecciona la forma en que se utiliza el protocolo TLS. Si Exchange usa TLS sólo con fines de confidencialidad, el cliente de Exchange no valida el certificado. Por ejemplo, cuando Exchange usa TLS entre servidores Concentrador de transporte utilizando la autenticación Kerberos a través del protocolo TLS, establece un canal de confianza entre los servidores y no lleva a cabo la validación del certificado. La autenticación entre los servidores tiene lugar mediante Kerberos una vez que finaliza el protocolo TLS.

Si se requiere la autenticación TLS, Exchange debe validar el certificado. Exchange puede validar el certificado de dos maneras: confianza directa o validación X.509. Cuando TLS se usa para la comunicación de un servidor Transporte perimetral con un servidor Concentrador de transporte, Exchange utiliza un mecanismo de confianza directa para validar el certificado.

Confianza directa quiere decir que Exchange usa un almacén de confianza, como Active Directory o Active Directory Application Mode (ADAM). Además, la confianza directa quiere decir que el certificado queda validado por su presencia en el almacén. Si se usa la confianza directa, da igual que el certificado tenga una firma personal o esté firmado por una entidad de certificación. Al suscribir un servidor Transporte perimetral a la organización de Exchange, la suscripción publica el certificado del servidor Transporte perimetral en Active Directory para que se validen los servidores Concentrador de transporte. El servicio Microsoft Exchange Edgesync actualiza ADAM con el conjunto de certificados de servidor Concentrador de transporte para que se valide el servidor Transporte perimetral.

El otro método que utiliza Exchange para validar certificados es la validación X.509. Si se usa la validación X.509, el certificado debe estar firmado por una entidad de certificación. Exchange usa la validación X.509 al autenticar hosts inteligentes o al usar la seguridad de dominio. La seguridad de dominio se explica en la siguiente sección.

Seguridad de dominio

La seguridad de dominio hace referencia al conjunto de funciones de Exchange 2007 y Microsoft Office Outlook que representa una alternativa relativamente económica a S/MIME u otras soluciones de seguridad del nivel de los mensajes. La finalidad de la seguridad de dominio es la de proporcionar a los administradores una forma de administrar rutas de acceso seguras a mensajes con socios comerciales a través de Internet. Una vez que se han configurado estas rutas de acceso seguras a mensajes, los mensajes que se han transferido correctamente por ellas desde un remitente autenticado se muestran a los usuarios como "de dominio seguro en las interfaces de Outlook y Outlook Web Access.

Un conector de envío comprueba que el dominio de destino está en la lista de dominios de envío configurados para la seguridad de dominio si se dan las condiciones siguientes:

El conector de envío se ha configurado para enrutar los mensajes mediante registros de recursos de intercambio de correo (MX) del Sistema de nombres de dominio (DNS).
El conector de envío se ha configurado como de dominio seguro.

Si el dominio de destino está en la lista, el servidor de transporte fuerza la autenticación TLS mutua al enviar correo electrónico al dominio.

El servidor de recepción responde con un comando SMTP QUIT si se cumplen las siguientes condiciones:

Exchange no puede negociar TLS
Se produce un error de validación del certificado o de CRL.

En ese caso, los mensajes se quedan en la cola del servidor de envío. La cola está en un estado de reintento. Este comportamiento se da también si se produce un error de comprobación del nombre.

Si el conector de recepción es de dominio seguro, el servidor de transporte comprueba el correo recibido. A continuación, el servidor de transporte fuerza la autenticación TLS mutua si el remitente está en la lista de dominios de recepción configurados para la seguridad de dominio. Si se superan todas las comprobaciones, el mensaje se marca como "de dominio seguro". Si el remitente no puede negociar TLS, o se produce un error de validación del certificado del servidor o comprobación de CRL, el servidor de transporte rechaza el mensaje mediante el comando REJECT del protocolo SMTP. Si se da un error de comprobación del nombre, también se produce el comando REJECT del protocolo SMTP. Entonces, el servidor Exchange manda al servidor de envío un mensaje con un error temporal de SMTP (4xx). Esto indica que el servidor de envío debe volver a intentarlo más adelante. Este comportamiento evita que los errores transitorios causados por errores de comprobación de CRL temporales generen el envío de una notificación NDR al remitente. El error únicamente demora la entrega del mensaje.

Para obtener más información, consulte Administrar la seguridad de dominio (en inglés).

Autenticación con seguridad externa

Puede seleccionar la opción de autenticación con seguridad externa si está convencido de que la conexión de los servidores a través de la red es de confianza. La conexión puede ser una asociación IPsec o una red privada virtual. También puede ser que los servidores se encuentren en una red de confianza controlada físicamente. Esta configuración resulta útil en el siguiente caso:

Establece el flujo de correo entre un servidor de transporte de Exchange 2007 y una versión anterior de Exchange Server o cualquier otro servidor SMTP.
No desea usar la autenticación básica.

Los conectores de Exchange configurados con seguridad externa deben usar conectores de envío y de recepción dedicados, ya que se asume que todas las conexiones con los conectores son seguras. Por ello, los conectores de envío configurados con seguridad externa deben usar un host inteligente para enrutar los mensajes. Además, las direcciones IP de los hosts inteligentes de destino se deben configurar en el conector. Los conectores de recepción configurados con seguridad externa deben tener el parámetro RemoteIPRanges configurado en el intervalo de direcciones IP de los servidores de envío. TLS también se puede combinar con la opción de autenticación con seguridad externa para agregar la confidencialidad de sesión. Puede hacerlo así en el Shell de administración de Exchange si establece el parámetro RequireTLS de los conectores en $True.

Autorización

Durante el transporte de mensajes, la autorización es el proceso que determina si una acción solicitada como, por ejemplo, el envío de correo, se admite en una sesión de SMTP.

Permisos de transporte de Exchange 2007

Los servidores de transporte de Exchange 2007 usan el modelo de autorización de Windows en una sesión de SMTP para determinar si el remitente está autorizado a enviar mensajes, por ejemplo, a un conector concreto, a un destinatario concreto y como un remitente concreto. Una sesión SMTP recibe un conjunto de permisos inicial (anónimo). Una vez que la sesión queda autenticada, tiene más permisos a su disposición. Así se cambia el conjunto de acciones autorizadas para la sesión.

En el modelo de autorización de Windows, los permisos se conceden por medio de una interacción de control de acceso en la que se compara el token de acceso con las listas de control de acceso (ACL). Un token de acceso enumera un conjunto de entidades principales de seguridad. Una entidad principal de seguridad puede ser una cuenta de usuario, una cuenta de equipo o un grupo de seguridad. Cada entidad principal de seguridad tiene asociado un identificador de seguridad (SID). A cada sesión se le asigna un token de acceso. Las ACL se definen en el objeto conector de Active Directory o ADAM. Una DACL contiene un conjunto de entradas de control de acceso (ACE). Cada ACE admite o deniega un permiso a una entidad principal de seguridad. Cuando el servidor de transporte realiza una comprobación para determinar si se concede un permiso a la sesión, por ejemplo de envío de correo electrónico, llama a una API de comprobación de acceso de Windows y proporciona el token de acceso de la sesión y la DACL del conector como parámetros, junto con el permiso solicitado.

Este proceso es idéntico al de determinar el permiso de lectura de un archivo. El token de acceso, la DACL del archivo y el permiso solicitado se envían a la misma API. La API comprueba si las entidades principales de seguridad enumeradas en el token de acceso están en todas las ACE de la DACL para determinar si el permiso solicitado se concede o se deniega. Además de los identificadores SID de Windows proporcionados por Active Directory, ADAM, o la base de datos del Administrador de cuentas de seguridad (SAM) local de un equipo, Exchange 2007 define SID adicionales. Estos SID representan grupos lógicos. En la Tabla 3 se muestran los SID definidos por Exchange 2007 para su uso durante la autenticación del transporte.

Tabla 3 SID de Exchange 2007

Nombre para mostrar	SID	Grupo lógico
Servidores asociados	S-1-9-1419165041-1139599005-3936102811-1022490595-10	Dominios de envío y de recepción configurados para la seguridad de dominio.
Servidores Concentrador de transporte	S-1-9-1419165041-1139599005-3936102811-1022490595-21	Servidores Concentrador de transporte de la misma organización de Exchange.
Servidores Transporte perimetral	S-1-9-1419165041-1139599005-3936102811-1022490595-22	Servidores Transporte perimetral de confianza.
Servidores con seguridad externa	S-1-9-1419165041-1139599005-3936102811-1022490595-23	Servidores de otros fabricantes de confianza que estén en el mismo dominio con autoridad.
Servidores de Exchange heredados	S-1-9-1419165041-1139599005-3936102811-1022490595-24	Servidores de Exchange Server 2003 que estén en la misma organización de Exchange.

Permisos de conector de recepción

Los conectores de recepción procesan las sesiones entrantes del servidor. La sesión puede ser establecida por un remitente autenticado o anónimo. Si una sesión se autentica correctamente, se actualizan los SID del token de acceso de la sesión. En la Tabla 4 se enumeran los permisos que se pueden conceder a una sesión que se conecta a un conector de recepción.

Tabla 4 Permisos de conector de recepción

Permiso	Nombre para mostrar	Descripción
ms-Exch-SMTP-Submit	Enviar mensajes al servidor	La sesión debe disponer de este permiso, o de lo contrario no podrá enviar mensajes al conector de recepción. Si una sesión no dispone de este permiso, el comando MAIL FROM producirá un error.
ms-Exch-SMTP-Accept-Any-Recipient	Enviar mensajes a cualquier destinatario	Este permiso hace que la sesión pueda retransmitir mensajes a través de este conector. Si no se concede este permiso, este conector sólo aceptará los mensajes a los destinatarios de dominios aceptados.
ms-Exch-SMTP-Accept-Any-Sender	Aceptar todos los remitentes	Con este permiso, la sesión puede omitir la comprobación de suplantación de la dirección del remitente.
ms-Exch-SMTP-Accept-Authoritative-Domain-Sender	Aceptar remitentes de dominios con autoridad	Con este permiso, la sesión omite una comprobación que rechaza los mensajes entrantes de direcciones de correo electrónico de dominios con autoridad.
ms-Exch-SMTP-Accept-Authentication-Flag	Aceptar el marcador de autenticación	Con este permiso, los servidores de Exchange con versiones anteriores de Exchange Server pueden enviar mensajes de remitentes internos. Los servidores de Exchange 2007 reconocen el mensaje como interno.
ms-Exch-Accept-Headers-Routing	Aceptar encabezados de enrutamiento	Con este permiso, la sesión puede enviar un mensaje que deja todos los encabezados recibidos como están. Si no se concede el permiso, el servidor elimina todos los encabezados recibidos.
ms-Exch-Accept-Headers-Organization	Aceptar encabezados de organización	Con este permiso, la sesión puede enviar un mensaje que deja todos los encabezados de organización como están. Todos los encabezados de organización empiezan por “X-MS-Exchange-Organization-“. Si no se concede el permiso, el servidor de recepción elimina todos los encabezados de organización.
ms-Exch-Accept-Headers-Forest	Aceptar encabezados de bosque	Con este permiso, la sesión puede enviar un mensaje que deja todos los encabezados de bosque como están. Todos los encabezados de bosque empiezan por “X-MS-Exchange-Forest-“. Si no se concede el permiso, el servidor de recepción elimina todos los encabezados de bosque.
ms-Exch-Accept-Exch50	Aceptar Exch50	Con este permiso, la sesión puede enviar un mensaje que contenga el comando XEXCH50. Este comando es necesario por razones de interoperabilidad con Exchange 2000 Server y Exchange 2003. El comando XEXCH50 proporciona datos, por ejemplo el nivel de confianza del correo no deseado (SCL), para el mensaje.
ms-Exch-Bypass-Message-Size-Limit	Omitir tamaño límite de mensajes	Con este permiso, la sesión puede enviar un mensaje en el que no se tenga en cuenta la restricción del tamaño de los mensajes configurada para el conector.
Ms-Exch-Bypass-Anti-Spam	Omitir filtros contra el correo no deseado	Con este permiso, en la sesión se pueden omitir los filtros de correo no deseado.

Permisos de conector de envío

Los conectores de envío procesan las sesiones salientes hacia otro servidor. El remitente puede establecer la sesión en un receptor anónimo o en uno autenticado. Si la sesión se autentica correctamente, se actualiza el conjunto de SID del token de acceso de la sesión. Los permisos del conector de envío determinan los tipos de información de encabezado que se pueden incluir en un mensaje que se envían utilizando el conector. Los mensajes que se envían a otros servidores de Exchange de la organización o a una organización de Exchange de confianza en un escenario entre bosques se pueden enviar normalmente con todos los encabezados. Los mensajes que se envían a Internet o a servidores SMTP que no son de Exchange no pueden contener todos los encabezados. Si se incluyen los encabezados en el mensaje, la funcionalidad de firewall de encabezados de Exchange 2007 los elimina. En la Tabla 5 se enumeran los permisos que se pueden conceder a una sesión que se conecta a un conector de envío.

Tabla 5 Permisos de conector de envío

Permiso	Nombre para mostrar	Descripción
ms-Exch-Send-Exch50	Send Exch50	Con este permiso, la sesión puede enviar un mensaje que contenga el comando EXCH50. Si no se concede este permiso, el servidor envía el mensaje, pero no incluye el comando EXCH50.
Ms-Exch-Send-Headers-Routing	Enviar encabezados de enrutamiento	Con este permiso, la sesión puede enviar un mensaje que deja todos los encabezados recibidos como están. Si no se concede el permiso, el servidor elimina todos los encabezados recibidos.
Ms-Exch-Send-Headers-Organization	Enviar encabezados de organización	Con este permiso, la sesión puede enviar un mensaje que deja todos los encabezados de organización como están. Todos los encabezados de organización empiezan por “X-MS-Exchange-Organization-“. Si no se concede el permiso, el servidor de envío elimina todos los encabezados de organización.
Ms-Exch-Send-Headers-Forest	Enviar encabezados de bosque	Con este permiso, la sesión puede enviar un mensaje que deja todos los encabezados de bosque como están. Todos los encabezados de bosque empiezan por “X-MS-Exchange-Forest-“. Si no se concede el permiso, el servidor de envío elimina todos los encabezados de bosque.

Grupos de permisos

Un grupo de permisos es un conjunto de permisos predefinido que se puede conceder a un conector de recepción. Los grupos de permisos sólo están disponibles para los conectores de recepción. El uso de los grupos de permisos simplifica la configuración de los permisos en los conectores de recepción. La propiedad PermissionGroups define los grupos o funciones que pueden enviar mensajes al conector de recepción y los permisos admitidos en dichos grupos. El conjunto de grupos de permisos está predefinido en Exchange 2007, por lo que no se pueden crear grupos de permisos adicionales. Además, tampoco se pueden modificar los miembros de un grupo de permisos ni los permisos asociados.

En la Tabla 6 se muestran los grupos de permisos, los miembros de los grupos de permisos y los permisos asociados de Exchange 2007.

Tabla 6 Grupos de permisos y permisos asociados de los conectores de recepción

Nombre del grupo de permisos	Entidad principal de seguridad	Permisos concedidos a los servidores Transporte perimetral	Permisos concedidos a los servidores Concentrador de transporte
Anónimo	Usuarios anónimos	Enviar mensajes al servidor Aceptar todos los remitentes Aceptar encabezados de enrutamiento	Enviar mensajes al servidor Aceptar todos los remitentes Aceptar encabezados de enrutamiento
ExchangeUsers	Usuarios autenticados (se excluyen las cuentas conocidas)	No disponible	Enviar mensajes al servidor Aceptar todos los destinatarios Omitir filtros contra correo no deseado
Servidores Exchange	Servidores de Exchange 2007	Todos los permisos de recepción	Todos los permisos de recepción
ExchangeLegacyServers	Servidores de Exchange 2003 y Exchange 2000	No disponible	Enviar mensajes al servidor Enviar mensajes a cualquier destinatario Aceptar todos los remitentes Aceptar remitentes de dominios con autoridad Aceptar el marcador de autenticación Aceptar encabezados de enrutamiento Aceptar Exch50 Omitir tamaño límite de mensajes Omitir filtros contra correo no deseado
Asociado	Cuenta de servidor asociado	Enviar mensajes al servidor Aceptar encabezados de enrutamiento	Enviar mensajes al servidor Aceptar encabezados de enrutamiento

Tipos de uso de los conectores

Cuando se crea un conector nuevo, se puede especificar un tipo de uso para aplicárselo. El tipo de uso determina la configuración predeterminada del conector. La configuración indica los SID que están autenticados, los permisos asignados a dichos SID y el mecanismo de autenticación.

En la Tabla 7 se enumeran los tipos de usos disponibles de los conectores de recepción. Al seleccionar un tipo de uso para un conector de recepción, se asignan automáticamente grupos de permisos al conector. También se configura un mecanismo de autenticación predeterminado.

Tabla 7 Tipos de uso de los conectores de recepción

Tipo de uso	Grupos de permisos predeterminados	Mecanismo de autenticación predeterminado
Cliente	ExchangeUsers	TLS. BasicAuthPlusTLS.
Custom	Ninguno	Ninguna.
Interno	ExchangeServers ExchangeLegacyServers	Autenticación de Exchange Server.
Internet	AnonymousUsers Asociado	Ninguno o con seguridad externa.
Asociado	Asociado	No aplicable. Este tipo de uso se selecciona si se establece la autenticación TLS mutua con un dominio remoto.

En la Tabla 8 se enumeran los tipos de usos disponibles de los conectores de envío. Al seleccionar un tipo de uso para un conector de envío, se asignan automáticamente permisos a los SID. También se configura un mecanismo de autenticación predeterminado.

Tabla 8 Tipos de uso de los conectores de envío

Tipo de uso	Permisos predeterminados	Entidad principal de seguridad	Mecanismo de autenticación predeterminado de los hosts inteligentes
Custom	Ninguno	Ninguno	Ninguno
Interno	Enviar encabezados de organización Send Exch50 Enviar encabezados de enrutamiento Enviar encabezados de bosque	Servidores Concentrador de transporte Servidores Transporte perimetral Grupo de seguridad de servidores de Exchange Servidores con seguridad externa Grupo de seguridad de interoperabilidad heredado de Exchange Servidores cabeza de puente de Exchange 2003 y Exchange 2000	Autenticación de Exchange Server.
Internet	Enviar encabezados de enrutamiento	Cuenta de usuario anónima	Ninguna.
Asociado	Enviar encabezados de enrutamiento	Servidores asociados	No aplicable. Este tipo de uso se selecciona si se establece la autenticación TLS mutua con un dominio remoto.

Si selecciona el tipo de uso personalizado para un conector de envío o de recepción, debe configurar manualmente el método de autenticación y los SID autorizados, y debe asignar permisos a dichos SID. Si no especifica ningún tipo de uso para el conector, se establece en personalizado.

Establecer permisos mediante el script Enable-CrossForestConnector

Puede usar el script Enable-CrossForestConnector.ps1 para simplificar la manera de configurar los permisos de conectores entre bosques. El script asigna los permisos de una forma que se parece a los grupos de permisos. Se asigna un conjunto de permisos definido a un conector de envío o recepción. Este conjunto de permisos se puede modificar según sea necesario en el escenario de las conexiones, modificando el contenido del script Enable-CrossForestConnector.ps1. Para obtener más información, consulte Configuración de los conectores entre bosques (en inglés).

Establecer permisos mediante el cmdlet Add-AdPermission

El cmdlet Add-AdPermission del Shell de administración de Exchange es un cmdlet global que se usa para asignar permisos a objetos almacenados en Active Directory. Puede usar el cmdlet Add-AdPermission para conceder permisos concretos a un conector de envío o de recepción. El cmdlet Add-AdPermission no se usa normalmente para administrar permisos de transporte. Sin embargo, sí que debe usarse para configurar permisos en los siguientes escenarios:

Establecer el flujo de correo en un escenario entre bosques.
Aceptar correo electrónico anónimo de Internet de un remitente de un dominio con autoridad.

Los permisos de transporte de Exchange 2007 forman parte del conjunto de derechos extendidos que se pueden asignar mediante este cmdlet. En el procedimiento siguiente se muestra cómo usar el cmdlet Add-AdPermission para establecer permisos en un conector de recepción de servidor Concentrador de transporte para que las sesiones anónimas puedan enviar mensajes:

Cómo establecer permisos en un conector de recepción mediante el Shell de administración de Exchange

Ejecute el siguiente comando:

Add-AdPermission -Identity "Default Hub1" -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights ms-Exch-SMTP-Submit,ms-Exch-SMTP-Accept-Any-Recipient,ms-Exch-Bypass-Anti-Spam

Puede usar el cmdlet Get-AdPermission para ver la lista de control de acceso discrecional de un conector de envío o de recepción. Ejecute uno de los comandos siguientes para recuperar los permisos asignados a un conector de recepción y mostrar los resultados en una tabla con formato:

Cómo ver los permisos extendidos de un conector de recepción mediante el Shell de administración de Exchange

Ejecute uno de los siguientes comandos:

Get-AdPermission -Identity "Default ServerName" | format-table -view User
Get-AdPermission -Identity "Default ServerName" | format-table -view Identity

Puede usar el cmdlet Remove-AdPermission para quitar todos los permisos asignados anteriormente.

Para obtener más información acerca de cómo establecer, agregar y quitar permisos mediante el Shell de administración de Exchange, consulte los siguientes temas (en inglés):

Establecer permisos mediante Edición de ADSI

Edición de Interfaces del servicio Active Directory (ADSI) es una consola de administración de Microsoft incluida en las Herramientas de soporte técnico de Windows. Edición de ADSI se usa como editor de nivel inferior para modificar las propiedades de objetos de Active Directory o ADAM que no se exponen en otras interfaces de administración. Sólo los administradores con mucha experiencia deben usar Edición de ADSI.

Puede usar Edición de ADSI para ver y modificar las listas de control de acceso de los conectores de envío y de recepción. Una vez que abra Edición de ADSI, puede buscar el objeto del conector. Los conectores de Exchange 2007 se almacenan en la partición de configuración del servicio de directorios. Los conectores de envío se almacenan como un objeto en el contenedor de conexiones. Los conectores de recepción se almacenan como un objeto secundario del servidor de transporte de Exchange 2007.

Para modificar los permisos de los conectores de recepción mediante Edición de ADSI:

Busque el conector de recepción en la siguiente ubicación:

CN=Configuration\CN=Services\CN=Microsoft Exchange\CN=<Organization>\CN=Administrative Groups\CN=Exchange Administrative Group (FYDIBOHF23SPDLT)\CN=Servers\CN=<Server Name>\CN=Protocols\CN=SMTP Receive Connectors
Seleccione un conector de recepción en el panel de resultados. Haga clic con el botón secundario y, a continuación, haga clic en Propiedades.
Haga clic en la ficha Seguridad. Aparecerá la siguiente pantalla:
Haga clic en Agregar para seleccionar el usuario o grupo al que se van a conceder los permisos, o seleccione una entrada Nombre de grupo o de usuario existente.
Seleccione los permisos que se deben asignar a la cuenta y active la casilla de la columna Permitir.

Para modificar los permisos de los conectores de envío mediante Edición de ADSI:

Busque el conector de envío en la siguiente ubicación:

CN=Configuration\CN=Services\CN=Microsoft Exchange\CN=<Organization>\CN=Administrative Groups\CN=Exchange Administrative Group(FYDIBOHF23SPDLT)\CN=Routing Groups\CN=Routing Group (DWBGZMFD01QNBJR)\CN=Connections
Seleccione un conector de envío en el panel de resultados. Haga clic con el botón secundario y, a continuación, haga clic en Propiedades.
Haga clic en la ficha Seguridad. Aparecerá la siguiente pantalla:
Haga clic en Agregar para seleccionar el usuario o grupo al que se van a conceder los permisos, o seleccione una entrada Nombre de grupo o de usuario existente.
Seleccione los permisos que se deben asignar a la cuenta y active la casilla de la columna Permitir.

Solucionar problemas de permisos

Durante la conversación con el protocolo, el servidor SMTP podría rechazar ciertos comandos porque faltan permisos. En la Tabla 9 se enumeran los mensajes de rechazo del protocolo más habituales y la configuración de los permisos que causa el error.

Tabla 9 Mensajes de rechazo de protocolo habituales y sus causas

Respuesta del servidor SMTP	Causa
530 5.7.1 El cliente no se autenticó	El remitente especificado en el campo MAIL FROM del protocolo SMTP no tiene permiso para enviar a este servidor. Se debe conceder al remitente el permiso ms-Exch-SMTP-Submit.
535 5.7.3 Error de autenticación	En la fase AUTH de la conversación del protocolo SMTP, las credenciales proporcionadas eran incorrectas o el usuario autenticado no tiene permiso para enviar a este servidor.
550 5.7.1 El cliente no tiene permiso para enviar a este servidor	El remitente especificado en el campo MAIL FROM de la conversación del protocolo SMTP se autenticó, pero no tiene permiso para enviar a este servidor.
550 5.7.1 El cliente no tiene permiso para enviar como este remitente	El remitente especificado en el campo MAIL FROM de la conversación del protocolo SMTP es una dirección de un dominio con autoridad. Sin embargo, la sesión no tiene el permiso ms-Exch-SMTP-Accept-Authoritative-Domain-Sender. Esto puede suceder si un mensaje se envió desde Internet a un servidor Transporte perimetral desde una dirección para la que la organización de Exchange tiene autoridad.
550 5.7.1 El cliente no tiene permiso para enviar en nombre de la dirección remitente.	El usuario autenticado no tiene permiso para enviar un mensaje en nombre del remitente especificado en el encabezado del mensaje. Además, la sesión no tiene el permiso ms-Exch-SMTP-Accept-Any-Sender.
550 5.7.1. No se puede retransmitir	El dominio de recepción al que se dirige el mensaje no está en ninguno de los dominios aceptados definidos para esta organización. Además, la sesión no tiene el permiso ms-Exch-SMTP-Accept-Any-Recipient.

Información adicional

Para obtener más información, consulte los siguientes temas (en inglés):