Exchange Server Pro » Security

Exchange 2010 FAQ: Are Wildcard SSL Certificates Supported?

Paul Cunningham — Mon, 19 Dec 2011 06:36:11 +0000

Question: can I use a wildcard SSL certificate on my Exchange 2010 server?

Answer: Yes, you can.

Often people ask me whether wildcard SSL certificates can be used with Exchange Server 2010, because they have heard that they are either unsupported, not secure, or just not recommended.

What is a wildcard SSL certificate? From Microsoft TechNet:

A wildcard certificate is designed to support a domain and multiple subdomains. For example, configuring a wildcard certificate for *.contoso.com results in a certificate that will work for mail.contoso.com, web.contoso.com, and autodiscover.contoso.com.

The attractiveness of wildcard SSL certificates is that they are usually cheaper than other types of certificates, and they make some Exchange Server configurations easier to manage.

Support for Exchange 2010 and Wildcard SSL Certificates

The support question is a relatively easy one to answer. Yes they are supported from a vendor perspective. One clue for this is that wildcard SSL certificates are an option in the Exchange 2010 new certificate wizard. Microsoft does not make a habit of including options in Exchange Server that will lead you down an unsupported path.

However they are not supported for all scenarios. For example:

wildcard certificates can’t be used in conjunction with OCS 2007 (eg for secure communications for UM/OWA integration)
wildcard certificates are not supported for older mobile devices such as Windows Mobile 5.0

Security Implications for Exchange 2010 and Wildcard SSL Certificates

The security question is also relatively easy to answer. The common assumption is that wildcard SSL certificates are less secure than other SSL certificates.

Microsoft’s own documentation even references “security implications”.

…many customers are uncomfortable with the security implications of maintaining a certificate that can be used for any sub-domain. A more secure alternative is to list each of the required domains as SANs in the certificate. By default, this approach is used when certificate requests are generated by Exchange.

Verisign/Symantec describes some of those implications here:

Security: If one server or sub-domain is compromised, all sub-domains may be compromised.

Management: If the wildcard certificate needs to be revoked, all sub-domains will need a new certificate.

However, put those concerns in the context of your Exchange organization. If you’re using a wildcard SSL certificate to secure a single, internet-facing Client Access server then the above issues do not create much concern.

On the other hand if you’re deploying a large, global Exchange organization with multiple geographic entry points for various services, or those services spread over many services, then those issues are of greater concern.

Summary

So in conclusion, yes Exchange 2010 supports wildcard SSL certificates and no they are not necessarily less secure than other certificates.

However, do your due diligence and make sure that the specific support and security scenarios that do exist will not adversely impact your own Exchange 2010 deployment.

Get more Exchange Server tips at ExchangeServerPro.com

Email Fundamentals: What is an Open Relay?

Paul Cunningham — Wed, 17 Aug 2011 12:30:00 +0000

If you are responsible for a Microsoft Exchange Server that is connected to the internet then you need to know what an open relay is.

In short, an open relay is an email server that is configured to accept mail from any sender and deliver it to any recipient. This is an undesirable configuration because it can be exploited very easily by spammers and other malicious users.

A properly configured Exchange server will accept mail sent from outside senders to recipients that are “known” or “local” to that Exchange server. In Exchange Server 2007/2010 this is configured in the Accepted Domains settings for the organization.

In other words, it is normal and expected that senders outside the organization can send email to recipients inside the organization. That email should be accepted and delivered by the Exchange server (assuming the recipient actually exists).

This may be slightly different in the case of shared SMTP namespaces and External Relay domains, but for the sake of this article we’ll focus on this simple example.

In comparison, a server that is an open relay would allow a sender from outside of the organization to send (or “relay”) emails to recipients who are also outside of the organization.

Clearly this is bad because a malicious person could send spam, phishing emails or malware via your Exchange server.

The most obvious risk here is that your Exchange server is used by spammers to exploit others. Another concern is how much of your network and server resources this type of exploitation can consume.

But a more serious concern is that it can lead to other mail systems blocking mail that is sent from your server. This can happen in several ways, such as your server being listed on a blacklist such as Spamhaus, or other email systems performing an open relay test on your server and blocking it when it fails the test.

