Welcome back to our second installment of Getting Started with SecurityGateway Part II. 
Did you miss Part I?
At this point we’ll assume that you have read part one of our Getting Started with SecurityGateway series and you have decided on what type of scenario SecurityGateway will run under.
So what’s next?
During the installation of SecurityGateway you will be asked to supply a domain name, select a User Verification Source method, define where the back end email server is located, and create the administrator account. We first need to continue configuring our User Verification Source. Let’s get started!
User Verification Sources
First let’s define: What is a “User Verification Source”?
A “User Verification Source” is a method SecurityGateway uses to automatically detect valid accounts on the back end email server. Users can be added in a manual fashion but it is preferable to have SecurityGateway add/remove users automatically. SecurityGateway supports the User Verification Sources listed below. An account will be created for users on SecurityGateway that are successfully validated.
User Verification Sources can also allow users to authenticate with SecurityGateway using their own username and password for the back end email server. This is referred to as dynamic authentication which the first 3 types of verification do support. The “LDAP” option is the only verification source that does not support dynamic authentication.
- “SMTP Verification (call forward)”. When an email is arriving for a new user on SecurityGateway we will contact the back end server via SMTP and give the MAIL FROM and RCPT TO commands. The RCPT TO command will be the value of the user we are trying to verify. SecurityGateway is looking for a “Recipient OK” type of response to validate that the user account does exist on the back end email server. If we get a “Recipient Unknown” type error then SecurityGateway gives a similar response and the account is not automatically added as a user to SecurityGateway. This is a verification method that can be used against any back end email server.
The draw back to this verification method is that aliases are not automatically detected. An alias address will initially use up an account license on SecurityGateway, although we can manually tie, or relate, alias addresses to real accounts if needed. - “Active Directory/Exchange”. This is the most common method we see since most of our SecurityGateway customers are protecting a back end Exchange Server. When an email is arriving for a new user SecurityGateway can contact Active Directory to find out if the user is valid or not.This type of verification method is the most useful out of all our available options. To access SecurityGateway users only need to remember a single set of credentials. Their credentials to login to Active Directory! When a user tries to authenticate with SecurityGateway using this verification method we will send the credentials to Active Directory looking for a negative (failed username/password) or a positive (username/password are valid) response. As well aliases can be automatically detected and associated to the proper account on SecurityGateway.Read only access is all that is needed. We only need to be able to query Active Directory. SecurityGateway will never make any changes to your Active Directory environment.
- “MDaemon (Minger)”. “Minger” is a protocol exclusive to MDaemon servers that allows us to query a MDaemon server to see if users exist or not. It also allows users to dynamically authenticate with SecurityGateway simply using the same credentials that they access MDaemon with.
- “LDAP”. SecurityGateway can query any generic LDAP server for user verification purposes. As stated above this is the only user verification method that does not support dynamic authentication. User accounts on SecurityGateway would need to be manually given a password for the user to be able to connect.
Let’s get our User Verification Source fully configured to “talk” with an Exchange 2013 server. All we have left to do here is give a username and password to an account that has permissions to access Active Directory. Here’s how we’ll do it.
- log in to SecurityGateway as the admin. In the bottom left hand corner click the “Setup/Users” button, near the top left click “User Verification Sources”, select the entry we are going to make changes to, and then click the Edit button.
- Fill out the User name and Password fields with an account that has permissions to access Active Directory. Click the “Save and Close” button if you are happy with the configuration.
How can I tell if I have my User Verification Source settings entered correctly?
At this point we are assuming that SecurityGateway is not yet live. If SecurityGateway can be reached from the internet via DNS lookups then simply send a test email from an external account (i.e. GMail, Outlook.com, Yahoo). I personally use the Windows Telnet Client to test a User Verification Source if the SecurityGateway server is not live.
Alt-N has a KB article that explains how to send a test email using telnet.
***Note: you only need to go as far as issuing the RCPT TO command with a valid email address of an account in Active Directory and note the response. If you receive a Recipient OK response you now know that the lookup in Active Directory was successful. The user was found and is now added as a user in SecurityGateway. Receiving a “451 Unable to verify recipient” indicates a problem. Below are examples of a failed and successful lookup. Ensure to type quit and press Enter to close the connection. When the session completes, the information is then written to the log file.
Failed User Verification Source Lookup
The error indicates that the username or password is incorrect.
Thu 2014-09-11 11:30:53: –> 250 <mike@ccsoftware.ca>, Sender ok
Thu 2014-09-11 11:31:01: <– rcpt to:<mike@robobak.ca>
Thu 2014-09-11 11:31:01: Performing AD lookup (mail.robobak.ca:389 for mike@robobak.ca)
Thu 2014-09-11 11:31:01: Failed to connect to AD host mail.robobak.ca, port 389 The user name or password is incorrect.
Thu 2014-09-11 11:31:01: ** All user verification sources failed
Thu 2014-09-11 11:31:01: ========== Processing RCPT scripts for recipient: mike@robobak.ca
Thu 2014-09-11 11:31:01: — Executing: Blacklist —
Thu 2014-09-11 11:31:01: — Executing: Tarpitting —
Thu 2014-09-11 11:31:01: * Enabling Tarpitting
Thu 2014-09-11 11:31:01: — Executing: Relaying Denied —
Thu 2014-09-11 11:31:01: — Executing: Invalid Recipient —
Thu 2014-09-11 11:31:01: ** Error 450 <mike@robobak.ca>, Unable to verify recipient
Thu 2014-09-11 11:31:01: –> 450 <mike@robobak.ca>, Unable to verify recipient
Successful User Verification Source Lookup
Thu 2014-09-11 11:44:09: –> 250 <mike@ccsoftware.ca>, Sender ok
Thu 2014-09-11 11:44:19: <– rcpt to:<Mike@robobak.ca>
Thu 2014-09-11 11:44:19: Performing AD lookup (mail.robobak.ca:389 for Mike@robobak.ca)
Thu 2014-09-11 11:44:19: Using search filter ((&(|(objectclass=user)(objectclass=group)(objectclass=publicFolder))(|(mail=Mike@robobak.ca)(proxyAddresses=SMTP:Mike@robobak.ca))))
Thu 2014-09-11 11:44:20: Found user: Mike Gordon <mike@robobak.ca>
Thu 2014-09-11 11:44:20: ========== Processing RCPT scripts for recipient: mike@robobak.ca
Thu 2014-09-11 11:44:20: — Executing: Blacklist —
Thu 2014-09-11 11:44:20: — Executing: Tarpitting —
Thu 2014-09-11 11:44:20: — Executing: Relaying Denied —
Thu 2014-09-11 11:44:20: — Executing: Invalid Recipient —
Thu 2014-09-11 11:44:20: — Executing: Validate Local Sender —
Thu 2014-09-11 11:44:20: — Executing: DNS Blacklists (client IP) —
Thu 2014-09-11 11:44:20: — Executing: SPF —
Thu 2014-09-11 11:44:20: –> 250 <mike@robobak.ca>, Recipient ok
What’s next?
Now that we have the User Verification Source configured, email should now be able to flow through SecurityGateway to Exchange, but what about email sent from Exchange users that are going to external recipients? You could configure Exchange to send this email directly but there are benefits to having Exchange let SecurityGateway do the final delivery of emails.
- all outbound delivery of emails is now logged by SecurityGateway. Diagnosing delivery failures are easy using SecurityGateway’s comprehensible and searchable logs. Right from a browser!
- BackScatter Protection can be applied to all outbound emails. In a nutshell BackScatter Protection prevents unwanted bounce emails from being received by your users for emails they did not send in the first place. A more detailed explanation of BackScatter Protection can be found here.
- DKIM (DomainKeys Identified Mail) signing. Why not allow SecurityGateway to do the work of signing emails with DKIM. Let Exchange handle requests from users.
- outbound virus protection. SecurityGateway will AV scan all outgoing emails. Not just inbound ones!
- outbound data leak prevention, which uses an industry standard Sieve filtering language, allows administrators the flexibility to customize the flow of outbound email – to prevent the sending of unauthorized content and attachments.
Follow these steps to configure Exchange 2013 to send all outbound email through SecurityGateway assuming the IP address of the server running SecurityGateway is 192.168.0.1.
- Login to the Exchange Admin Centre as an Administrator (i.e. https://mydomain.com/ecp).
- Select “mail flow” on the left hand side and then click “send connectors” at the top.
- Click the “+” icon to add a new send connector.
- Name the connector SecurityGateway and select “Custom” under Type:. Click Next.
- Select the radio button option “Route mail through smart hosts” and click the “+” icon to add a new entry. Using my example here I would enter the IP address of the server running SecurityGateway which is 192.168.0.1. Replace with the IP address of your own SecurityGateway server. Click Save and then Next.
- For “Smart host authentication” leave it set at “None”. Click Next.
- The next option to configure is the “Address space” which simply means we can configure Exchange to only use the smart host when sending emails to specific domains. Although in our case we want all email to be sent to the smart host. Click the “+” icon to create a new entry. “Types” should be set to SMTP. In the “Full Qualified Domain Name (FQDN)” field enter a * (SHIFT + 8). The * is a wild card that indicates all domains. Leave the “Cost” at 1. Click Save and then Next.
- Now we need to select which server to associate this connector with. Click the “+” icon, select your server, click the “add ->” button, and then OK. Click the Finish button to complete the configuration of the send connector.
- You’re done!
***Please note that we don’t support any Exchange configurations. This information is given as a general guide line only.
Won’t SecurityGateway be filtering email from my Exchange users with the same scrutiny as external email?
No. We generally have 3 types of exclusions. We can exclude senders we white list (IPs, host names, and email addresses), and another is excluding authenticated sessions. The one we’re most concerned with here is the exclusion “Exclude messages from domain mail servers“. Exchange in this case would be a “domain mail server”. If you click through SecurityGateway’s security options you’ll notice domain mail servers are exempt from most security lookups but not antivirus filtering! So SecurityGateway knows email is from a “domain mail server” based on the IP address the connection is coming from.
During the installation of SecurityGateway we needed to define a domain and enter where the “domain mail server” is located. If you entered something incorrectly no worries! We can edit this information at any time. Click the Setup/Users button in the bottom left hand corner and then click “Domain Mail Servers” under the Mail Configuration sub menu. Edit your entry and take note if the information in the “Hostname or IP” field is correct. This is how SecurityGateway identifies the back end email server.
This is the end of Part II. You should now have a SecurityGateway server that accepts email and sends it over to Exchange. Also email from Exchange users sent to external locations will now pass through SecurityGateway.
Please stay tuned for Part III the final installment of our Getting Started with SecurityGateway series where we’ll go over and briefly explain the security features we have at our disposal.
If you have any questions please send us an email to support@ccsoftware.ca.
