Exchange Server Pro » Security

How to Configure a Relay Connector for Exchange Server 2010

Paul Cunningham — Thu, 19 Aug 2010 09:00:59 +0000

In most Exchange Server 2010 environments there will be the need to allow relaying for certain hosts, devices or applications to send email via the Exchange server. This is common with multi-function devices such as network attached printer/scanners, or applications such as backup software that send email reports.

SMTP communication is handled by the Hub Transport server in an Exchange organization. The transport service listens for SMTP connections on it’s default Receive Connector. However, this connector is secured by default to not allow anonymous connections (ie, the type of connection most non-Exchange systems will be making).

You can see this in effect if you telnet to the server on port 25 and try to initiate unauthenticated SMTP communications.

220 EX3.exchangeserverpro.local Microsoft ESMTP MAIL Service ready at Wed, 18 Au
g 2010 19:42:27 +1000
helo
250 EX3.exchangeserverpro.local Hello [192.168.0.9]
mail from: somebody@hotmail.com
530 5.7.1 Client was not authenticated

For some Hub Transport servers that are internet-facing, anonymous connections may already be enabled. In those cases relay would still be denied but will behave differently than the first example.

220 EX3.exchangeserverpro.local Microsoft ESMTP MAIL Service ready at Wed, 18 Au
g 2010 20:01:44 +1000
helo
250 EX3.exchangeserverpro.local Hello [192.168.0.9]
mail from: somebody@hotmail.com
250 2.1.0 Sender OK
rcpt to: somebody@gmail.com
550 5.7.1 Unable to relay

You’ll note that relay is denied if I try to send from an @hotmail.com address to an @gmail.com address, because neither is a valid domain for the Exchange organization. But with Anonymous Users enabled on the Receive Connector I can send from an @hotmail.com address to a valid local address.

220 EX3.exchangeserverpro.local Microsoft ESMTP MAIL Service ready at Wed, 18 Au
g 2010 20:05:54 +1000
helo
250 EX3.exchangeserverpro.local Hello [192.168.0.9]
mail from: somebody@hotmail.com
250 2.1.0 Sender OK
rcpt to: alan.reid@exchangeserverpro.local
250 2.1.5 Recipient OK
data
354 Start mail input; end with .
test
.
250 2.6.0  [In
ternalId=2] Queued mail for delivery

However if I try to relay out to an external recipient, the Exchange server does not allow it.

220 EX3.exchangeserverpro.local Microsoft ESMTP MAIL Service ready at Wed, 18 Au
g 2010 20:11:27 +1000
helo
250 EX3.exchangeserverpro.local Hello [192.168.0.9]
mail from: backups@exchangeserverpro.net
250 2.1.0 Sender OK
rcpt to: alerts@managedserviceprovider.com
550 5.7.1 Unable to relay

To permit a non-Exchange server to relay mail we can create a new Receive Connector on the Hub Transport server. Launch the Exchange Management Console and navigate to Server Management, and then Hub Transport. Select the Hub Transport server you wish to create the new Receive Connector on, and from the Actions pane of the console choose New Receive Connector.

Give the new connector a name such as “Relay ” and click Next to continue.

You can leave the local network settings as is, or optionally you can use a dedicated IP address for this connector if one has already been allocated to the server. Using dedicated IP addresses for each connector is sometimes required if you need to create connectors with different authentication settings, but for a general relay connector it is not necessary to change it.

Highlight the default IP range in the remote network settings and click the red X to delete it.

Now click the Add button and enter the IP address of the server you want to allow to relay through the Exchange server. Click OK to add it and then Next to continue.

Click the New button to complete the wizard.

The Receive Connector has now been created but is not yet ready to allow the server to relay through it. Go back to the Exchange Management Console, right-click the newly created Receive Connector and choose properties.

Select the Permission Groups tab and tick the Exchange Servers box.

Select the Authentication Tab and tick the Externally Secured box.

Apply the changes and the Receive Connector is now ready for the server to relay through.

220 EX3.exchangeserverpro.local Microsoft ESMTP MAIL Service ready at Wed, 18 Au
g 2010 20:31:00 +1000
helo
250 EX3.exchangeserverpro.local Hello [192.168.0.9]
mail from: backups@exchangeserverpro.net
250 2.1.0 Sender OK
rcpt to: alerts@managedserviceprovider.com
250 2.1.5 Recipient OK
data
354 Start mail input; end with .
test
.
250 2.6.0 <924bab1e-0f07-4054-8700-d121577993b4@EX3.exchangeserverpro.local> [In
ternalId=3] Queued mail for delivery

Because the remote IP range has been secured to that single IP address, any other servers on different IP addresses still won’t be able to relay through the Exchange Server. From any other IP address not included in the remote IP range on the Receive Connector relay will be denied.