In their default configuration Exchange Server 2007/2010 are not open relays. However through operator error they could become an open relay. If you have any concerns about your Exchange server possibly being an open relay you can test it by going to Abuse.net and entering your Exchange server’s public IP address or DNS name (ie your MX record) and running the test.

I run this test multiple times on any Exchange server deployment that I’m involved in, or any time a change is made to internet-facing servers. If you’ve never run an open relay test on your own server this may be worth considering.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange SSL Certificate Management Survey

Paul Cunningham — Thu, 28 Jul 2011 12:19:29 +0000

The Microsoft Exchange Team is running a survey to collect customer feedback on SSL certificate management in Microsoft Exchange Server.

As the post says it is less than 10 minutes work to complete the survey.

I’ve just filled out the survey myself and it prompted a few thoughts on Exchange Server SSL certificate management.

For one thing, Exchange Server 2010 has much better certificate management tools than Exchange Server 2007. However the survey made me think of at least two ways that it could be improved.

Add an option to the Exchange Management Console to skip the CRL check when enabling an SSL certificate for Exchange services. Currently if the CRL check fails (very common when servers are not permitted to access the web directly) the administrator sees an error. Though you can work around it with proxy settings this can also break the Exchange management tools completely if misconfigured. The other workaround is to enable the certificate using the Exchange Management Shell.
Add an option to Exchange setup to use an internal Certificate Authority for the initial SSL certificate, if one is available. A lot of customers do use internal CA’s for the internal-facing Client Access servers, and this option would solve the Autodiscover certificate warnings that are caused by self-signed certificates.

If you can spare a few minutes go ahead and complete the survey to provide Microsoft with your valuable feedback.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange 2010: How to Grant Send on Behalf Permissions for a Distribution Group

Paul Cunningham — Wed, 29 Jun 2011 10:49:38 +0000

In some Exchange 2010 environments it is desirable to allow users to send email on behalf of a distribution group. However unlike for mailboxes, the Exchange Management Console doesn’t provide an option to grant this permission.

Note: this tutorial is for “send on behalf” permissions. If you’re looking for “send as” permissions go here instead.

To enable send on behalf permissions for a distribution group you need to use the Exchange Management Shell. Launch the shell and use the Set-DistributionGroup command to set the permissions, for example:

Set-DistributionGroup "Sales Team" -GrantSendOnBehalfTo alan.reid

Alan Reid can now use the From field in an Outlook message to send on behalf of the Sales Team group.

Sending on Behalf of a Distribution Group

This is what the message will look like for the recipient.

A message sent on behalf of a distribution group

If they reply to the message it will go to the Sales Team distribution group, not the individual sender.

Replies go to the distribution group, not the individual sender

Alternatively you can grant the send on behalf permission to all members of the group, which can save on administrative effort over time if all group members should be allowed to send of behalf of the group they are in.

Set-DistributionGroup "Sales Team" -GrantSendOnBehalfTo "Sales Team"

Adding Additional Users or Groups to Send on Behalf Permissions

It is important to realise though that this setting is easy to overwrite if you try to add another user or group when there is already one that has been granted send on behalf permissions.

To demonstrate, here is the distribution group with the Sales Team granted send of behalf permissions.

[PS] C:\>Get-DistributionGroup "Sales Team" | fl name,grant*

Name                : Sales Team
GrantSendOnBehalfTo : {exchangeserverpro.net/Company/Groups/Sales Team}

Now if I use the same command as shown earlier to grant another group send on behalf permissions, it overwrites the existing setting instead of appending it.

[PS] C:\>Set-DistributionGroup "Sales Team" -GrantSendOnBehalfTo "Branch Office Team"

[PS] C:\>Get-DistributionGroup "Sales Team" | fl name,grant*

Name                : Sales Team
GrantSendOnBehalfTo : {exchangeserverpro.net/Company/Groups/Branch Office Team}

Instead we need to use a different method to add additional users or groups to the send on behalf permissions.

First, read the existing settings into a variable.

[PS] C:\>$a = Get-DistributionGroup "Sales Team"

Next, read the new group into a second variable.

[PS] C:\>$b = Get-DistributionGroup "Branch Office Team"

If you were adding an individual user you would just use Get-User instead of Get-DistributionGroup.

Then, append the distinguished name of the second group into the GrantSendOnBehalfTo value from the first group.

[PS] C:\>$a.GrantSendOnBehalfTo += $b.DistinguishedName

