Remoção da permissão Ms-Exch-SMTP-Accept-Any-Sender não funciona

  

Fui questionado por um cliente o porquê a aplicação dele conseguia enviar e-mail se passando por qualquer domínio. Após analisar o Receive Connector utilizado pela aplicação, validei que o problema era a permissão Ms-Exch-SMTP-Accept-Any-Sender que estava sendo aplicada. Essa permissão permite o uso do Receive Connector como relay utilizando qualquer domínio, por mais que o domínio não esteja no Accepted Domains do Exchange.

O cliente então me solicitou a remoção dessa permissão, de modo que a aplicação conseguisse enviar apenas utilizando um domínio SMTP autorizado pelo Exchange.

A resolução era fácil e rápida, bastava remover a permissão com o seguinte comando:

Get-ReceiveConnector "Nome do Receive Conector" | Remove-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Sender"

O problema foi que mesmo após a remoção, o Exchange ainda assim continuava a aceitar qualquer domínio como MAIL FROM.

Troubleshooting:

Cheguei a fazer diversos testes de telnet e verificar inúmeras vezes se a permissão havia sido de fato removida com o seguinte comando:

Get-ReceiveConnector "Nome do Conector" | Get-ADPermission -user "NT AUTHORITY\Anonymous Logon" | where {$_.ExtendedRights -like "ms-Exch-SMTP-Accept-Any-Sender"} | fl

O resultado não me retornava nada, o que é o correto quando não existe a permissão. Posteriormente habilitei as logs verbose no Receive Connector, mas não pude validar nada.

Por último, consegui encontrar onde possivelmente seria o problema, na transport role do Receive Connector.

Causa:

Ao criar um Receive Connector, nós temos a possibilidade de vincula-lo ao Frontend Transport Service ou Transport Service (Hub Transport). Por boa pratica, até mesmo como instruído nas documentações da Microsoft, nos sempre criamos conectores pra relay no Frontend Transport.

Ao que parece, a remoção da permissão de ms-Exch-SMTP-Accept-Any-Sender só tem efeito se o Receive Connector foi criado no Transport Service. Eu não pude descobrir se isso é algo do design do produto, ou um bug.

O problema dessa “limitação” do produto é que como a porta 25 já é vinculada ao Frontend Transport, nos não conseguimos vincular também ao Transport Service. Uma porta pode ser vinculada a apenas um serviço. Por conta disso, deve se usar uma outra porta além da 25.

Resolução:

Como workaround eu criei o Receive Connector da seguinte maneira:

• Receive Connector que escute na porta 2525 (pode ser qualquer outra).

New-ReceiveConnector -Name <ConnectorName> -TransportRole HubTransport -Custom -Bindings <LocalIPAddresses>:2525 -RemoteIpRanges <RemoteIPAddresses>

• Conceder permissão anônima ao novo conector:

Set-ReceiveConnector “Relay” -PermissionGroups AnonymousUsers

Get-ReceiveConnector "Relay" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient"

• Bloquear envio utilizando qualquer domínio:

Get-ReceiveConnector "Relay" | Remove-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Sender"

Desse modo, basta que se configure a aplicação para usar a porta selecionada. Assim o bloqueio será feito em modo que a aplicação consiga fazer o MAIL FROM usando apenas domínios aceitos pelo Exchange.