NDR: 550-5.7.1 Delivery not authorized, message refused. 550-5.7.1 con Exchange Server 2010 e Information Rights Managements

Por: Pedro Gonzalez Martinez and Caio Ribeiro Cesar Technical Reviewer: Patricia Cifuentes

Exsten algunas situaciones en las que al tartar de enviar un mensaje utilizando una plantilla de IRM a traves de Outlook y/o OWA que puede causar un NDR para todos los destinatarios con la siguente descripcion:

user1@dominio.corp #550-5.7.1 Delivery not authorized, message refused. 550-5.7.1 Microsoft Exchange Transport cannot RMS decrypt the message. 550 5.7.1 Please contact your system administrator for more information. ##

El código X.7.1 esta descrito como una entrega no autorizada y el 5.X.X es definido como una falla permanente. Las posibles causas por la que estoy puede ocurrir son:

1. El remitente no tiene privilegios para enviar correos.

2. Existe un reenvio (relay) a través de un servidor que no permite el reenvío de correos.

3. El remitente tiene un buzón con una restricción a este nivel habilitada. Por ejemplo; el usuario no está enlistado en los miembros de los usuarios permitidos para enviar correos a una lista de distribución.

Sin embargo, en la descripción del mensaje NDR hay una pieza de información importante que nos da una idea acerca del problema:

Microsoft Exchange Transport cannot RMS decrypt the message.

Vamos a entrar en más detalles con base en este mensaje y su relación con el IRM.

En Exchange 2010 cuando se habilita las funcionalidades de IRM, el pre-licenciamiento está activado de manera predeterminada, esto significa que Exchange adjuntara una pre-licencia en el mensaje por medio del Prelicense Agent y esto causara que el cliente no tenga que consultar cada ves al servidor de AD-RMS para la obtención de una licencia, que en otras palabras es un certificado XrML (Extensive Rights markup language) que contiene la información de los usuario permitidos para tener acceso al contenido. Igualmente las plantillas creadas por el AD-RMS esta generadas con una base XrML.

Ahora bien, para Exchange es importante tener la capacidad de poder descifrar (decrypt) estos mensajes, por un lado; por razones de seguridad interna como por ejemplo auditorias o investigaciones y por otro lado; esta capacidad es importante ya que al tener el mensaje descifrado será posible aplicar reglas de transporte así como archivado o “journaling”.

Es decir, el mensaje al ser descifrado, se revisa el contenido y en caso de que alguna regla/restricción concuerde, está podrá ser aplicada.

La siguiente tabla describe el agente de transporte (Transport Agent) aplicado por el IRM en el servidor con el rol de Hub Transport:

Como punto adicional, hay que recordar que debido a que Exchange 2010 con el rol de Hub Transport, hace uso del buzon “Federation mailbox” para decifrar el mensaje, es importante asegurarse que es miembro del grupo “SuperUsers”. Si no estamos seguros de que los permisos estén bien aplicados, por favor consultar el siguiente artículo: Add the Federation Mailbox to the AD RMS Super Users Group

Igualmente para cerciorarnos de que el Exchange Transport está configurado para decifrar los mensajes podemos confirmarlo con el siguiente cmdlet: Get-IRMConfiguration | fl *transport* y lo que observaremos es lo siguiente:

Si el parametro “TransportDecryptionSetting” está configurado como “Mandatory” (el cual es el valor predeterminado cuando el IRM está configurado) entonces el mensaje cuando no pueda ser descifrado será regresado con el NDR: #550-5.7.1 Delivery not authorized, message refused. 550-5.7.1 Microsoft Exchange Transport cannot RMS decrypt the message. 550 5.7.1 Please contact your system administrator for more information. ##

Asumiendo que los requerimientos descritos en la sección “IRM Requirements” del documento: Understanding Information Rights Management y la configuración descrita en el articulo: AD RMS Microsoft Exchange Server 2010 Integration Guide se han cumplido. Es posible que el NDR se este generando porque el RAC (Rights Account Certificate) localizado en el cache, no pueda ser “manejado” completamente por la cuenta del Network Service Account en el servidor de transporte de Exchange 2010.

Pero, ¿Qué es el RAC?

Basicamente el RAC, es uno de los tantos certificados que son usados por los clientes y servidores a lo largo del proceso de cifrado de los mensajes, y parte de esta información esta almacenada temporalmente (cached) en el servidor con el rol de HUB Transport para Exchange 2010, como fue comentado anteriormente, para disminuir las consultas al servidor de AD-RMS.

Existe un excelente artículo que describe el proceso de manera detallada y como el RAC es utilizado y la interacción en el proceso del cifrado del mensaje: Licenses and Certificates, and how AD RMS protects and consumes documents

Ahora bien, el servicio de Cryptographic Services para Windows esta manejado por la cuenta del Network Service y por lo tanto, si esta cuenta no puede interactuar correctamente con los registros del RAC, el mensaje de NDR se genera.

Finalmente, dicho todo lo anterior, la solución que podemos encontrar para este problema, cuando todo está correctamente configurado, es asignar explícitamente los permisos de “Modify” para la cuenta de

“Network Service Account” en la ruta: <Drive>:\programdata\Microsoft\DRM\Server\ en el servidor Exchange 2010 con el rol de Hub Transport Server.

NOTA: Tomar en cuenta que la carpeta PROGRAMDATA esta oculta.

** Por fines prácticos se han dejado las imágenes, tablas y tecnicismos en inglés.