Finally, set the new value on the first group.

[PS] C:\>Set-DistributionGroup "Sales Team" -GrantSendOnBehalfTo $a.GrantSendOnBehalfTo

You can see now that both the Sales Team and Branch Office Team now have send on behalf permissions to the Sales Team distribution group.

[PS] C:\>Get-DistributionGroup "Sales Team" | fl name,grant*

Name                : Sales Team
GrantSendOnBehalfTo : {exchangeserverpro.net/Company/Groups/Sales Team,
exchangeserverpro.net/Company/Groups/Branch Office Team}

Removing Users or Groups from Send on Behalf Permissions

To remove one of the users or groups from having send on behalf permissions we use a similar process as we used to add them.

First, read the current setting into a variable.

[PS] C:\>$a = Get-DistributionGroup "Sales Team"

You can now see the distinguished names of the users or groups that currently have permissions.

[PS] C:\>$a.GrantSendOnBehalfTo | fl distinguishedname

DistinguishedName : CN=Sales Team,OU=Groups,OU=Company,DC=exchangeserverpro,DC=net

DistinguishedName : CN=Branch Office Team,OU=Groups,OU=Company,DC=exchangeserverpro,DC=net

Remove the one that you don’t want any more.

[PS] C:\>$a.GrantSendOnBehalfTo -= "CN=Branch Office Team,OU=Groups,OU=Company,DC=exchangeserverpro,DC=net"

Now apply the new setting to the distribution group.

[PS] C:\>Set-DistributionGroup "Sales Team" -GrantSendOnBehalfTo $a.GrantSendOnBehalfTo

You can see that the Branch Office Team has been removed from the send on behalf permissions.

[PS] C:\>Get-DistributionGroup "Sales Team" | fl name,grant*

Name                : Sales Team
GrantSendOnBehalfTo : {exchangeserverpro.net/Company/Groups/Sales Team}

Finally, if you want to remove all send on behalf permissions from a group you can run this command.

[PS] C:\>Set-DistributionGroup "Sales Team" -GrantSendOnBehalfTo $null

[PS] C:\>Get-DistributionGroup "Sales Team" | fl name,grant*

Name                : Sales Team
GrantSendOnBehalfTo : {}

Get more Exchange Server tips at ExchangeServerPro.com

Exchange 2010 Shared Calendar Permissions and Nested Groups

Paul Cunningham — Sat, 11 Jun 2011 12:10:53 +0000

When you are assigning shared calendar permissions in Exchange Server 2010 you may encounter situations where users who are members of a group that is nested within the group you grant permissions to still can’t access the calendar.

This can occur when one of the groups in the chain of nested groups is not a Security group. Only Security groups can be used to apply ACLs to objects, Distribution groups can’t be used for this.

In the example below a group has been granted permissions to the calendar, and two users are made members of the parent group through different nested groups.

In this situation the first user will be able to access the shared calendar because only Security groups exist in the chain of nested groups for them. However the second user will not be able to access the calendar because of the Distribution group that is in their chain of nested groups.

The solution is to simply convert any Distribution groups to Security groups. They can remain as mail-enabled Security groups and still be used for email purposes, but will now also be able to be used for granting access to resources as well.

Get more Exchange Server tips at ExchangeServerPro.com

Hackers Successfully Breach RSA Networks

Paul Cunningham — Wed, 20 Apr 2011 12:00:08 +0000

This article has been reposted with updates below.

In mid-March security vendor RSA publicly announced that hackers had successfully compromised parts of their network and extracted information relating to their SecurID products.

Our investigation has led us to believe that the attack is in the category of an Advanced Persistent Threat (APT). Our investigation also revealed that the attack resulted in certain information being extracted from RSA’s systems. Some of that information is specifically related to RSA’s SecurID two-factor authentication products.

RSA SecurID is widely used to provide two-factor authentication of Exchange OWA, Citrix, VPNs, and other corporate remote access. If you use SecurID products it would be wise to keep up to date with this story as it develops.

More information from RSA can be found here.

Updated:

ZDNet: RSA breach report lacks depth
Bruce Schneier writes “RSA Data Security, Inc. is probably pretty screwed if SecurID is compromised. Those hardware tokens have no upgrade path, and would have to be replaced. How many of the company’s customers will replace them with competitors’ tokens. Probably a bunch. Hence, it’s in RSA’s best interest for their customers to forget this incident as quickly as possible.“
Anatomy of an Attack – RSA’s Uri Rivner describes the attack in more detail
RSA says “disclosure could compromise clients“

