Hi guys!

We got Exchange 2013 in the Internet facing ADsite.

If an externat user use telnet to port 25, we need to prevent that a mail from our own domain can be accepted.

In Exchange 2010, we prevent this removing the ExtendedRights ms-exch-smtp-accept-authoritative-domain-sender on ther Internet connector.

Now in Exchange 2013, we remove this ExtendedRights in the FrontEnd Internet Connector, but the mail is accepted anyway.

Any idea if this behavior change in Exchange 2013?

Regards,

Esteban

What are you using for anti-spam? Thats where this should be configured.

Hi ,

Because of you and Andy i came to know about the use of permission (ms-exch-smtp-accept-authoritative-domain-sender) in exchange . 

Why don't we prefer the spf records ? i hope that would also avoid spoofing.

Regards

S.Nithyanandham

The anti-spam is the Exchange 2013 built in feature.

SPF is setup on the DNS and works great... no other company gets mails from others servers that my own MX, this is not the problema.

If I run Test-SenderID in my Exchange, the response is "none", but if I run the test in other company, it response "pass".

Esteban

The anti-spam is the Exchange 2013 built in feature.

SPF is setup on the DNS and works great... no other company gets mails from others servers that my own MX, this is not the problema.

If I run Test-SenderID in my Exchange, the response is "none", but if I run the test in other company, it response "pass".

E

"Sender filtering functionality filters all messages that come through all Receive connectors on that computer."... so It will block real emails that come from our users.

"Sender filtering functionality filters all messages that come through all Receive connectors on that computer."... so It will block real emails that come from our users.

not all antispam has a spoofing component (Trend Micro WFBS for example).

In exchange 2007/ and 2010 you would just run this command:

Get-ReceiveConnector "public internet connector" | Get-ADPermission -user "NT AUTHORITY\Anonymous Logon" | where {$_.ExtendedRights -like "ms-exch-smtp-accept-authoritative-domain-sender"} | Remove-ADPermission

or specifically deny it:

Get-ReceiveConnector "public internet connector" | add-ADPermission -user "NT AUTHORITY\Anonymous Logon" -Deny -ExtendedRights "ms-exch-smtp-accept-authoritative-domain-sender"

However like Esteban above, this no longer works in Exchange 2013.

Every solution on the web is the same and is also suggested by posters above (set up SPF records and use SenderID: "Set-SenderIdConfig -SpoofedDomainAction reject" and "Set-SenderIdConfig -InternalMailEnabled $True")

However this ends up applying to ALL connectors! So when you have a LAN connector set up as an open relay internally with say a printer/scanner relaying through it anonymously with an address like scanner@mydomain.com, it gets rejected by the LAN connector because the printer IP is not in the SPF record.

Is there any way to make spoofing of own domain apply to only the internet facing connector like the old 2007/2010 method of removing ms-exch-smtp-accept-authoritative-domain-sender for anon users? Or perhaps make it so the "Set-SenderIdConfig -SpoofedDomainAction reject" and "Set-SenderIdConfig -InternalMailEnabled $True" commands only apply to the internet facing connector?

• Edited by technet usr Saturday, October 11, 2014 11:43 AM

not all antispam has a spoofing component (Trend Micro WFBS for example).

In exchange 2007/ and 2010 you would just run this command:

Get-ReceiveConnector "public internet connector" | Get-ADPermission -user "NT AUTHORITY\Anonymous Logon" | where {$_.ExtendedRights -like "ms-exch-smtp-accept-authoritative-domain-sender"} | Remove-ADPermission

or specifically deny it:

Get-ReceiveConnector "public internet connector" | add-ADPermission -user "NT AUTHORITY\Anonymous Logon" -Deny -ExtendedRights "ms-exch-smtp-accept-authoritative-domain-sender"

However like Esteban above, this no longer works in Exchange 2013.

Every solution on the web is the same and is also suggested by posters above (set up SPF records and use SenderID: "Set-SenderIdConfig -SpoofedDomainAction reject" and "Set-SenderIdConfig -InternalMailEnabled $True")

