none
Exchange Server 2013 and ms-Exch-SMTP-Accept-Authoritative-Domain-Sender RRS feed

  • Question

  • Hello, Team!

    I think I’ve found a serious issue in last CU releases. This is the case:

    1 Multirole server Exchange 2013 SP1 (and older) , one creceive connector from internet to this server, no edge, nothing.

    I care about preventing spoofing my company’s email addresses, and remove remove the ms-Exch-SMTP-Accept-Authoritative-Domain-Sender transport permission from anonymous senders.

    To do this, we usually simple run powershell command

    Remove-ADPermission <ReceiveConnector Name> –user “NT AUTHORITY\Anonymous Logon” –ExtendedRights ms-Exch-SMTP-Accept-Authoritative-Domain-Sender

    This command works on Exchange SP1, the client (telnet session, f.e.) which try spoof address of company will be refused. (see screenshot below)

    But in Exchange 2013 CU5, CU6 and even CU7 release this revoke permissions DOESN’T WORKS without any errors, softly. I've try Powershell and ADSI but unsuccessfully.

    Then we take off permission on connector above, we keep 3 default permissions:

    Accept-any-sender

    Accept-Routing-Headers

    Submit-Message to Server

    It is wonderful works only on server SP1, but not on servers with older versions, which have right settings.

    The saddest thing is I have information about Office 365 this behavior reproduced too. And I also think what in your lab you could take 15 minutes and play this simply thing....

    I found only that information on connector side is diffenent on SP1 and CU5,6,7.

    This is normal connection on SP1, when somebody try spoofed address. We can see a 250 AUTH Response on server side, and server refuse fake connection, all right.

    And on CU5 and newest versions we doesnt see this code. Maybe auth mechanism miss something?

    Any suggestions? On MS connect site a didn't found exchange bugs topic :)




    Thursday, January 8, 2015 7:18 PM