Get more Exchange Server tips at ExchangeServerPro.com

What Are You Telling Customers About the Epsilon Data Breach?

Paul Cunningham — Sat, 09 Apr 2011 22:18:00 +0000

The big news in the anti-spam world lately has been the customer data breach at Epsilon. You may never have heard of Epsilon before this incident, so here is a quick description of them by Ken Magill.

Epsilon is the largest permission-based email marketing services provider in the world. According to the company’s Web site, it sends more than 40 billion emails annually for more than 2,500 clients, including seven of the Fortune 10.

The data breach first came to widespread attention as major brands such as Hilton, Tivo and Dell began emailing their customers to warn them that their email addresses had been compromised.

This is nothing new in the world of email marketing, high profile data breaches have occurred in recent years with email providers such as iContact and Aweber (twice) and there is a longer history of them dating back to 2005 and 2002. And thats just a few of the ones we actually hear about.

It should come as no surprise that databases of active, verified email addresses are a rich target for data thieves, just as other targets such as the companies that issue SSL certificates or make security tokens are also highly targeted.

The thought of your email addresses being compromised in this way might alarm some customers. But what is the real impact? More spam?

As I explained to one of my customers, if you have an email address then there is a pretty good chance the spammers already have it. In this particular case an office of only 8 staff has close to 40,000 spam emails blocked each month. A few new spammers getting hold of those email addresses might increase the volume of spam a little.

But as long as that spam is still spam-like then it stands no greater chance of making it past the anti-spam protection our customers already have. In other words if the spam is still coming from untrusted IP addresses such as botnets, contains content that will be filtered, or links out to malicious URLs, then you can expect it to be blocked just like other spam.

The real risk is if the spammers are able to construct spam emails that make it past the anti-spam filters, which as we all know does happen from time to time. Depending on the extent of the Epsilon data breach the spammers may also be in possession of information that makes it easier to trick the receiver into believing it is a legitimate email.

For example of the spammer knows your email address and your real name and which companies you’ve done business with and therefore expect to receive email from, then they can craft a more personalized and relevant spam email to send to you.

So while most people would recognize an email from a bank that they aren’t a customer of as spam, if the same email appeared to come from the bank that they do use and addresses them by their real name then the phishing attempt may be more successful.

All of this places the weakest link (aside from the apparently flawed security of email service providers) at the same place it has always been – the end user and their awareness of issues around spam, social engineering, and phishing.

Unfortunately these are complex issues and as Laura Wise recently showed it can be hard enough for an expert in this field to tell real email from fake. Worse still some companies send legitimate email that easily fits the profile of a phishing attempt.

So what are you telling your customers about this?

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server 2010 POP3: Securing POP3 Client Remote Access

Paul Cunningham — Thu, 03 Mar 2011 12:29:54 +0000

In the last part of this tutorial series I gave you an overview of the POP3 protocol and showed you how to enable POP3 for Exchange Server 2010. In this tutorial I’ll show you how to configure the Exchange 2010 POP3 service for secure client access.

Understanding the Need for Secure POP3

The Post Office Protocol (POP) can be insecure as it allows the passing of user credentials in plain text. To understand how serious this is, imagine that your end users are in a public wi-fi network and connecting to your corporate Exchange servers over POP3. They’ll be authenticating with their Active Directory username and password.

If POP access is not secured those credentials will be sent “in the clear” and could be sniffed by an attacker who is also on the same wi-fi network. To see an example of this in action, here is a POP3 session login sniffed on an insecure network.

Insecure POP3 login traffic

The user’s cleverly chosen password of “Seagull1″ is visible to anyone who is able to sniff the network traffic.

As you can see in the example above it is very important that POP traffic is secured if you plan to use it for remote email access in your Exchange 2010 environment.

Configuring Security for the Exchange Server 2010 POP3 Service

To configure the POP3 service on Exchange Server 2010 Client Access servers open the Exchange Management Console and navigate to Server Configuration/Client Access.

Click on the name of the Client Access server you want to configure, and then open the Properties of the POP3 protocol in the lower pane.

