?
Solved

Exchange Server 2013 allows outside systems to send mail as internal users

Posted on 2014-04-12
3
Medium Priority
?
735 Views
Last Modified: 2014-04-13
Dear Support,

I have a new customer with Exchange 2013 and they are receiving email to their internal mailboxes that is addressed as if it came from other employees in the organization.  I know that this can be fixed in Exchange 2010 by using the command:

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

I have run this command in Exchange 2013 and it removed the permission but I can still telnet from an outside system and send emails to internal users as if from internal users.  I have restarted the MS Exchange Transport service and this did not solve the problem.

What I would like to know is if this command is no longer relevant in Exchange 2013?  If this is so how would I go about preventing outside systems from creating emails that look like they came from internal users?  If this command should still work does this mean that the Exchange Server has other problems that are not evident?  Like I said this customer is new and I have little back ground on the system.  I am hesitant to jump down the rabbit hole of windows updates and other measures until I know that the command is valid.  I was asked to focus only on this one issue.

Thanks
0
Comment
Question by:AndrewEckstrom
  • 2
3 Comments
 
LVL 25

Accepted Solution

by:
Zephyr ICT earned 1000 total points
ID: 39996511
I've read in other forums that this is some kind of "bug" ... It doesn't work like it should for others either ... That being said, the workaround they found was to create a new receive connector and define it as a Hub Transport and not a Front-End Transport... That did the trick to solve the issue... Maybe it helps you?
0
 

Author Comment

by:AndrewEckstrom
ID: 39996894
Dear spravtek,

That suggestion has solved the immediate problem.  Since this solution appears to not be part of Microsoft's best practices are there any steps that I need to take into consideration to make sure that the connector does not open unexpected security holes?

Thanks
0
 
LVL 25

Expert Comment

by:Zephyr ICT
ID: 39996952
Hi AndrewEckstrom,

I don't think there will be any issues with this no, though normally it should indeed not be configured like this ... I haven't come across any official documentation either, when I get the change I'll try to ask one of the Exchange guru's I know if he knows more... But that takes a while.
0

Featured Post

Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Microsoft Jet database engine errors can crop up out of nowhere to disrupt the working of the Exchange server. Decoding why a particular error occurs goes a long way in determining the right solution for it.
This article explains how to move an Exchange 2013/2016 mailbox database and logs to a different drive.
The video tutorial explains the basics of the Exchange server Database Availability groups. The components of this video include: 1. Automatic Failover 2. Failover Clustering 3. Active Manager
In this video I will demonstrate how to set up Nine, which I now consider the best alternative email app to Touchdown.
Suggested Courses
Course of the Month3 days, 13 hours left to enroll

600 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question