All replies

  • So if someone wants to reproduce the issue, take one SP1 server, and one CU7 or 6 or 5.

    Take receive connector and remove permissions to anonymous users:

    Remove-ADPermission <ReceiveConnector Name> –user “NT AUTHORITY\Anonymous Logon” –ExtendedRights ms-Exch-SMTP-Accept-Authoritative-Domain-Sender

    Result on SP1:

    if message come from Internet to expect connector we change, it will be refused.

    Result on CU6,7:

    if message come from Internet to expect connector we change, it will be received!

    Friday, January 9, 2015 5:20 PM
  • Hi Dmitriy,

    Thank you for your point. This is a quick note to let you know that I am trying to involve someone familiar with this topic to further look at this issue.

    Regards,


    Winnie Liang
    TechNet Community Support

    Monday, January 12, 2015 2:04 AM
    Moderator
  • Hi Dmitriy,

    Do you compare the AD permission of the Internet connectors between SP1 and CU7?

    Meanwhile, if there is no 250-auth in the telnet, what is the authentication setting of the Internet receive connector?

    Thanks.

    Wednesday, January 14, 2015 8:28 AM
    Moderator
  • Hi, Richard!

    Of course, I compared these permissions, and it match.

    In default installation we have four AD permission for anon users, these are:

    Accept-any-sender, Accept-Routing-Headers, Submit-Message to Server and

    ms-Exch-SMTP-Accept-Authoritative-Domain-Sender. The powershell command remove last permission on connector, and only three remain.

    These settings are identical on both servers, but only SP1 server rejects connections, not both.

    You can check this as quickly as I had, and go to test the situation in the lab.

    Wednesday, January 14, 2015 8:50 AM
  • Hi Dmitriy,

    Thanks for your update.

    Then how about the receive connector configuration? Are they using the same authentication settings?

    Thanks.

    Wednesday, January 14, 2015 10:13 AM
    Moderator
  • Hi Dmitriy,

    Seems like as a bug .I have found a similar issue like you are facing .

    Please check this link.

    https://social.technet.microsoft.com/Forums/office/en-US/0fdf213c-02e3-4ea1-9e6d-242abf9559b8/prevent-own-domain-spoofed-spam?forum=exchangesvrsecuremessaging


    Thanks & Regards S.Nithyanandham

    Wednesday, January 14, 2015 10:17 AM
  • Yes, of course. I try remove Default connector, create Default receive internet connector on both servers, THEN remove a permission.
    Wednesday, January 14, 2015 10:25 AM
  • Hi Dmitriy,

    Thanks for your update.

    Then how about the receive connector configuration? Are they using the same authentication settings?

    Thanks.

    I would like to clarify the situation a little for you.
    I carried out a large migration project environment from EX2010 to 2013.
    When I support this environment for 2013 more than two years.
    And setting worked well in 2010,CU1,CU2,CU3,and finally in SP1 over from my upgrades.
    Understand that it does not work in versions of the above, and I'd really like to know why.

    I repeat that I would like to know in the first place, why it does not work anymore?
    Why it is not documented?

    As You can see, if you approach with the existing and available information on the problem, not you will immediately understand that there are serious problems caused serious changes.

    I want to attract the attention of the  Exchange team  and other peoples to the problem and find out why this is happening.

     
    Thursday, January 15, 2015 6:48 AM
  • Hi Dmitriy,

    Seems like as a bug .I have found a similar issue like you are facing .

    Please check this link.

    https://social.technet.microsoft.com/Forums/office/en-US/0fdf213c-02e3-4ea1-9e6d-242abf9559b8/prevent-own-domain-spoofed-spam?forum=exchangesvrsecuremessaging


    Thanks & Regards S.Nithyanandham

    Thank you very much for this information, I will have it in mind.

    But the logic of the decision is very strange. Why we need turn on Internal mail checks? Exchange stopped to determine where the inside, and where the outside?

    I have a 30 to 50 internal connectors, and now I need change, document, support all  these settings? Why in SP1 we don't need to do suggested workaround? Whats happen with next releases?

    Thursday, January 15, 2015 7:45 AM
  • Hello all,

    I am facing with this issue. Does anyone have solution for this ?

    And how about this issue on CU8 ?

    Thanks and Brgds,

    Quang


    Friday, March 27, 2015 12:29 PM
  • Hi nquang123, unfortunately same issue on a CU8 too. :(
    Thursday, April 2, 2015 7:34 AM
  • Currently having this issue, does anyone know if it was fixed in CU9?

    If not, Dmitriy, have you come up with another way to accomplish similar results? 

    Tuesday, August 4, 2015 5:15 PM
  • Unfortunatly, I didn't check issue in CU9, but I think it's in the same place.

    From my perspective, I've decided to use small postfix server, which really helps me resolve problem. ^^

    Tuesday, August 4, 2015 5:25 PM
  • I just finished the same work with CU 12.
    This bug is still exist.

    icq:62-12-22

    Friday, July 1, 2016 7:24 AM
  • Yeah, it is still there. Product group promised to fix it in the next few releases. Maybe someday it will happen. J
    Thursday, July 7, 2016 12:38 PM
  • well it appears to still be broken in exchange 2016...removed the permissions and still accepting senders from our domain...
    Friday, July 8, 2016 12:15 PM
  • Of course, in E16Cu2 same history! Cause based code is identical. Besides Exchange, the same history in O365- cause one code for all platforms is still the same. But in O365, like as in Exchange, you can mitigate your negative emails by adding Transport Rules for blocking such sort of messages.
    Friday, July 8, 2016 12:24 PM
  • Hi,

    It works on a new Exchange 2016 CU2 deployment! Removed ms-Exch-SMTP-Accept-Authoritative-Domain-Sender and can´t spoof!


    Dario Woitasen | MCSE Lync Server 2013/Exchange Server 2013 | MCITP: Enterprise Messaging Administrator 2007/2010, Lync Server 2010 Administrator, Office 365 | MCSA Windows Server 2012

    Thursday, July 14, 2016 4:23 PM
  • That's a great news, thanks!

    Definitely for those who deciding to migrate for 2016.

    Thursday, July 14, 2016 4:47 PM
  • We get "50 5.7.60 SMTP; Client does not have permissions to send as this sender" after write the body of the message, not after mail from:.


    Dario Woitasen | MCSE Lync Server 2013/Exchange Server 2013 | MCITP: Enterprise Messaging Administrator 2007/2010, Lync Server 2010 Administrator, Office 365 | MCSA Windows Server 2012

    Thursday, July 14, 2016 6:28 PM
  • This is quite nornal behavior for this case.
    Saturday, August 13, 2016 5:31 AM
  • Hi,

    Did you do a clean install Exchange 2016 CU2 or update Exchange 2016 CU1 to CU2 ?
    We update Exchange 2016 CU1 to CU2 and nothing changed.



    • Edited by Pavel Belyj Tuesday, October 25, 2016 10:12 AM
    Tuesday, October 25, 2016 10:11 AM
  • 


    Tuesday, October 25, 2016 10:30 AM
  • Hi Pavel, the main theme doesn't related Exchange 2016.

    It wasn't fixed in Exchange  2016 CU1, but this thread about Exchnage 2013 and this bug still there.


    Tuesday, October 25, 2016 1:32 PM
  • Hi,

    As far as I know issue is still in Exchange 2016 CU4.



    Wednesday, January 25, 2017 11:43 AM
  • Hi,

    As far as I know issue is still in Exchange 2016 CU4.



    Насколько я понимаю, Вам можно отвечать и по русски. Я так понимаю, что закрытие данного вопроса рассмотрено в CU4 и после его установки проблема будет закрыта ?

    I understand that the closure of this issue is considered in CU4 and after installation the problem will be closed?

    • Edited by Pavel Belyj Wednesday, January 25, 2017 11:51 AM
    Wednesday, January 25, 2017 11:50 AM
  • Hi,

    As far as I know issue is still in Exchange 2016 CU4.



    Problem is still present at EX16 CU18!!

    As a way around create your external Internet Receive Connector as HubTransport instead of a FrontEndTransport, issue the command:

    Remove-ADPermission <ReceiveConnector Name> –user “NT AUTHORITY\Anonymous Logon” –ExtendedRights ms-Exch-SMTP-Accept-Authoritative-Domain-Sender

    And everything then works, the issue is that I don't know what implications this might have.

    Best Regards,
    Raul Morales

    • Proposed as answer by Raul Morales Friday, October 20, 2017 4:50 PM
    Friday, October 20, 2017 4:22 PM