Configuring the POP3 protocol for Exchange 2010 Client Access servers

On the Authentication tab you can see that Secure logon is the default setting. So why have I been explaining the importance of POP3 security to you when Exchange 2010 is secure by default?

Exchange 2010 POP3 default Authentication settings

Because I see a lot of customers changing this setting to Plain text logon, simply because that is the easiest way to get POP3 working quickly. Usually they do this because they encounter logon errors for clients who are trying to connect.

POP3 logon errors for Exchange Server 2010 remote user

A network capture shows the same error occurring.

Exchange 2010 POP3 client logon error network traffic

This will happen if the email client is not configured to use SSL for the connection.

Configuring SSL connection for POP3 client

When the POP3 connection is made using SSL the client is able to logon and retrieve mail successfully. And more importantly, they are doing so without attackers on insecure networks being able to sniff the credentials from the network traffic.

Network capture of SSL-secured POP3 traffic

Configuring Ports for Exchange Server 2010 POP3

You may have noticed in the screenshot above that when the client is configured for SSL it changes the port from 110 to 995. TCP 995 is the port for SSL-secured POP3. The POP3 service is bound to both ports 110 and 995 by default. You can see this in the Bindings tab of the POP3 properties.

Exchange 2010 POP3 default port bindings

Configuring an SSL Certificate for Exchange Server 2010 POP3

Because SSL is being used to secure the POP3 connections you will need to configure an SSL certificate for your Client Access server.

This certificate must include the name that you want your remote users to connect to for POP3 access, as well as be trusted by the remote user’s computer that they are connecting from. If it is not trusted, or there is a name mismatch, then they may receive certificate warnings in their POP3 email client.

Certificate warnings for Exchange 2010 POP3 users

To fix this after installing an SSL certificate configure the certificate name in the Authentication tab of the POP3 properties.

Configuring SSL certificate name for Exchange 2010 POP3

You’ll need to restart the POP3 service to apply this or any other configuration change that you make.

When all of the settings are configured correctly your remote email users will be able to connect to Exchange Server 2010 over POP3 securely.

In the next part of this tutorial series we’ll take a look at some of the other configuration options for Exchange 2010 POP3.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server 2010 SP1 Mailbox Audit Logging Step by Step Guide

Paul Cunningham — Tue, 08 Feb 2011 12:21:41 +0000

A lot of businesses want to be able to track who accesses mailboxes in the organization, and who takes certain actions such as deleting mailbox items. This is particularly true where mailboxes are accessed by delegates, for example when a senior manager has several people who access and manage their mailbox, or for shared mailboxes such as those used by sales and support teams.

Exchange Server 2010 SP1 includes a feature called Mailbox Audit Logging that provides exactly this capability. However it is not turned on for mailboxes by default, so the Exchange administrator has to enable for those mailboxes which are considered sensitive or any where access needs to be logged and audited.

You can see whether a mailbox has audit logging enabled by running the Get-Mailbox command.

[PS] C:\>Get-Mailbox Alan.Reid | fl *audit*

AuditEnabled     : False
AuditLogAgeLimit : 90.00:00:00
AuditAdmin       : {Update, Move, MoveToDeletedItems, SoftDelete, HardDelete, FolderBind, SendAs, SendOnBehalf, Create}
AuditDelegate    : {Update, SoftDelete, HardDelete, SendAs, Create}
AuditOwner       : {}

The output there shows you that:

Mailbox auditing is not enabled for this mailbox
The log age limit is 90 days
The actions that are logged for admins, delegates, and the owner themselves

Note how the mailbox owner is not logged by default, because their access would generate a lot of audit log entries. Delegates are logged for basic actions, and administrators are logged for additional administrative actions as well.

To enable a mailbox for audit logging use the Set-Mailbox command.

[PS] C:\>Set-Mailbox Alan.Reid -AuditEnabled $true

To demonstrate audit logging I’ve accessed the mailbox as delegate Alex Heyne, and deleted several inbox items.

There are a few different ways you can look for mailbox audit log entries. The first is a by searching a single mailbox using the Exchange Management Shell.

The Search-MailboxAuditLog command lets use perform searches of mailbox audit logs. In this example I’m performing a search and displaying just one entry.

[PS] C:\>Search-MailboxAuditLog -Identity Alan.Reid -LogonTypes Delegate -StartDate 1/1/2011 -EndDate 2/8/2011 -ResultSi
ze 1 -ShowDetails