220 EX3.exchangeserverpro.local Microsoft ESMTP MAIL Service ready at Wed, 18 Au
g 2010 20:46:06 +1000
helo
250 EX3.exchangeserverpro.local Hello [192.168.0.2]
mail from: backups@exchangeserverpro.net
250 2.1.0 Sender OK
rcpt to: alerts@managedserviceprovider.com
550 5.7.1 Unable to relay

You can later add more IP addresses, IP ranges, subnets, or even add multiple IP addresses to the Receive Connector using a script if necessary.

Get more Exchange Server tips at ExchangeServerPro.com

Causes of MapiExceptionNotAuthorized Error Sending to Public Folders

Paul Cunningham — Thu, 22 Apr 2010 04:15:30 +0000

In some scenarios a mailbox user sending emails to a mail-enabled Public Folder may receive an undeliverable message in reply.

The message contains the following error details:

#550 5.2.0 STOREDRV.Deliver: The Microsoft Exchange Information Store service
reported an error.  The following information should help identify the cause
of this error: "MapiExceptionNotAuthorized:16.18969:57080000..."

This error can occur under a variety of configurations relating to Public Folder client permissions.

External Senders

External senders will receive the error if the Public Folder does not permit “Anonymous” to create new items.

[PS] C:\>Get-PublicFolderClientPermission \pftest

Identity                   User                       AccessRights
--------                   ----                       ------------
\pftest                    Default                    {FolderVisible}
\pftest                    mycompany.local/Users/A... {Owner}
\pftest                    Anonymous                  {None}

To grant this access run the following command in the Exchange Management Shell.

[PS] C:\>Add-PublicFolderClientPermission \pftest -User Anonymous -AccessRights CreateItems

Identity                   User                       AccessRights
--------                   ----                       ------------
\pftest                    Anonymous                  {CreateItems}

Internal Senders

Internal senders are able to be authenticated by the Exchange server, and so are not treated as Anonymous. For internal senders the user must have at least Create Items permissions on the Public Folder. For general use Public Folders this can be granted as the “Default” permission.

To grant this access run the following command in the Exchange Management Shell.

[PS] C:\>Add-PublicFolderClientPermission \pftest -user Default -AccessRights CreateItems

Identity                   User                       AccessRights
--------                   ----                       ------------
\pftest                    Default                    {Contributor}

Internal Senders Alternate Scenario

Because internal senders are being authenticated by the Exchange server their group membership is taken into consideration. When the Exchange server receives a new item from an internal sender it takes the following basic steps:

Maps the sender address to a user account object (this occurs even if the email was not sent by the user themselves, eg was sent via Telnet)
Enumerates the user’s group membership
Assesses the group membership against the ACLs on the Public Folder
Permits or denies the mail item depending on the ACL

Because of this process the Exchange server must have Read access to the groups that the sender is a member of, including direct membership and indirect membership (eg by nested groups).

If the Exchange server cannot read a group object it will deny the mail item and the user will receive the undeliverable message with “MapiExceptionNotAuthorized”. The reason for this is that it is designed to fail in a secure way (ie, “I can’t verify your access therefore I will deny you”), rather than an insecure way (ie “I can’t verify your access therefore I will permit you”).

With that in mind you would need to investigate all of the direct and indirect group membership for the user and try to locate a group object that does not have the Exchange Servers group with Read access in its ACL. Most commonly this will occur when the group is in a Domain in the Forest that has not been prepped for Exchange, or is in an OU where permissions inheritance has been disabled.

Correcting the ACL on the group objects should resolve the undeliverable “MapiExceptionNotAuthorized” error in those cases.

Get more Exchange Server tips at ExchangeServerPro.com

GFI LANGuard Tutorial

Paul Cunningham — Wed, 15 Jul 2009 01:00:49 +0000

SecurityDistro.com has published my tutorial on how to use GFI LANGuard to find and resolve security vulnerabilities on your network.

A typical business network is made up of many computers each of which represents a potential security hole for the network. As networks grow the effort to manage these security risks grows as well. Although different vendors provide management tools specific to their products these do little to reduce the administrative burden of managing all of the different elements of the network.

GFI LANguard offers a single, centralized solution for IT administrators to scan the computers and servers on the network to detect and resolve security threats. GFI LANguard is available both as a licensed product for larger networks, and also as a free, full featured version for scanning up to 5 IP addresses.

Read the full tutorial here.

Get more Exchange Server tips at ExchangeServerPro.com

Bruce Schneier on Certificate Authorities

Paul Cunningham — Tue, 30 Dec 2008 22:34:04 +0000