However this ends up applying to ALL connectors! So when you have a LAN connector set up as an open relay internally with say a printer/scanner relaying through it anonymously with an address like scanner@mydomain.com, it gets rejected by the LAN connector because the printer IP is not in the SPF record.

Is there any way to make spoofing of own domain apply to only the internet facing connector like the old 2007/2010 method of removing ms-exch-smtp-accept-authoritative-domain-sender for anon users? Or perhaps make it so the "Set-SenderIdConfig -SpoofedDomainAction reject" and "Set-SenderIdConfig -InternalMailEnabled $True" commands only apply to the internet facing connector?

• Edited by technet usr Saturday, October 11, 2014 11:43 AM

not all antispam has a spoofing component (Trend Micro WFBS for example).

In exchange 2007/ and 2010 you would just run this command:

Get-ReceiveConnector "public internet connector" | Get-ADPermission -user "NT AUTHORITY\Anonymous Logon" | where {$_.ExtendedRights -like "ms-exch-smtp-accept-authoritative-domain-sender"} | Remove-ADPermission

or specifically deny it:

Get-ReceiveConnector "public internet connector" | add-ADPermission -user "NT AUTHORITY\Anonymous Logon" -Deny -ExtendedRights "ms-exch-smtp-accept-authoritative-domain-sender"

However like Esteban above, this no longer works in Exchange 2013.

Every solution on the web is the same and is also suggested by posters above (set up SPF records and use SenderID: "Set-SenderIdConfig -SpoofedDomainAction reject" and "Set-SenderIdConfig -InternalMailEnabled $True")

However this ends up applying to ALL connectors! So when you have a LAN connector set up as an open relay internally with say a printer/scanner relaying through it anonymously with an address like scanner@mydomain.com, it gets rejected by the LAN connector because the printer IP is not in the SPF record.

Is there any way to make spoofing of own domain apply to only the internet facing connector like the old 2007/2010 method of removing ms-exch-smtp-accept-authoritative-domain-sender for anon users? Or perhaps make it so the "Set-SenderIdConfig -SpoofedDomainAction reject" and "Set-SenderIdConfig -InternalMailEnabled $True" commands only apply to the internet facing connector?

• Edited by technet usr Saturday, October 11, 2014 11:43 AM

not all antispam has a spoofing component (Trend Micro WFBS for example).

In exchange 2007/ and 2010 you would just run this command:

Get-ReceiveConnector "public internet connector" | Get-ADPermission -user "NT AUTHORITY\Anonymous Logon" | where {$_.ExtendedRights -like "ms-exch-smtp-accept-authoritative-domain-sender"} | Remove-ADPermission

or specifically deny it:

Get-ReceiveConnector "public internet connector" | add-ADPermission -user "NT AUTHORITY\Anonymous Logon" -Deny -ExtendedRights "ms-exch-smtp-accept-authoritative-domain-sender"

However like Esteban above, this no longer works in Exchange 2013.

Every solution on the web is the same and is also suggested by posters above (set up SPF records and use SenderID: "Set-SenderIdConfig -SpoofedDomainAction reject" and "Set-SenderIdConfig -InternalMailEnabled $True")

However this ends up applying to ALL connectors! So when you have a LAN connector set up as an open relay internally with say a printer/scanner relaying through it anonymously with an address like scanner@mydomain.com, it gets rejected by the LAN connector because the printer IP is not in the SPF record.

Is there any way to make spoofing of own domain apply to only the internet facing connector like the old 2007/2010 method of removing ms-exch-smtp-accept-authoritative-domain-sender for anon users? Or perhaps make it so the "Set-SenderIdConfig -SpoofedDomainAction reject" and "Set-SenderIdConfig -InternalMailEnabled $True" commands only apply to the internet facing connector?

• Edited by technet usr Saturday, October 11, 2014 11:43 AM

There is a bug in Exchange 2013 that the "ms-exch-smtp-accept-authoritative-domain-sender" parameter is a completely ignored permission on the receive connectors.

the workaround solution is as follows:

Block your own domain:

Set-SenderFilterConfig -BlockedDomains mydomain.com

Set-SenderFilterConfig -InternalMailEnabled $true