RunspaceId               : d76bf455-a098-4ef2-abad-7d0b153df302
Operation                : SoftDelete
OperationResult          : Succeeded
LogonType                : Delegate
ExternalAccess           : False
DestFolderId             :
DestFolderPathName       :
FolderId                 : LgAAAABP8tPUduCNQbq3ixaUfzrSAQD4k0krNt4bTo9RiFYHZzc/AAAAAB6kAAAB
FolderPathName           : \Inbox
ClientInfoString         : Client=MSExchangeRPC
ClientIPAddress          : 10.0.1.11
ClientMachineName        :
ClientProcessName        : OUTLOOK.EXE
ClientVersion            : 14.0.4760.1000
InternalLogonType        : Delegated
MailboxOwnerUPN          : Alan.Reid@exchangeserverpro.net
MailboxOwnerSid          : S-1-5-21-3252988086-3956323440-3716555505-1113
DestMailboxOwnerUPN      :
DestMailboxOwnerSid      :
DestMailboxGuid          :
CrossMailboxOperation    : False
LogonUserDisplayName     : Alex Heyne
LogonUserSid             : S-1-5-21-3252988086-3956323440-3716555505-1117
SourceItems              : { RgAAAABP8tPUduCNQbq3ixaUfzrSBwD4k0krNt4bTo9RiFYHZzc/AAAAAB6kAACNDsKGlk9ZQqbgD/lyUK03AAAAvG
                           eCAAAA,  RgAAAABP8tPUduCNQbq3ixaUfzrSBwD4k0krNt4bTo9RiFYHZzc/AAAAAB6kAACNDsKGlk9ZQqbgD/lyUK0
                           3AAAAvGeBAAAA,  RgAAAABP8tPUduCNQbq3ixaUfzrSBwD4k0krNt4bTo9RiFYHZzc/AAAAAB6kAACNDsKGlk9ZQqbg
                           D/lyUK03AAAAvGeAAAAA,  RgAAAABP8tPUduCNQbq3ixaUfzrSBwD4k0krNt4bTo9RiFYHZzc/AAAAAB6kAACNDsKGl
                           k9ZQqbgD/lyUK03AAAAvGd/AAAA,  RgAAAABP8tPUduCNQbq3ixaUfzrSBwD4k0krNt4bTo9RiFYHZzc/AAAAAB6kAA
                           CNDsKGlk9ZQqbgD/lyUK03AAAAvGd+AAAA,  RgAAAABP8tPUduCNQbq3ixaUfzrSBwD4k0krNt4bTo9RiFYHZzc/AAA
                           AAB6kAACNDsKGlk9ZQqbgD/lyUK03AAAAvGd9AAAA,  RgAAAABP8tPUduCNQbq3ixaUfzrSBwD4k0krNt4bTo9RiFYH
                           Zzc/AAAAAB6kAACNDsKGlk9ZQqbgD/lyUK03AAAAvGd8AAAA,  RgAAAABP8tPUduCNQbq3ixaUfzrSBwD4k0krNt4bT
                           o9RiFYHZzc/AAAAAB6kAACNDsKGlk9ZQqbgD/lyUK03AAAAvGd7AAAA,  RgAAAABP8tPUduCNQbq3ixaUfzrSBwD4k0
                           krNt4bTo9RiFYHZzc/AAAAAB6kAACNDsKGlk9ZQqbgD/lyUK03AAAAvGd6AAAA,  RgAAAABP8tPUduCNQbq3ixaUfzr
                           SBwD4k0krNt4bTo9RiFYHZzc/AAAAAB6kAACNDsKGlk9ZQqbgD/lyUK03AAAAvGd5AAAA,  RgAAAABP8tPUduCNQbq3
                           ixaUfzrSBwD4k0krNt4bTo9RiFYHZzc/AAAAAB6kAACNDsKGlk9ZQqbgD/lyUK03AAAAvGd4AAAA,  RgAAAABP8tPUd
                           uCNQbq3ixaUfzrSBwD4k0krNt4bTo9RiFYHZzc/AAAAAB6kAACNDsKGlk9ZQqbgD/lyUK03AAAAvGd3AAAA,  RgAAAA
                           BP8tPUduCNQbq3ixaUfzrSBwD4k0krNt4bTo9RiFYHZzc/AAAAAB6kAACNDsKGlk9ZQqbgD/lyUK03AAAAvGd2AAAA,
                            RgAAAABP8tPUduCNQbq3ixaUfzrSBwD4k0krNt4bTo9RiFYHZzc/AAAAAB6kAACNDsKGlk9ZQqbgD/lyUK03AAAAvGd
                           1AAAA,  RgAAAABP8tPUduCNQbq3ixaUfzrSBwD4k0krNt4bTo9RiFYHZzc/AAAAAB6kAACNDsKGlk9ZQqbgD/lyUK03
                           AAAAvGd0AAAA}