“The CA system is broken, but it works because broken systems tend to be better for society, which needs fluidity in the face of complicated social constructs,” Schneier said. “Systems that are broken but work are very common in the real world: Front door locks are surprisingly pickable. Think of faxed signatures, for example. It’s a ridiculous form of authentication, yet people trust these documents all the time for very important stuff.”

Link: Researchers Hack Internet Security Infrastructure

Get more Exchange Server tips at ExchangeServerPro.com

Well-designed security systems fail gracefully, SonicWALL does not

Paul Cunningham — Sat, 06 Dec 2008 11:31:00 +0000

To quote Bruce Schneier, “well-designed security systems fail gracefully”. This means for example when the ISA firewall service fails it closes off network connectivity entirely (ie retains security) instead of opening your entire network up (ie decreases security).

This week SonicWALL’s license servers suffered a glitch rendering thousands of customer units useless and leaving the customers’ networks open to attack. The affected devices included firewall and email security appliances.

Security appliances are popular for no good reason at all. The decision maker in many organisations falls for marketing hype that a “hardware firewall” is better than the alternative, ignoring the obvious fact that the appliance is ultimately no different to any other firewall that consists of a piece of hardware running secure OS and firewall features.

When purchasing a firewall or security product the decision should not be based on perception but rather fact. I’m sure no SonicWALL customer ever imagined that the company could make an error on their license servers that would comprimise their security in such a manner. Its worth noting that once your Microsoft ISA Server firewall is up and running it can never become “unlicensed” by an error at Microsoft.

Get more Exchange Server tips at ExchangeServerPro.com

SharePoint Security Resources

Paul Cunningham — Mon, 17 Nov 2008 08:00:00 +0000

Microsoft provides two useful resources for MOSS security:

Security for Office SharePoint Server 2007 (downloadable book)
Office SharePoint Server Security Account Requirements (worksheet)

Link: John Westworth’s blog on Technet

Get more Exchange Server tips at ExchangeServerPro.com

Steve Riley on hypervisor attacks

Paul Cunningham — Fri, 05 Sep 2008 07:42:15 +0000

You have to ask: is there malware on my system? You can be 100 per cent certain there is no malware that you can detect, but less than 100 per cent certain that there is no malware at all. Now, ladies and gentlemen, isn’t this true of every computer we already have? There is no difference just because it’s virtualisation.

Read the entire article at ZDNet.

Get more Exchange Server tips at ExchangeServerPro.com

White Paper: Configuring Virtual Organizations and Address List Segregation in Exchange 2007

Paul Cunningham — Fri, 08 Feb 2008 03:15:42 +0000

Microsoft has released their own white paper containing guidance on configuring Exchange 2007 for Address List separation. This is something that was pretty easy in Exchange 2003, but suddenly made a lot more complicated and less obvious in Exchange 2007. A bunch of home brew solutions came about some time after Exchange 2007 was released and now Microsoft’s white paper has the prescriptive guidance (which is basically the same as some of the better home brews out there).

Why segregate Address Lists?

Some larger organisations look for segregated Address Lists as a means of improving the relevancy of the Address List objects that users are seeing in their Outlook address book. Why see all 20,000 global employees when really you only need to see the 1000 employees and distribution lists in your country (especially since smart admins lock down distribution lists so people can’t send rubbish emails to “All Staff – Global” for example). Here is Microsoft’s word on the matter:

Address list segregation is a process whereby administrators can segment their users into separate groups and implement security policies so that groups of users can see only their specific address list. The ability to restrict access to address lists in this manner may be used as part of the toolset for helping companies meet their internal security requirements and as part of a regulatory compliance strategy for meeting the requirements dictated by the Health Insurance Portability and Accountability Act (HIPPA), and the Sarbanes-Oxley Act.

It is useful to illustrate how address list segregation can be implemented by way of examples. Suppose your company, Contoso, purchases the company Fabrikam. The management team determines that they want to manage Fabrikam’s entire IT infrastructure, but they want the employees of Contoso and Fabrikam to be completely segregated so that they are only able to see other users and resources from their respective companies. By implementing address list segregation, Contoso administrators can meet this requirement for all Exchange Server 2007 functionality.

Another scenario is the “Virtual Organisations” mentioned in the White Paper title, which I think is code for hosted Exchange providers. Last year I worked on deploying a hosted environment that included Exchange Server 2007 and that is how I encountered all of the difficulties with configuring Exchange 2007 in this fashion (and came across the home brew solutions). Microsoft calls it “Virtual Organisations” but I think that is because they are not recommending you use this solution for hosted Exchange services.

It is also important to understand that attempting to configure Exchange 2007 as a commercial “hosting” solution is not recommended.

The configuration described in this document is complex in nature, and while it can be effective in smaller environments or in limited scope, it can become very challenging to manage such a configuration as the scope of the deployment increases if automation steps are not implemented.