be sure your internet receive connector has the ms-Exch-SMTP-Accept-Any-Sender removed for anon users as otherwise it will bypass the SenderFilter settings:

Get-ReceiveConnector "name of the internet receive connector" | Get-ADPermission -user "NT AUTHORITY\Anonymous Logon" | where {$_.ExtendedRights -like "ms-Exch-SMTP-Accept-Any-Sender"} | Remove-ADPermission

Now to let your open relay LAN connector spoof, add the ms-Exch-SMTP-Accept-Any-Sender parameter to ensure it bypass the SenderFilter settings for anon users:

Get-ReceiveConnector "name of your LAN Open Relay connector" | add-ADPermission -user "NT AUTHORITY\Anonymous Logon" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Sender"

• Edited by technet usr Saturday, October 11, 2014 6:58 PM

There is a bug in Exchange 2013 that the "ms-exch-smtp-accept-authoritative-domain-sender" parameter is a completely ignored permission on the receive connectors.

the workaround solution is as follows:

Block your own domain:

Set-SenderFilterConfig -BlockedDomains mydomain.com

Set-SenderFilterConfig -InternalMailEnabled $true

be sure your internet receive connector has the ms-Exch-SMTP-Accept-Any-Sender removed for anon users as otherwise it will bypass the SenderFilter settings:

Get-ReceiveConnector "name of the internet receive connector" | Get-ADPermission -user "NT AUTHORITY\Anonymous Logon" | where {$_.ExtendedRights -like "ms-Exch-SMTP-Accept-Any-Sender"} | Remove-ADPermission

Now to let your open relay LAN connector spoof, add the ms-Exch-SMTP-Accept-Any-Sender parameter to ensure it bypass the SenderFilter settings for anon users:

Get-ReceiveConnector "name of your LAN Open Relay connector" | add-ADPermission -user "NT AUTHORITY\Anonymous Logon" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Sender"

• Edited by technet usr Saturday, October 11, 2014 6:58 PM

There is a bug in Exchange 2013 that the "ms-exch-smtp-accept-authoritative-domain-sender" parameter is a completely ignored permission on the receive connectors.

the workaround solution is as follows:

Block your own domain:

Set-SenderFilterConfig -BlockedDomains mydomain.com

Set-SenderFilterConfig -InternalMailEnabled $true

be sure your internet receive connector has the ms-Exch-SMTP-Accept-Any-Sender removed for anon users as otherwise it will bypass the SenderFilter settings:

Get-ReceiveConnector "name of the internet receive connector" | Get-ADPermission -user "NT AUTHORITY\Anonymous Logon" | where {$_.ExtendedRights -like "ms-Exch-SMTP-Accept-Any-Sender"} | Remove-ADPermission

Now to let your open relay LAN connector spoof, add the ms-Exch-SMTP-Accept-Any-Sender parameter to ensure it bypass the SenderFilter settings for anon users:

Get-ReceiveConnector "name of your LAN Open Relay connector" | add-ADPermission -user "NT AUTHORITY\Anonymous Logon" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Sender"

• Edited by technet usr Saturday, October 11, 2014 6:58 PM

There is a bug in Exchange 2013 that the "ms-exch-smtp-accept-authoritative-domain-sender" parameter is a completely ignored permission on the receive connectors.

the workaround solution is as follows:

Block your own domain:

Set-SenderFilterConfig -BlockedDomains mydomain.com

Set-SenderFilterConfig -InternalMailEnabled $true

be sure your internet receive connector has the ms-Exch-SMTP-Accept-Any-Sender removed for anon users as otherwise it will bypass the SenderFilter settings:

Get-ReceiveConnector "name of the internet receive connector" | Get-ADPermission -user "NT AUTHORITY\Anonymous Logon" | where {$_.ExtendedRights -like "ms-Exch-SMTP-Accept-Any-Sender"} | Remove-ADPermission

Now to let your open relay LAN connector spoof, add the ms-Exch-SMTP-Accept-Any-Sender parameter to ensure it bypass the SenderFilter settings for anon users:

Get-ReceiveConnector "name of your LAN Open Relay connector" | add-ADPermission -user "NT AUTHORITY\Anonymous Logon" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Sender"

• Edited by technet usr Saturday, October 11, 2014 6:58 PM

not all antispam has a spoofing component (Trend Micro WFBS for example).

Hi Andy,

Thanks for your feedback. There are hundreds of posts online looking for a method of preventing spoofing in Exchange - https://www.google.ie/search?q=exchange+spoofing

While there is a well known popular fix for Exchange 2007/2010, there has never been a publicly posted solution for Exchange 2013.

Hopefully the solution I spent a while working on today and shared above with the community will help out some people in the future.

Many thanks.

Hi TechNet Usr... I will test this solution.

Using Andy solution, will blocks Printers/Scanners/Apps/Etc that use @mydomain.com and are real emails... just not authenticated.

Esteban

Hi TechNet Usr... I will test this solution.

Using Andy solution, will blocks Printers/Scanners/Apps/Etc that use @mydomain.com and are real emails... just not authenticated.

E

Andy thanks for the recommendation!

Perhaps you not able to understand that in the third world this is not an option.

Anyway... I'm not searching for any fancy feature... just be able to stop mails from my own domain from the outside.

Hello all

Maybe someone from Microsoft could explain, why Exchange 2013 is not using permission ms-exch-smtp-accept-authoritative-domain-sender to verify sender domain?

Any update on this? I am having the exact same problem as the OP in this thread. Two companies exchange 2013 migrations went well, EXCEPT they now receive spoofed spam email from their own domain occasionally. One company has a 3rd party email filter that blocks it (Kaspersky), the other does not and cannot afford to buy one. Under Exchange 2010/2007 we ran:

Get-ReceiveConnector Default <name> | Get-ADPermission -user NT AUTHORITY\Anonymous Logon | where {$_.ExtendedRights -like ms-exch-smtp-accept-authoritative-domain-sender} | Remove-ADPermission

And all was well... we had a separate receive connector for internal copiers/scanners. In Exchange 2013 the above command no longer works.

• Edited by trafsta1 19 hours 17 minutes ago

Hi, the solution is posted above:

--------

There is a bug in Exchange 2013 that the "ms-exch-smtp-accept-authoritative-domain-sender" parameter is a completely ignored permission on the receive connectors.

the workaround solution is as follows:

Block your own domain:

Set-SenderFilterConfig -BlockedDomains mydomain.com

Set-SenderFilterConfig -InternalMailEnabled $true

be sure your internet receive connector has the ms-Exch-SMTP-Accept-Any-Sender removed for anon users as otherwise it will bypass the SenderFilter settings:

Get-ReceiveConnector "name of the internet receive connector" | Get-ADPermission -user "NT AUTHORITY\Anonymous Logon" | where {$_.ExtendedRights -like "ms-Exch-SMTP-Accept-Any-Sender"} | Remove-ADPermission

Now to let your open relay LAN connector spoof, add the ms-Exch-SMTP-Accept-Any-Sender parameter to ensure it bypass the SenderFilter settings for anon users:

Get-ReceiveConnector "name of your LAN Open Relay connector" | add-ADPermission -user "NT AUTHORITY\Anonymous Logon" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Sender"

-----------

The other my solution is to configure transport rule:

In the effect no authorized messages from local domain will be rejected, but it will be bounced to sender after submit message.

Any update on this? I am having the exact same problem as the OP in this thread. Two companies exchange 2013 migrations went well, EXCEPT they now receive spoofed spam email from their own domain occasionally. One company has a 3rd party email filter that blocks it (Kaspersky), the other does not and cannot afford to buy one. Under Exchange 2010/2007 we ran:

Get-ReceiveConnector Default <name> | Get-ADPermission -user NT AUTHORITY\Anonymous Logon | where {$_.ExtendedRights -like ms-exch-smtp-accept-authoritative-domain-sender} | Remove-ADPermission

And all was well... we had a separate receive connector for internal copiers/scanners. In Exchange 2013 the above command no longer works.

• Edited by trafsta1 Saturday, April 11, 2015 12:07 PM