SourceFolders            : {}
ItemId                   :
ItemSubject              :
DirtyProperties          :
OriginatingServer        : ESP-HO-EX2010A (14.01.0218.011)
MailboxGuid              : d91ebf81-f836-431c-8857-2f2a46ee0a93
MailboxResolvedOwnerName : Alan Reid
LastAccessed             : 2/7/2011 10:11:33 PM
Identity                 : RgAAAABP8tPUduCNQbq3ixaUfzrSBwAVowOS8YKPSZu3yRX+MS1dAAAAAj7RAAAVowOS8YKPSZu3yRX+MS1dAAAAAj7o
                           AAAJ
IsValid                  : True

As you can see the information is partially useful (we can see who did something and when they did it) but there is also a lot of unreadable data presented.

Mailbox audit logs can also be searched using the Exchange Control Panel. In the organization management area are a series of different auditing tasks, including mailbox audit log searches.

Exchange 2010 Mailbox Audit Log Search in Exchange Control Panel

This web interface makes searches much easier and also returns results that are readable.

Exchange 2010 Mailbox Audit Log search results

You can see that mailbox audit logging is a useful feature for organizations that need to audit this kind of activity, but with the trade off that the logs are stored in the mailbox and so will increase mailbox size. However since any audit logging of this kind has to be stored somewhere this shouldn’t be seen as a road block to activating the feature on only those specific mailboxes that require auditing.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server AntiSpam: Review of SPAMFighter Exchange Module for Exchange Server 2010

Paul Cunningham — Wed, 01 Dec 2010 12:57:21 +0000

SPAMfighter Exchange Module

SPAMfighter Exchange Module is an Exchange Server antispam product for Exchange 2000, 2003, 2007 and 2010, and also for Small Business Server.

SPAMfighter is installed on Exchange servers to perform its scanning, but also uses cloud capabilities to quickly detect new spam based on reports from over 7,000,000 SPAMfighter customers around the world.

It does this by creating an encrypted signature of incoming email messages and sending that signature to the SPAMfighter servers for comparison. Thanks to this approach SPAMfighter customers get fast detection of new spam outbreaks without relying on scheduled signature updates.

Installing SPAMfighter Exchange Module

For my test I installed SPAMfighter Exchange Module on a Windows Server 2008 R2 server with the Exchange Server 2010 Client Access and Hub Transport server roles.

Installing SPAMfighter Exchange Module

With Exchange already installed SPAMfighter only needed the additional pre-requisite of Microsoft Visual C++ Runtime 8.0 Service Pack 1, which it will automatically download and install for you.

SPAMfighter automatically downloads pre-requisites

The setup process is very simple and straightforward, and SPAMfighter downloads the latest virus definition updates as part of the setup process.

Configuring SPAMfighter Exchange Module

SPAMfighter has a web-based administration console that is simple and intuitive to use. There are three main sections to the admin console.

Configuration

The configuration section is where you configure each of the different SPAMfighter filters and their policy settings. I found this section to be quite easy to follow and understand, unlike some other similar products.

SPAMfighter Policy Configuration page

All of the features you would expect of an Exchange antispam product are easily configurable, including sliders to adjust the aggressiveness of different filters, whitelists/blacklists, and filtering of file extensions. I also liked the option to filter based on languages, which is very useful considering the amount of spam I see that is written in a foreign language.

One of the strengths of SPAMfighter is the community filter, which uses spam reports from the millions of SPAMfighter users around the world to detect and block new spam variants quickly.

SPAMfighter Community Filter settings

Administrators are given granular control over how the filtering policies are configured, and this can be made even more specific with the use of Usergroups, allowing different policies to apply to different areas of the business.

