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

Existem situações em que o usuário tenta enviar mensagens utilizando um template de IRM pelo Outlook/OWA e ele acaba recebendo a seguinte mensagem de erro (NDR):

user1@domain.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. ##

O código X.7.1 é descrito como “Delivery not authorized” e o código 5.X.X. como “permanent failure”. As causas que podem trazer este tipo de problema podem ser:

1. O sender não possui permissão para enviar emails;

2. Existe um SMTP server no meio da comunicação que não permite o relay de mensagens;

3. Existe uma restrição de mailbox habilitada para o sender. Um exemplo é se o usuário não possui permissão para enviar à uma lista de distribuição específica.

Voltando para o NDR, existe uma informação no log que pode nos dar uma idéia melhor sobre o problema:

Microsoft Exchange Transport cannot RMS decrypt the message.

Em um servidor Exchange 2010, quando habilitamos as funções do IRM, a opção de “pre-licensing” é habilitada por default. Desta maneira, o Exchange irá anexar na mensagem uma pre-license pelo PreLicense Agent e isto fará com que o cliente não consulte o servidor de AD RMS para obter uma licença – baseada em XrML (Extensive Rights Markup Language) – que possui as informações para os usuários com permissão para acessar o conteúdo.

Para o Exchange HUB Transport, é importante efetuar o decrypt das mensagens por premissas de segurança por exemplo questões de auditoria/aplicar transport rules ou a função de journaling. As mensagens devem ser descriptografadas para que o Exchange reveja o conteúdo e caso alguma regra de transporte se aplique, seja aplicada.

A tabela abaixo demonstra os Agentes instalados no HUB Transport pelo IRM:

image

Como o Exchange 2010 Hub Transport utiliza a Federation Mailbox para efetuar o decrypt das mensagens, é essencial que esta mailbox seja adicionada no grupo “SuperUsers”. Para maiores informações deste processo, conulte o artigo : Add the Federation Mailbox to the AD RMS Super Users Group.

Para validar que as configurações de Decrypt estão ativadas, podemos validar com o cmdlet: Get-IRMConfiguration | fl *transport*

image

Se o parâmetro “TransportDecryptionSetting” está configurado como “Mandatory” (que é o valor default quando temos um IRM configurado) a mensagem não pode ser descriptografada e recebemos o NDR.

Caso os requerimentos para o IRM estejam corretamente configurados (Understanding Information Rights Management / AD RMS Microsoft Exchange Server 2010 Integration Guide ), então o NDR pode aparecer pois as entradas em cache do RAC (Rights Account Certificate) não puderam ser utilizadas pelo Network Service Account do Exchange 2010 Transport Server.

Basicamente, o CCR é um dos vários certificados que estão sendo emitidos pelos clientes e servidores durante todo o processo de criptografia de mensagens e parte desta informação está sendo armazenada em cache no Hub Server. O artigo Licenses and Certificates, and how AD RMS protects and consumes documents demonstra o processo detalhado de criação do RAC.

Para o Windows, o serviço de criptografia é gerenciado pelo Network Service Account e se este serviço não consegue interagir com as entradas em cache do RAC, o NDR 550-5.7.1 pode aparecer.

Para resolver este problema, você deve adicionar a permissão de Modify para o “Network Service Account” no caminho <Drive>:\programdata\Microsoft\DRM\Server\ no seu Exchange 2010 Hub Transport.

NOTA: O diretório PROGRAMDATA é um diretório oculto.

image

image