Any update on this? I am having the exact same problem as the OP in this thread. Two companies exchange 2013 migrations went well, EXCEPT they now receive spoofed spam email from their own domain occasionally. One company has a 3rd party email filter that blocks it (Kaspersky), the other does not and cannot afford to buy one. Under Exchange 2010/2007 we ran:

Get-ReceiveConnector Default <name> | Get-ADPermission -user NT AUTHORITY\Anonymous Logon | where {$_.ExtendedRights -like ms-exch-smtp-accept-authoritative-domain-sender} | Remove-ADPermission

And all was well... we had a separate receive connector for internal copiers/scanners. In Exchange 2013 the above command no longer works.

• Edited by trafsta1 Saturday, April 11, 2015 12:07 PM

Any update on this? I am having the exact same problem as the OP in this thread. Two companies exchange 2013 migrations went well, EXCEPT they now receive spoofed spam email from their own domain occasionally. One company has a 3rd party email filter that blocks it (Kaspersky), the other does not and cannot afford to buy one. Under Exchange 2010/2007 we ran:

Get-ReceiveConnector Default <name> | Get-ADPermission -user NT AUTHORITY\Anonymous Logon | where {$_.ExtendedRights -like ms-exch-smtp-accept-authoritative-domain-sender} | Remove-ADPermission

And all was well... we had a separate receive connector for internal copiers/scanners. In Exchange 2013 the above command no longer works.

• Edited by trafsta1 Saturday, April 11, 2015 12:07 PM

I ran the following commands:

Set-SenderFilterConfig -BlockedDomains domain1.com, domain2.com

Set-SenderFilterConfig -InternalMailEnabled $true

Get-ReceiveConnector "Default Frontend <name>" | Get-ADPermission -user "NT AUTHORITY\Anonymous Logon" | where {$_.ExtendedRights -like "ms-Exch-SMTP-Accept-Any-Sender"} | Remove-ADPermission

and it removed the permissions above just fine.

I then ran:

Get-ReceiveConnector "Local Network Relaying" | add-ADPermission -user "NT AUTHORITY\Anonymous Logon" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Sender"

and it said:

WARNING: The appropriate access control entry is already present on the object "CN=Local Network Relaying,CN=SMTP Receive Connectors,CN=Protocols,CN=<server>,CN=Servers,CN=Exchange Administrative Group (...),CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=local" for account "NT AUTHORITY\ANONYMOUS LOGON".

Now our users cannot scan from copiers and appliances on the same subnet cannot send via the Local Network Relaying connector, it gives this error:

2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,0,10.20.0.99:25,10.20.0.34:41338,+,,
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,1,10.20.0.99:25,10.20.0.34:41338,*,SMTPSubmit SMTPAcceptAnyRecipient SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender AcceptRoutingHeaders,Set Session Permissions
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,2,10.20.0.99:25,10.20.0.34:41338,>,"220 server Microsoft ESMTP MAIL Service ready at Mon, 20 Apr 2015 10:33:13 -0400",
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,3,10.20.0.99:25,10.20.0.34:41338,<,HELO sslvpn,
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,4,10.20.0.99:25,10.20.0.34:41338,*,SMTPSubmit SMTPAcceptAnyRecipient SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender AcceptRoutingHeaders,Set Session Permissions
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,5,10.20.0.99:25,10.20.0.34:41338,>,250 server Hello [10.20.0.34],
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,6,10.20.0.99:25,10.20.0.34:41338,<,MAIL FROM: <appliance@domain.com>,
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,7,10.20.0.99:25,10.20.0.34:41338,*,SMTPSubmit SMTPAcceptAnyRecipient SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender AcceptRoutingHeaders,Set Session Permissions
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,8,10.20.0.99:25,10.20.0.34:41338,*,08D249192435538B;2015-04-20T14:33:13.840Z;1,receiving message
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,9,10.20.0.99:25,10.20.0.34:41338,>,250 2.1.0 Sender OK,
2015-04-20T14:33:13.856Z,SERVER\Local Network Relaying,08D249192435538B,10,10.20.0.99:25,10.20.0.34:41338,<,RCPT TO: <someone@domain.com>,
2015-04-20T14:33:13.856Z,SERVER\Local Network Relaying,08D249192435538B,11,10.20.0.99:25,10.20.0.34:41338,>,250 2.1.5 Recipient OK,
2015-04-20T14:33:13.856Z,SERVER\Local Network Relaying,08D249192435538B,12,10.20.0.99:25,10.20.0.34:41338,<,DATA,
2015-04-20T14:33:13.856Z,SERVER\Local Network Relaying,08D249192435538B,13,10.20.0.99:25,10.20.0.34:41338,>,354 Start mail input; end with <CRLF>.<CRLF>,
2015-04-20T14:33:13.856Z,SERVER\Local Network Relaying,08D249192435538B,14,10.20.0.99:25,10.20.0.34:41338,*,,Proxy destination(s) obtained from OnProxyInboundMessage event
2015-04-20T14:33:13.871Z,SERVER\Local Network Relaying,08D249192435538B,15,10.20.0.99:25,10.20.0.34:41338,*,Tarpit for '0.00:00:05' due to '554 5.1.0 Sender denied',
2015-04-20T14:33:18.887Z,SERVER\Local Network Relaying,08D249192435538B,16,10.20.0.99:25,10.20.0.34:41338,>,554 5.1.0 Sender denied,
2015-04-20T14:33:18.887Z,SERVER\Local Network Relaying,08D249192435538B,17,10.20.0.99:25,10.20.0.34:41338,-,,Remote(SocketError)

Any ideas as to how I can quickly rectify this? Putting it back the way it was would be fine for me for now, but I cannot figure out how to reverse the "Remove-ADPermission" command above... :(

Edit: I ran these commands to get things back (but still don't know how to add the permission back for the command that did the Remove-ADPermissions)

Set-SenderFilterConfig -BlockedDomains $null

Set-SenderFilterConfig -InternalMailEnabled $false

Either way for now copiers and hardware appliances are able to send emails internally over the "Local Network Relaying" connector so it's good enough for now... will await responses on here before proceeding any further :)

• Edited by trafsta1 16 hours 1 minutes ago

Your connector "Local Network Relaying" should now be an open relay but you are getting access denied.

I would guess your copiers and appliances are not actually using that connector.

Check the network bindings on the "Local Network Relaying" connector to confirm it is listening on your local subnet.

You can also set a different SMTP banner for each connector then telnet in on port 25 and see what banner you get to confirm you are connecting to the correct one.

• Edited by trafsta1 15 hours 53 minutes ago

I will test security changes this tomorrow morning before staff get in. Currently only "Transport Layer Security (TLS)" and "Anonymous users" is selected.

"220 LAN Relay Microsoft ESMTP MAIL Service ready" shows upw ith telnet.

By the way, the issue isn't just with copiers. It's with anything that is trying to relay w/o authentication (copiers, hardware appliances like SonicWall VPN SRA4200's, Ruckus wireless appliances, blat.exe, telnet, etc).

I should also ask, what is the command to reverse what this command does?

Get-ReceiveConnector "Default Frontend <name>" | Get-ADPermission -user "NT AUTHORITY\Anonymous Logon" | where {$_.ExtendedRights -like "ms-Exch-SMTP-Accept-Any-Sender"} | Remove-ADPermission

I ran the following commands:

Set-SenderFilterConfig -BlockedDomains domain1.com, domain2.com

Set-SenderFilterConfig -InternalMailEnabled $true

Get-ReceiveConnector "Default Frontend <name>" | Get-ADPermission -user "NT AUTHORITY\Anonymous Logon" | where {$_.ExtendedRights -like "ms-Exch-SMTP-Accept-Any-Sender"} | Remove-ADPermission

and it removed the permissions above just fine.

I then ran:

Get-ReceiveConnector "Local Network Relaying" | add-ADPermission -user "NT AUTHORITY\Anonymous Logon" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Sender"

and it said:

WARNING: The appropriate access control entry is already present on the object "CN=Local Network Relaying,CN=SMTP Receive Connectors,CN=Protocols,CN=<server>,CN=Servers,CN=Exchange Administrative Group (...),CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=local" for account "NT AUTHORITY\ANONYMOUS LOGON".

Now our users cannot scan from copiers and appliances on the same subnet cannot send via the Local Network Relaying connector, it gives this error:

2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,0,10.20.0.99:25,10.20.0.34:41338,+,,
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,1,10.20.0.99:25,10.20.0.34:41338,*,SMTPSubmit SMTPAcceptAnyRecipient SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender AcceptRoutingHeaders,Set Session Permissions
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,2,10.20.0.99:25,10.20.0.34:41338,>,"220 server Microsoft ESMTP MAIL Service ready at Mon, 20 Apr 2015 10:33:13 -0400",
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,3,10.20.0.99:25,10.20.0.34:41338,<,HELO sslvpn,
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,4,10.20.0.99:25,10.20.0.34:41338,*,SMTPSubmit SMTPAcceptAnyRecipient SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender AcceptRoutingHeaders,Set Session Permissions
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,5,10.20.0.99:25,10.20.0.34:41338,>,250 server Hello [10.20.0.34],
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,6,10.20.0.99:25,10.20.0.34:41338,<,MAIL FROM: <appliance@domain.com>,
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,7,10.20.0.99:25,10.20.0.34:41338,*,SMTPSubmit SMTPAcceptAnyRecipient SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender AcceptRoutingHeaders,Set Session Permissions
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,8,10.20.0.99:25,10.20.0.34:41338,*,08D249192435538B;2015-04-20T14:33:13.840Z;1,receiving message
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,9,10.20.0.99:25,10.20.0.34:41338,>,250 2.1.0 Sender OK,
2015-04-20T14:33:13.856Z,SERVER\Local Network Relaying,08D249192435538B,10,10.20.0.99:25,10.20.0.34:41338,<,RCPT TO: <someone@domain.com>,
2015-04-20T14:33:13.856Z,SERVER\Local Network Relaying,08D249192435538B,11,10.20.0.99:25,10.20.0.34:41338,>,250 2.1.5 Recipient OK,
2015-04-20T14:33:13.856Z,SERVER\Local Network Relaying,08D249192435538B,12,10.20.0.99:25,10.20.0.34:41338,<,DATA,
2015-04-20T14:33:13.856Z,SERVER\Local Network Relaying,08D249192435538B,13,10.20.0.99:25,10.20.0.34:41338,>,354 Start mail input; end with <CRLF>.<CRLF>,
2015-04-20T14:33:13.856Z,SERVER\Local Network Relaying,08D249192435538B,14,10.20.0.99:25,10.20.0.34:41338,*,,Proxy destination(s) obtained from OnProxyInboundMessage event
2015-04-20T14:33:13.871Z,SERVER\Local Network Relaying,08D249192435538B,15,10.20.0.99:25,10.20.0.34:41338,*,Tarpit for '0.00:00:05' due to '554 5.1.0 Sender denied',
2015-04-20T14:33:18.887Z,SERVER\Local Network Relaying,08D249192435538B,16,10.20.0.99:25,10.20.0.34:41338,>,554 5.1.0 Sender denied,
2015-04-20T14:33:18.887Z,SERVER\Local Network Relaying,08D249192435538B,17,10.20.0.99:25,10.20.0.34:41338,-,,Remote(SocketError)

Any ideas as to how I can quickly rectify this? Putting it back the way it was would be fine for me for now, but I cannot figure out how to reverse the "Remove-ADPermission" command above... :(

Edit: I ran these commands to get things back (but still don't know how to add the permission back for the command that did the Remove-ADPermissions)

Set-SenderFilterConfig -BlockedDomains $null

Set-SenderFilterConfig -InternalMailEnabled $false

Either way for now copiers and hardware appliances are able to send emails internally over the "Local Network Relaying" connector so it's good enough for now... will await responses on here before proceeding any further :)

• Edited by trafsta1 Monday, April 20, 2015 3:23 PM

• Edited by trafsta1 Monday, April 20, 2015 3:32 PM