LDAPS for Microsoft Exchange
Notice¶
Starting from sometime in March of 2020, Microsoft is enforcing encryption for LDAP connections on all recent versions of Exchange:
Warning¶
If you are currently using LDAP without SSL for MailCleaner and any other purposes, it is possible that communication will break if you disable non-SSL communication prior to migrating all clients needed. Before proceeding, you should ensure that you enable SSL communication to Active Directory in addition to leaving regular non-SSL communication enabled. Only after you have confirmed that all MailCleaner domain and all of your other network dependencies on Active Directory have successfully migrated should you disable non-SSL LDAP (port 389).
Access¶
Once you have confirmed that the LDAPS service is listening, you will need to ensure that MailCleaner is able to actually reach the service. This specifically means ensuring that it is willing to accept port 636 connections from MailCleaner.
If you are confident that the port is available, skip to the next section.
If you use MailCleaner Cloud, the server needs to be available from our two ranges of IPs: 195.176.194.0/24 and 193.246.63.0/24. If you would like to verify this configuration you can request that our staff run the following test for you.
If you are using a MailCleaner Virtual Appliance,telnet allows you to open a connection to the host and port of your choice. A test will look like:
telnet your.ldaps.server 636 Trying 1.1.1.1... Connected to your.ldaps.server. Escape character is '^]'.
The result shown here is a successful connection. You can simply enter quit to disconnect. If the command hangs on Trying 1.1.1.1... then it appears that MailCleaner cannot reach your server on that port.
If this test does not succeed you may need to make adjustments to the Access Control List for Active Directory or check for a rule on your firewall.
Updating Existing Domains¶
Below are the instructions for configuring MailCleaner once you are sure that the LDAPS service is available.
If you are a Virtual Appliance user with a large number of domains and are not sure which are currently using LDAP, you can quickly get a list querying the database. To open the database connection, connect to the master database with:
$ mc_mysql -m mc_config
then run the query:
select d.name, p.auth_server from domain_pref as p join domain as d on p.id=d.prefs where p.address_fetcher = 'ldap' and (p.auth_server not like '%:636' or (p.auth_param not like '%:1:1' and p.auth_param not like '%:1:2' and p.auth_param not like '%:1:3'));
This will show you all domains that are set to use LDAP but which either do not have "enable SSL" checked, or are using a port other than 636. You must be careful if you have domains that do not use Exchange, as some of the results listed may not be required or capable of changing to use SSL.
Address Verification¶
Configured from:
Configuration->Domains->(select Domain)->Address verification
The default method for address verification for newly created domains is an SMTP Callout, so it is possible that you may not need to make any adjustments.
However, in most versions of Exchange, SMTP Callouts do not work by default unless the DBEB (Directory Based Edge-Blocking) feature is enabled, so it is very possible that domains using Exchange have been set up with LDAP instead.
If you do have the "Callout connector" option on the "Address verification" page set to "ldap" you will need to ensure that:
- The "LDAP server" destination defines the correct port, like:
- 1.1.1.1:636
- remote.mydomain.com:636
- "Use ssl" is enabled
With these settings in place, you can submit, then use the "Test configuration" to ensure that LDAPS is both available and provides the expected reply for valid and invalid addresses.
User Authentication¶
Configured from:
Configuration->Domains->(select Domain)->User authentication
By default, there is no User Authentication method configured for new domains, so it is possible that you may currently have User Authentication enabled at all, or you could be using an alternative method such as IMAP.
Similar to Address verification, if you are using "ldap/Active Directory" as the "Authentication type" you will need to ensure that:
- The "Authentication server" destination defines the correct port, like:
- 1.1.1.1:636
- remote.mydomain.com:636
- "Use ssl" is enabled
With these settings in place, you can submit, then use the "Test configuration" with a valid set of credentials to ensure that LDAPS configuration will allow users to log in.
New Configurations¶
If you have never configured LDAP(S) for your domain(s), you may not be familiar with the settings required for the other fields. It is difficult to say exactly what settings you will require, since this varies by tenant and Active Directory version. Here are some general guidelines:
Address Verification¶
LDAP server: remote.mydomain.com:636 // The host and port running the LDAPS service Base DN: DC=mydomain,DC=com // Distinguished Name; the reference to the domain within the directory Bind user: mailcleaner // A user account within the directory for MailCleaner to log in with; no special privileges needed; password should never expire Bind password: p@ssw0rd // The password for the Bind User Use ssl: Checked // Only addresses in group: [blank] // Restrict inbound email to only specific groups; probably leave blank
User Authentication¶
Authentication server: remote.mydomain.com:636 // The host and port running the LDAPS service Base DN: DC=mydomain,DC=com // Distinguished Name; the reference to the domain within the directory Bind user: mailcleaner // A user account within the directory for MailCleaner to log in with; no special privileges needed; password should never expire Bind password: p@ssw0rd // The password for the Bind User User attribute: sAMAccountName // The attribute used to match the authentication username; usually sAMAccountName, proxyAddresses, or mail Use SSL: Checked // Whether or not the port is encrypted; required for LDAPS Protocol version: 3 // Version 2 is largely discontinued, you almost definitely want 3 Username modifier: add the domain using @ character // How to look up the modifier to match the attribute; eg. sAMAccountName probably has no domain, proxyAddresses has the domain with an @ Address lookup: fetch address(es) from ldap directory // How to determine which addresses the user should have access to
Useful links
https://youtu.be/JFPa_uY8NhY (How to configure and test LDAPs on 2012 Server)
Sample configuration from our demo.mailcleaner.net server: see following picture
