Remove the Ms-Exch-SMTP-Accept-Any-Sender permission doesn’t work

  

I was asked by a costumer why his application was able to send as any domain. After check the Receive Connector used by the application, I validated that the problem was the Ms-Exch-SMTP-Accept-Any-Sender permission being applied. This permission allows the use of the Receive Connector as relay for any domain, even if the domain is not in the Exchange Accepted Domains.

The costumer then asked me to remove this permission in order to restrict the relay to be used only an Exchange-authorized SMTP domain.

The resolution was easy and fast – in theory – just remove the permission with the following command:

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

But even after removal, Exchange still continued accepting any domain as MAIL FROM.

Troubleshooting:

I did several telnet tests and checked many times whether the permission had actually been removed with the following command:

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

The result did not return anything to me, which is correct when there is no permission. Then I enabled the verbose logs in the Receive Connector, but I could not validate anything strange.

Finally, I was able to find out where possibly the problem would be in the transport role of the Receive Connector.

Cause:

When creating a Receive Connector, we have the possibility to link it to the Frontend Transport Service or Transport Service (Hub Transport). As a best practice instructed by Microsoft documentation, we always create relay connectors as Frontend Transport Role.

The removal of the permission ms-Exch-SMTP-Accept-Any-Sender seems to take effect only if the Receive Connector was created as Transport Service Role. I could not figure out if this is something from the product design, or a bug.

The problem with this product “limitation” is that because port 25 is already bound to Frontend Transport role, so we cannot bind it to the Transport Service as well. A port can be bound in only one service. Due to this behavior, other door that is not the 25 must be used.

Resolution:

As workaround I created the Receive Connector as follows:

1- Receive Connector that listens on port 2525 (could be any other).

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

2- Grant anonymous permission to the new connector:

Set-ReceiveConnector “Relay” -PermissionGroups AnonymousUsers

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

3- Deny relay to non-accepted domains:

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

Thus, it is enough to configure the application to use the selected port. The blocking will be done so that the application can do MAIL FROM using only accepted domains by Exchange Server.