Usergroups allow different SPAMfighter policies to be applied

Filter settings can also be configured on individual mailboxes, for example to blacklist or whitelist a certain email address for just one user in the organization.

Statistics

To me a critical feature of email security products is the reporting. Without useful reporting it is impossible to know whether a product is performing well or not. Fortunately SPAMfighter has very good reports that are easily accessed in the administration console.

SPAMfighter statistics reporting

Scheduled reports can also be sent to any user via email, which makes them easily available to non-administrators. This saves the Exchange Server administrator a lot of time since they don’t need to manually generate reports for managers.

Administration

The administration section is where you can configure product and definition update schedules, diagnostic logging, performance tuning, and who can access the administrative console.

SPAMfighter integrates with Active Directory for security settings

SPAMfighter Exchange Module is integrated with both Exchange Server and with Active Directory, so you can use Active Directory groups to manage access to the administrative console, and let those admins login with their regular user credentials. No need to create and manage any special admin accounts and passwords.

Performance of SPAMfighter Exchange Module

After installing SPAMfighter on my test Exchange server I redirected a few different email accounts and domains towards it to see how it performed.

None of the clean mail that was sent to SPAMfighter was blocked as spam, so there were zero false-positives during this test. Spam that is detected gets moved to a folder in the user’s mailbox, so they are always able to check in case they think something has been blocked in error.

SPAMfighter sends spam to Junk Email or to a custom folder

I preferred to use Junk Email for this instead of the default SPAMfighter folder (note you can also specify your own custom folder name) because Outlook disables risky content such as hyperlinks and remote images in the Junk Email folder.

SPAMfighter Documentation and Support

Though there wasn’t a PDF user manual included with SPAMfighter Exchange Module the installation process was simple enough, and the administration console quite intuitive.

Anyone who has used an Exchange anti-spam product before should have no trouble configuring SPAMfighter the way that they want it. For people who are new to this type of technology each of the settings that you can configure in SPAMfighter has its own built in Help page to explain in more detail what the settings do.

SPAMfighter has detailed help documentation built in

I was able to experience SPAMfighter’s customer support when I had a minor issue in my testing environment. Their responses were fast and helpful and we were able to solve my problem quickly.

Conclusion

Overall I am impressed with the simplicity and effectiveness of SPAMfighter Exchange Module. It is an easy product to install and configure, and provides just enough flexibility in its configuration options without getting too complicated. More importantly, it blocked all of the spam that was sent to the server without a single false positive during my tests.

The SPAMfighter pricing page lists the license costs from 5 users up to 2500 users and I would easily recommend it for Exchange Server environments of that size range.

Disclosure: SPAMfighter is a paid advertiser on this website.

Screenshot Gallery:

Click to Show »

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server Pro » Security

Exchange 2010 FAQ: Are Wildcard SSL Certificates Supported?

Support for Exchange 2010 and Wildcard SSL Certificates

Security Implications for Exchange 2010 and Wildcard SSL Certificates

Summary

Related posts:

Email Fundamentals: What is an Open Relay?

Related posts:

Exchange SSL Certificate Management Survey

Related posts:

Exchange 2010: How to Grant Send on Behalf Permissions for a Distribution Group

Adding Additional Users or Groups to Send on Behalf Permissions

Removing Users or Groups from Send on Behalf Permissions

Related posts:

Exchange 2010 Shared Calendar Permissions and Nested Groups

Related posts:

Hackers Successfully Breach RSA Networks

Related posts:

What Are You Telling Customers About the Epsilon Data Breach?

Related posts:

Exchange Server 2010 POP3: Securing POP3 Client Remote Access

Understanding the Need for Secure POP3

Configuring Security for the Exchange Server 2010 POP3 Service

Configuring Ports for Exchange Server 2010 POP3

Configuring an SSL Certificate for Exchange Server 2010 POP3

Related posts:

Exchange Server 2010 SP1 Mailbox Audit Logging Step by Step Guide

Related posts:

Exchange Server AntiSpam: Review of SPAMFighter Exchange Module for Exchange Server 2010

Installing SPAMfighter Exchange Module

Configuring SPAMfighter Exchange Module

Configuration

Statistics

Administration

Performance of SPAMfighter Exchange Module

SPAMfighter Documentation and Support

Conclusion

Related posts: