TLS1.1 + support for legacy CommuniGate versions
The mail server CommuniGate Pro is well known and popular in Russia. This is a really productive and very functional mail server (now, however, VOIP / Messanger / etc already). However, he also has flaws. Closed code and significantly expensive license. It limits not only the number of users, but the update time. Unfortunately, by no means in all situations the purchase of an updated license is possible or expedient. However, the Internet is changing, vulnerabilities are found in protocols, support for old protocols is being canceled, and we also have to somehow live with it.
The task is to enable legacy users to send mail with authorization and support for TLS1.1 / TLS1.2, without making any major architectural changes to the existing system. Under cat add support for TLS1.1 + for older versions <5.1.3 СommuniGate using Postfix and LDAP.
One of our clients addressed the problem of the inability to send mail through google apps, using the data in it to access our old smtp. In our logs, errors like:
During the diagnostic process, it turned out that when establishing an encrypted connection, the google server refused to establish a session using SSL3 / TLS1.0 and tried to use TLS1.1.
The servers have CommuniGate of the old version (already 4.1.8) that does not support TLS1.1. It is part of the old (from all sides Outdated and Deprecated) system, which itself is not updated and has already received an assistant in the form of an external postfix for the incoming stream (spf / antispam) and outgoing (dkim / etc.).
At first, the nginx option was considered as a frontend (first, smtp, then pop3 / imap), which supports the latest version of TLS and transparently transfers requests to the old server, but it turned out that it does not support proxying smtp authorization, but will do it yourself and require additional scripts to add authorization. The situation was further complicated by the fact that there were several backend servers. As a result, an easier option to configure was found without the need for programming.
The good news was that CommuniGate even in older versions out of the box supports LDAP. As a result, the already partially used postfix was selected for the front-end role, which can also provide smtp authorization through the SASL module. The Dovecot server www.dovecot.org was selected as the SASL + LDAP layer .. Using additional components of the imap server seems to be an overcomplication, but the charm of dovecot is its modularity. You can disable everything in it (imap / pop3 / ssl / lmtp / sieve modules, support for postgresql / mysql / sqlite, etc.) and leave only the necessary minimum, namely the dovecot-auth authorization daemon and LDAP support that we need. Which we will do.
So.
Minimum configuration for Postfix + SASL :
/etc/postfix/main.cf
Dovecot configuration
Note that all LDAP servers could be specified in one file
But in this setup, it is assumed that each LDAP server owns information about all users and the check will go only until the first error. In the next version, user verification will be performed on all servers.
Doveconf output
And the LDAP connection configuration file by template
Remark on LDAP configuration
(Information on the CommuniGate LDAP module is searched and located both offsite, for the latest version,
www.communigate.com/communigatepro/LDAP.html
and for a specific version as part of the running server
https://mail.domain.com : 8010 / Guide / LDAP.html
Setting nuances dovecot + ldap
wiki2.dovecot.org/AuthDatabase/LDAP
The scheme “uid =% n, cn =% d” and the like did not work, but
auth_bind_userdn =% u worked, an
option was selected in where dovecot is not granted special privileges, but it just tries to log in with the received login and password on the CommuniGate server. The minus in speed, plus security, there is no need gence in extra rights.
the CommuniGate Configuration
You can make changes through Settings-> Access-> Serving LDAP Clients, or you can simply add the LDAP.settings file and restart CommuniGate.
LDAP support for accepted mail domains must be enabled, in our version this is the default.
After rebooting the mail daemons, we test authorization.
In the dovecot log when the auth_verbose = yes option is enabled, we see:
Users are happy, the amount of entropy in the world is slightly reduced :)
The task is to enable legacy users to send mail with authorization and support for TLS1.1 / TLS1.2, without making any major architectural changes to the existing system. Under cat add support for TLS1.1 + for older versions <5.1.3 СommuniGate using Postfix and LDAP.
One of our clients addressed the problem of the inability to send mail through google apps, using the data in it to access our old smtp. In our logs, errors like:
SMTPI-00139([x.x.x.x]) failed to accept a secure connection on [x.x.x.x] from [x.x.x.x]. Error Code=TLS 'client-hello' format error
During the diagnostic process, it turned out that when establishing an encrypted connection, the google server refused to establish a session using SSL3 / TLS1.0 and tried to use TLS1.1.
The servers have CommuniGate of the old version (already 4.1.8) that does not support TLS1.1. It is part of the old (from all sides Outdated and Deprecated) system, which itself is not updated and has already received an assistant in the form of an external postfix for the incoming stream (spf / antispam) and outgoing (dkim / etc.).
At first, the nginx option was considered as a frontend (first, smtp, then pop3 / imap), which supports the latest version of TLS and transparently transfers requests to the old server, but it turned out that it does not support proxying smtp authorization, but will do it yourself and require additional scripts to add authorization. The situation was further complicated by the fact that there were several backend servers. As a result, an easier option to configure was found without the need for programming.
The good news was that CommuniGate even in older versions out of the box supports LDAP. As a result, the already partially used postfix was selected for the front-end role, which can also provide smtp authorization through the SASL module. The Dovecot server www.dovecot.org was selected as the SASL + LDAP layer .. Using additional components of the imap server seems to be an overcomplication, but the charm of dovecot is its modularity. You can disable everything in it (imap / pop3 / ssl / lmtp / sieve modules, support for postgresql / mysql / sqlite, etc.) and leave only the necessary minimum, namely the dovecot-auth authorization daemon and LDAP support that we need. Which we will do.
So.
Minimum configuration for Postfix + SASL :
/etc/postfix/main.cf
...
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_authenticated_header = yes
...
Dovecot configuration
Note that all LDAP servers could be specified in one file
hosts = mail1:3389 mail2:3389 mail3:3389
But in this setup, it is assumed that each LDAP server owns information about all users and the check will go only until the first error. In the next version, user verification will be performed on all servers.
Doveconf output
root@smtp:~# doveconf -n
# 2.1.7: /etc/dovecot/dovecot.conf
# OS: Linux 3.2.0-4-686-pae i686 Debian 7.8
auth_cache_negative_ttl = 5 mins
auth_cache_size = 10 M
auth_cache_ttl = 5 mins
auth_mechanisms = plain login cram-md5
listen = *
passdb {
args = /etc/dovecot/servers/mail1.conf
driver = ldap
}
passdb {
args = /etc/dovecot/servers/mail2.conf
driver = ldap
}
passdb {
args = /etc/dovecot/servers/mail3.conf
driver = ldap
}
service auth {
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0660
user = postfix
}
}
#ssl здесь выключен, так как сервера находятся в одной доверенной подсети
ssl = no
And the LDAP connection configuration file by template
/etc/dovecot/servers/mail1.conf
hosts = mail1:3389
debug_level = 0
auth_bind = yes
auth_bind_userdn = %u
base =
Remark on LDAP configuration
(Information on the CommuniGate LDAP module is searched and located both offsite, for the latest version,
www.communigate.com/communigatepro/LDAP.html
and for a specific version as part of the running server
https://mail.domain.com : 8010 / Guide / LDAP.html
Setting nuances dovecot + ldap
wiki2.dovecot.org/AuthDatabase/LDAP
The scheme “uid =% n, cn =% d” and the like did not work, but
auth_bind_userdn =% u worked, an
option was selected in where dovecot is not granted special privileges, but it just tries to log in with the received login and password on the CommuniGate server. The minus in speed, plus security, there is no need gence in extra rights.
the CommuniGate Configuration
You can make changes through Settings-> Access-> Serving LDAP Clients, or you can simply add the LDAP.settings file and restart CommuniGate.
/etc/CommuniGate/Settings/LDAP.settings
{
Listener = {
MaxConnectionsPerAddress = 10;
MaxInputChannels = 10;
Ports = (
{
PortNumber = 3389;
RestrictionData = "x.x.x.x";
RestrictionType = Grant;
}
);
};
LogLevel = 2;
}
LDAP support for accepted mail domains must be enabled, in our version this is the default.
After rebooting the mail daemons, we test authorization.
root@smtp:/etc/dovecot/servers# doveadm auth mail@domain.com password
passdb: mail@domain.com auth succeeded
extra fields:
user=mail@domain.com
In the dovecot log when the auth_verbose = yes option is enabled, we see:
Feb 11 17:02:35 proxy dovecot: auth: Debug: Loading modules from directory: /usr/lib/dovecot/modules/auth
Feb 11 17:02:35 proxy dovecot: auth: Debug: Loading modules from directory: /usr/lib/dovecot/modules/auth
Feb 11 17:02:35 proxy dovecot: auth: Debug: Module loaded: /usr/lib/dovecot/modules/auth/libauthdb_ldap.so
Feb 11 17:02:37 proxy dovecot: auth: Debug: auth client connected (pid=0)
Feb 11 17:02:37 proxy dovecot: auth: Debug: client in: AUTH#0111#011PLAIN#011service=doveadm#011resp=
Feb 11 17:02:37 proxy dovecot: auth: Debug: cache(mail@domain.com): miss
Feb 11 17:02:37 proxy dovecot: auth: ldap(mail@domain.com): invalid credentials
Feb 11 17:02:37 proxy dovecot: auth: Debug: cache(mail@domain.com): miss
Feb 11 17:02:37 proxy dovecot: auth: ldap(mail@domain.com): invalid credentials
Feb 11 17:02:37 proxy dovecot: auth: Debug: cache(mail@domain.com): miss
Feb 11 17:02:37 proxy dovecot: auth: ldap(mail@domain.com): invalid credentials
Feb 11 17:02:37 proxy dovecot: auth: Debug: cache(mail@domain.com): miss
Feb 11 17:02:37 proxy dovecot: auth: ldap(mail@domain.com): invalid credentials
Feb 11 17:02:37 proxy dovecot: auth: Debug: cache(mail@domain.com): miss
Feb 11 17:02:37 proxy dovecot: auth: ldap(mail@domain.com): invalid credentials
Feb 11 17:02:37 proxy dovecot: auth: Debug: cache(mail@domain.com): miss
Feb 11 17:02:37 proxy dovecot: auth: ldap(mail@domain.com): invalid credentials
Feb 11 17:02:37 proxy dovecot: auth: Debug: cache(mail@domain.com): miss
Feb 11 17:02:37 proxy dovecot: auth: Debug: client out: OK#0111#011user=mail@domain.com
Users are happy, the amount of entropy in the world is slightly reduced :)