TLS1.1 + support for legacy CommuniGate versions
The CommuniGate Pro mail server is quite well known and popular in Russia. This is really a productive and very functional mail server (now, however, already VOIP / Messanger / etc). However, he also has flaws. Closed code and perceptibly expensive license. It limits not only the number of users, but the time of updates. Unfortunately, not in all situations the purchase of an updated license is possible or expedient. However, the Internet is changing, vulnerabilities are found in the protocols, the support of the old protocols is canceled, and with this, too, we must somehow live.
The task is to enable legacy users to send mail with authorization and support for TLS1.1 / TLS1.2, without making any serious architectural changes to the existing system. Under the cat, add support for TLS1.1 + for older versions <5.1.3 of CommuniGate using Postfix and LDAP.
One of our clients addressed the problem of not being able to send mail through google apps, using the data in it to access our old smtp. In our journals errors like:
')
During the diagnostic process, it turned out that when establishing an encrypted connection, google servers refused to establish a session using SSL3 / TLS1.0 and tried to use TLS1.1.
On servers there is CommuniGate of the old version (already 4.1.8), not supporting TLS1.1. It is part of the old (from all sides Outdated and Deprecated) system, which is not updated by itself and has already received an assistant as external postfix for the incoming flow (spf / antispam) and outgoing (dkim / etc.).
First, the nginx variant was used as a frontend (smtp first, then pop3 / imap), which supports the latest TLS version and transparently transmits requests to the old server, but it turned out that it does not support smtp authorization, but executes it itself and additional scripts are needed for authorization The situation was complicated by the fact that there were several backend servers. The result was found more simple to configure option without the need for programming.
The best news was that CommuniGate even supports out-of-the-box LDAP support in older versions. In the end, the partially used postfix was selected for the frontend role, which can also provide smtp authorization through the SASL module. The Dovecot server www.dovecot.org was chosen as the SASL + LDAP interlayer. The use of additional components of the imap server seems to be an excessive complication, but the beauty of dovecot is its modularity. It can disable everything (imap / pop3 / ssl / lmtp / sieve modules, postgresql / mysql / sqlite support, etc.) and leave only the necessary minimum, namely, the required authorization dovecot-auth daemon and LDAP support. What we will do.
So.
Minimal configuration for Postfix + SASL :
/etc/postfix/main.cf
Dovecot configuration
Note that all the LDAP servers could be specified in one file.
But in this configuration, it is assumed that each LDAP server owns information about all users and the check will go only to the first error. In the next version, user verification will be performed on all servers.
Doveconf output
And the LDAP connection setup file by pattern.
LDAP Tuning Wizard
(Information on the CommuniGate LDAP module is searched and located on the offsite for the latest version,
www.communigate.com/communigatepro/LDAP.html
and for a specific version of the server in progress
https://mail.domain.com:8010/Guide/LDAP.html
Nuances of dovecot + ldap settings
wiki2.dovecot.org/AuthDatabase/LDAP
The scheme “uid =% n, cn =% d” and the like did not work, but it worked
auth_bind_userdn =% u
An option was chosen in which dovecot is not granted special privileges, and he is simply trying to log in with the received login and password on the CommuniGate server. Minus in speed, plus security, there is no need for unnecessary rights.
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 restarting the mail daemons, we are testing authorization.
In the dovecot log when the auth_verbose = yes option is on, we see:
Users are happy, the amount of entropy in the world has decreased a little :)
The task is to enable legacy users to send mail with authorization and support for TLS1.1 / TLS1.2, without making any serious architectural changes to the existing system. Under the cat, add support for TLS1.1 + for older versions <5.1.3 of CommuniGate using Postfix and LDAP.
One of our clients addressed the problem of not being able to send mail through google apps, using the data in it to access our old smtp. In our journals errors like:
SMTPI-00139([xxxx]) failed to accept a secure connection on [xxxx] from [xxxx]. Error Code=TLS 'client-hello' format error ')
During the diagnostic process, it turned out that when establishing an encrypted connection, google servers refused to establish a session using SSL3 / TLS1.0 and tried to use TLS1.1.
On servers there is CommuniGate of the old version (already 4.1.8), not supporting TLS1.1. It is part of the old (from all sides Outdated and Deprecated) system, which is not updated by itself and has already received an assistant as external postfix for the incoming flow (spf / antispam) and outgoing (dkim / etc.).
First, the nginx variant was used as a frontend (smtp first, then pop3 / imap), which supports the latest TLS version and transparently transmits requests to the old server, but it turned out that it does not support smtp authorization, but executes it itself and additional scripts are needed for authorization The situation was complicated by the fact that there were several backend servers. The result was found more simple to configure option without the need for programming.
The best news was that CommuniGate even supports out-of-the-box LDAP support in older versions. In the end, the partially used postfix was selected for the frontend role, which can also provide smtp authorization through the SASL module. The Dovecot server www.dovecot.org was chosen as the SASL + LDAP interlayer. The use of additional components of the imap server seems to be an excessive complication, but the beauty of dovecot is its modularity. It can disable everything (imap / pop3 / ssl / lmtp / sieve modules, postgresql / mysql / sqlite support, etc.) and leave only the necessary minimum, namely, the required authorization dovecot-auth daemon and LDAP support. What we will do.
So.
Minimal 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 the LDAP servers could be specified in one file.
hosts = mail1:3389 mail2:3389 mail3:3389 But in this configuration, it is assumed that each LDAP server owns information about all users and the check will go only to 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 setup file by pattern.
/etc/dovecot/servers/mail1.conf hosts = mail1:3389 debug_level = 0 auth_bind = yes auth_bind_userdn = %u base = LDAP Tuning Wizard
(Information on the CommuniGate LDAP module is searched and located on the offsite for the latest version,
www.communigate.com/communigatepro/LDAP.html
and for a specific version of the server in progress
https://mail.domain.com:8010/Guide/LDAP.html
Nuances of dovecot + ldap settings
wiki2.dovecot.org/AuthDatabase/LDAP
The scheme “uid =% n, cn =% d” and the like did not work, but it worked
auth_bind_userdn =% u
An option was chosen in which dovecot is not granted special privileges, and he is simply trying to log in with the received login and password on the CommuniGate server. Minus in speed, plus security, there is no need for unnecessary rights.
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 = "xxxx"; RestrictionType = Grant; } ); }; LogLevel = 2; } LDAP support for accepted mail domains must be enabled, in our version this is the default.
After restarting the mail daemons, we are testing 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 on, 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=<hidden> 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 has decreased a little :)
Source: https://habr.com/ru/post/250767/
All Articles