It is conceivable that an organisation that has developed suitable account management scripts in their hosted environment could solve this scalability issue.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server 2007 SP1 disables Exchange Anti-spam updates

Paul Cunningham — Tue, 05 Feb 2008 21:13:50 +0000

Here is the anti-spam configuration on an Exchange Server 2007 RTM server:

[PS] C:>Get-AntispamUpdates   

UpdateMode                  : Automatic
LatestContentFilterVersion  : 3.3.4604.600
SpamSignatureUpdatesEnabled : True
LatestSpamSignatureVersion  : 3.3.4604.600
IPReputationUpdatesEnabled  : True
LatestIPReputationVersion   : 3.3.4604.001
MicrosoftUpdate             : NotConfigured

And here is the same Exchange Server 2007 server immediately after upgrading to Service Pack 1:

[PS] C:>Get-AntispamUpdates   

UpdateMode                  : Disabled
LatestContentFilterVersion  : 3.3.4604.600
SpamSignatureUpdatesEnabled : False
LatestSpamSignatureVersion  : 3.3.4604.600
IPReputationUpdatesEnabled  : False
LatestIPReputationVersion   : 3.3.4604.001
MicrosoftUpdate             : NotConfigured

The Service Pack 1 installation disabled the Anti-spam engine updates. This stung me on a production system that I upgraded shortly after the SP1 release. Eventually someone in the office mentioned the ever increasing volume of spam emails to me and I subsequently made this discovery.

Sadly the Release Notes do not seem to include this issue.

Get more Exchange Server tips at ExchangeServerPro.com

Restricting outbound email with Exchange Server 2007 Transport Rules

Paul Cunningham — Tue, 05 Feb 2008 09:08:50 +0000

In prior versions of Exchange an organisation that wished to restrict who could send outbound internet emails could apply the restriction on an SMTP connector. In this example emails sent to the * address space are rejected by default unless sent by a group listed in the “Accept messages from:” list, for example a group named “Internet Email Users”.

Exchange Server 2007 uses Send Connectors for configuring where outbound internet email is delivered, much like an SMTP connector in Exchange 2003 Server. However, the Send Connector is not the place to apply restrictions on who can send outbound internet email. These restrictions are instead applied with Transport Rules.

If you are new to the concept of Transport Rules you should read Understanding How Transport Rules Are Applied In An Exchange Server 2007 Organisation.

To configure the restrictions you create a Transport Rule that follows the same “Deny by default, except if from these groups” approach as Exchange 2003 Server.

Configuring a Transport Rule to Restrict Outbound Internet Email

Create a distribution group through your Exchange Management Console, and give it a descriptive name such as ”Internet Email Users”.
In the EMC go to Organization Configuration -> Hub Transport, and click on the Transport Rules tab.
Create a new Transport Rule, name it something like “Restrict Internet Email”
Select “Sent to users Outside the organisation” as the first condition.
Select “Send bounce message…” as the second condition, and configure a bounce message that will be informative enough for your end users.
Select “Except when the message is from member of distribution list” as the exception criteria, and add the Internet Email Users group that was created earlier.
Complete the Transport Rule wizard so that the rule is created in the Exchange Organization.

It may take a short time for the rule to replicate to all Hub Transport servers throughout your Active Directory sites. Because the rule is applied by Hub Transport servers, messages do not have to traverse the network all the way to the last outbound hop before being rejected by this rule. Instead they are rejected by the Hub Transport server within the Active Directory site in which the user’s Mailbox Server is located.

The Hub Transport server caches recipient and distribution list information for four hours, so if you have a rule such as this in place and add new users to the Internet Email Users group, those users may not be able to start sending outbound internet email until the recipient cache has refreshed on the Hub Transport server. Where this is not acceptable you can restart the “Microsoft Exchange Transport” service on each Hub Transport server which will initiate a cache refresh.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server Pro » Security

How to Configure a Relay Connector for Exchange Server 2010

Related posts:

Causes of MapiExceptionNotAuthorized Error Sending to Public Folders

External Senders

Internal Senders

Internal Senders Alternate Scenario

Related posts:

GFI LANGuard Tutorial

Related posts:

Bruce Schneier on Certificate Authorities

Related posts:

Well-designed security systems fail gracefully, SonicWALL does not

Related posts:

SharePoint Security Resources

Related posts:

Steve Riley on hypervisor attacks

Related posts:

White Paper: Configuring Virtual Organizations and Address List Segregation in Exchange 2007

Why segregate Address Lists?

Related posts:

Exchange Server 2007 SP1 disables Exchange Anti-spam updates

Related posts:

Restricting outbound email with Exchange Server 2007 Transport Rules

Configuring a Transport Rule to Restrict Outbound Internet Email

Related posts: