CommuniGate Pro
Version 6.4
 

Security

The CommuniGate Pro Server ensures that only certain users are allowed to access certain resources.

The CommuniGate Pro Server can authenticate its users, and it can also reject connections from outside of the "client networks".

Authentication Methods

The CommuniGate Pro Server supports both clear-text and secure SASL authentication methods for the following TCP-based session-oriented protocols:

  • POP (as specified in RFC1734)
  • IMAP (as specified in RFC2060)
  • LDAP (as specified in RFC2251)
  • ACAP (as specified in RFC2244)
  • SMTP (as specified in RFC2554)
  • FTP (as specified in RFC2228)
  • XMPP (as specified in RFC3920)

These secure methods allow mail clients to send encrypted passwords over non-encrypted and insecure links. If anybody can monitor your network traffic, SASL methods ensure that the real passwords cannot be detected by watching the client-server network traffic.

As an alternative to SASL methods, secure links (SSL/TLS) can be used between the client mailer and the server. When an SSL link is established, the entire network traffic between the server and the client is encrypted, and passwords can be sent in clear text over these secure links.

You can force an Account user to use either a SASL authentication method or SSL/TLS links if you enable the Secure Method Required option in the Account Settings. When this option is enabled, the Server rejects all authentication requests that send passwords in the clear text format over insecure links.

The CommuniGate Pro Server supports the following insecure (clear text) SASL authentication methods:

  • PLAIN
  • LOGIN

The CommuniGate Pro Server supports the following secure SASL authentication methods:

  • CRAM-MD5
  • DIGEST-MD5
  • GSSAPI

The CommuniGate Pro Server supports the following GSSAPI authentication methods:

  • Kerberos V5
  • NTLM

The CommuniGate Pro Server supports the following SASL-EXTERNAL authentication methods:

  • TLS-Certificate

The CommuniGate Pro Server supports the non-standard NTLM and MSN SASL methods used in Microsoft® products.

The CommuniGate Pro supports the secure APOP authentication method (used mostly for the POP protocol), and the insecure "regular login" method for the protocols that support Clear Text Login.

The CommuniGate Pro Server supports the special SessionID Authentication method.

Use the WebAdmin Interface to open a Domain Settings page and find the Login Methods panel:

Login Methods
CLRTXT CRAM-MD5 DIGEST-MD5 APOP
GSSAPI NTLM MSN SESSIONID
CLRTXT
When this option is selected, the Server advertises all supported non-secure (clear text) authentication methods for this Domain.
CRAM-MD5, DIGEST-MD5
When these options are selected, the Server advertises the secure CRAM-MD5 and DIGEST-MD5 authentication methods for this Domain.
Do not select these options if the Domain Accounts use one-way encrypted passwords, Authentication URI, or other authentication methods that do not support secure authentication methods.
APOP
When this option is selected, the Server provides a special initial prompt for POP and PWD connections. Mail clients can use this prompt to employ the secure APOP authentication method.
Do not select this option if the Domain Accounts use one-way encrypted passwords, Authentication URI, or other authentication methods that do not support secure authentication methods.
GSSAPI
When this option is selected, the Server advertises support for the GSSAPI authentication method.
Do not select this option if the Domain is not set to support GSSAPI methods (for example, you have not specified the required Kerberos Keys).
MSN, NTLM
When these options are selected, the Server advertises the non-standard MSN and NTLM authentication methods (used in some Microsoft products) for this Domain.
Do not select these options if the Domain Accounts use one-way encrypted passwords, Authentication URI, or other authentication methods that do not support secure authentication methods.
Note: The Microsoft Outlook products for various versions of MacOS do not work correctly with the MSN method if more that one account is configured in those products.
Note: Some Microsoft products send incorrect credentials when they detect that the server supports the NTLM SASL method. While those products then resend the correct credentials, the failed login attempts produce Failure-level Log records and may increase the "failed logins" counter too quickly, so the account becomes "temporarily locked".

The Advertise options control only the session-type services (SMTP, POP, IMAP, ACAP, PWD, FTP), and they do not have any effect on the transaction-type services (HTTP, SIP).
The Advertise options control only how the methods are advertised. Client applications can still use all these methods, even if these options are switched off.

SESSIONID
This option enables the SessionID Authentication method for the Domain.

Account Passwords

The CommuniGate Pro Server supports several passwords for each account.

One password is the CommuniGate Pro's "own password ". This password is stored as an element of the Account Settings, and it can be used with the CommuniGate Pro Server only.

Additional variants of CommuniGate Pro internal password can be specified with tag names. When authenticating with these tagged passwords the authenticating client application should specify the password tag after account name separated with $ symbol: user$tag.

An account can have the Authentication URI specified that is used to authenticate to an external LDAP server. This method works only with Clear Text authentication methods.

An account can have the External Password option enabled. In this case, user authentication is done using any custom authentication program running as a separate process (see below).

The system administrator can enable any set of passwords for any user account. On larger sites, it is better to enable these options using the Server-wide or Domain-wide Default Account Settings.

When several passwords are enabled for an account, the Server first checks the CommuniGate (internal) password, then Authentication URI if not empty, and then tries to use the External Authentication program. If at least one of these passwords matches the password presented with the client application, the application is granted access to that account.


CommuniGate Passwords

CommuniGate passwords are strings stored in the Account Settings. Password strings can be stored in the clear-text format or in encoded format. The Password Encryption Account Setting specifies the encryption to use when the account password is updated. When this setting is changed, the currently stored password is not re-encrypted.

When the U-crpt Password Encryption option is selected, the CommuniGate passwords are stored using the standard Unix crypt routine. If the UB-crpt Password Encryption option is selected, an enhanced Blowfish-based encryption is used.
U-crpt and UB-crpt methods implement a one-way encryption. As a result, the Server cannot decrypt them into their original (clear text) form, and it cannot use them for secure (SASL) Authentication Methods. Use these encryption methods only if you need compatibility with legacy password strings - it is usually more important to support "on-the-wire" security (using SASL methods), rather then "on-the-disk" security (using one-way password encryption methods).

U-crpt passwords can contain special prefixes. These prefixes allow you to import passwords encrypted using other password encryption methods.
See the Migration section for more details.

Note: please remember that the plain Unix crypt routine uses only the first 8 symbols of the password string.

If the CommuniGate Password is absent or empty, it cannot be used to log into the Account even if the Use CommuniGate Password option is enabled. But if the user has logged in using the External Authentication method, the user can specify (update) the Account CommuniGate Password. This feature can be used to migrate users from legacy mail systems where you can not compose the list of accounts with their non-encrypted (plain text) user passwords.


Kerberos Authentication

The CommuniGate Pro Server supports the Kerberos authentication method. The Kerberos method is based on "tickets". Client applications use these tickets to authenticate access to a service, provided by server. The tickets are encrypted with "key" and are issued by Key Distribution Centers (KDC), that share the key with the Server. For more details, please refer to the Kerberos documentation.

To support Kerberos Authentication for users of a CommuniGate Pro domain, you need to add Kerberos Server key(s) for that domain.

1) In the KDC database create a "principal" for the CommuniGate Pro server service (protocol) to authenticate the access with Kerberos. For the principal name components use the following values:

  • For "primary" specify the name of the CommuniGate Pro service (protocol). Normally, protocol names are specified in lowercase like smtp, imap, but there's the exception for the HTTP protocol that is specified in uppercase: HTTP.
  • For "instance" specify the hostname used to connect to the CommuniGate Pro domain. This name must match the name of the CommuniGate Pro domain or one of its Domain Aliases.
  • For "realm" specify the name of the Directory Service domain to authenticate to in uppercase.

2) Export the principal key into a key table file ("keytab").

3) Open the Domain Settings using the CommuniGate Pro WebAdmin Interface, and follow the Security and Kerberos links. The list of Domain Kerberos Keys will be displayed:

  Realm Issued Version Type
REALM1.COM(3)imap/domain1.com19-05-2021 17:36:336RC4-HMAC
REALM1.COM(3)imap/domain1.com21-05-2021 17:32:359DES-MD5
REALM1.COM(3)imap/domain1.com24-05-2021 12:41:5510DES-MD5
REALM1.COM(3)imap/domain1.com24-05-2021 17:33:2713DES-CRC32
  

Each Domain can have several Kerberos Keys. To add Keys from the file to the set of the Domain Kerberos Keys, click the browser file-select button (…), select the keytab file and click the Import Keys button.

To remove Keys, mark the Keys using checkboxes and click the Delete Marked button.

Domain Administrators can Add or Remove Kerberos Keys only if they have the KerberosKeys Access Right.

When the Server receives a Kerberos Ticket, it extracts the instance from the service principal name, indicated in the Ticket. The instance is used as the target Domain name (ticket-domain-name). The Server then builds a fictitious E-mail address LoginPage@ticket-domain-name and tries to route this address. This is the same mechanism, as the one used for finding the target Domain during HTTP access.

If the target Domain is found, the Server looks in the list of the Kerberos Keys for that Domain for the proper key (the key, for which service principal name and encryption type match those specified in the ticket). If the Key is found, and the Ticket can be decrypted with that Key; the Authenticator can be decrypted with the extracted session key and the authentication data is valid, the Server extracts the primary from the user principal name. The primary is used as the target Account name. That name must be a "simple" name, i.e. it cannot contain @ or % symbols.

The server adds the target Domain name to the target Account name and tries to route the obtained address.

If the Account is found, and the Kerberos Authentication method is enabled for that account, the Server grants access to the Account resources.

Integrating with Microsoft Active Directory

Microsoft Active Directory can be used to authenticate users of a CommuniGate Pro domain with Kerberos. Follow these steps:

  • In the DNS-zone of the Active Directory domain create an A-record pointing to the IP-address of the CommuniGate Pro domain.
  • Add full hostname (FQDN) specified in the A-record to the CommuniGate Pro domain aliases.
  • In the Active Directory domain create a user with the name cgatepro (you may want to use a different name).
  • On the Active Directory domain controller use the ktpass command to configure the Service Principal Name and to export the key:
  • ktpass -princ service/hostName@REALMNAME -mapuser cgatepro -pass key -out keytab.data -crypto encType -ptype KRB5_NT_SRV_HST
    where
    service
    is the name of the CommuniGate Pro service (protocol): imap for IMAP and MAPI, smtp for SMTP, HTTP for web-interfaces
    hostName
    is the full hostname used to connect to the CommuniGate Pro domain
    Note: the same name should be used in client applications
    REALMNAME
    is the full name of the Active Directory domain in uppercase
    key
    is the encryption key
    encType
    is the encryption type
    Example:
    ktpass -princ imap/cgpro.ad-domain.dom@AD-DOMAIN.DOM -mapuser cgatepro -pass 12345678 -out imap.data -crypto All -ptype KRB5_NT_PRINCIPAL
    For more details, please refer to the ktpass documentation.
  • Import the resulting keytab file into the CommuniGate Pro Domain Kerberos settings, as specified above.

Integrating with FreeIPA

FreeIPA can be used to authenticate users of a CommuniGate Pro domain with Kerberos. Follow these steps:

  • In FreeIPA create a host with the IP-address of the CommuniGate Pro domain.
  • Add full hostname (FQDN) to the CommuniGate Pro domain aliases.
  • For the host add the service, corresponding to the CommuniGate Pro service (protocol), or add the principal alias.
  • Use the ipa-getkeytab command to export the key:
  • ipa-getkeytab -s FreeIPA-hostName -p service/CGPro-hostName -e encType -k keytab.data -P
    where
    FreeIPA-hostName
    is the full hostname of the FreeIPA host
    service
    is the name of the CommuniGate Pro service (protocol): imap for IMAP and MAPI, smtp for SMTP, HTTP for web-interfaces
    CGPro-hostName
    is the full hostname used to connect to the CommuniGate Pro domain
    Note: the same name should be used in client applications
    encType
    encryption type
    Example:
    ipa-getkeytab -s freeipa.ipadom.dom -p imap/cgpro.ipadom.dom -e arcfour-hmac -k imap.data -P
    For more details, please refer to the ipa-getkeytab documentation.
  • Import the resulting keytab file into the CommuniGate Pro Domain Kerberos settings, as specified above.

LDAP Authentication

The CommuniGate Pro Server supports the LDAP URI authentication method when the URI has the form ldap(s)://address[:port]/parameters. This method is based on the LDAP protocol BIND request being sent to an external LDAP server accessible at address[:port] with authentication DN built from the parameters part of the URI and the password as received in the access protocol request being authenticated. In this scenario only the clear text authentication methods are supported between CommuniGate Pro and the connecting client. If the External LDAP server answers positively to the BIND request with BIND DN built from the parameters part, then the user can log into the Account.

The asterisk (*) symbol is substituted in the parameters part of the URI with the CommuniGate Pro Account name, the ^0 is substituted with the CommuniGate Pro Domain name.

Note: for Microsoft Active Directory LDAP server as parameters instead of DN you can use DOMAIN\account or account@domain.dom where DOMAIN is the short Windows domain name, domain.dom is the full Windows domain name, and account is the value of sAMAccountName attribute of the account record in the Active Directory.

Examples:
ldap://10.0.0.2:389/*@^0
ldaps://dc.ad-domain.dom:636/*@ad-domain.dom
ldap://10.0.0.2:389/AD-DOMAIN\*

Certificate Authentication

The CommuniGate Pro Server supports the Client Certificate authentication method. This method can be used when clients connect to the Server via secure SSL/TLS connections. The Server may request a client to send a Client Certificate (installed on the client computer), signed with the Trusted Certificate selected on the Server for the target Domain.

If a client sends such a Certificate, the E-mail address specified in the Certificate subjectAltName element (if any) or in the Subject element E-mail field can be used for the Certificate-based Authentication. It is interpreted as the name of the CommuniGate Pro Account to log into.

Note: after the supplied E-mail address is processed with the Router, it checks that the target Account belongs to the same Domain as the Domain the used to verify the supplied Certificate, so Administrators of one Domain cannot create Certificates allowing users to access Accounts in other CommuniGate Pro Domains.

Only Accounts with enabled Certificate Authentication method can be accessed using Client Certificates.

See the PKI section for more details.


External Authentication

The CommuniGate Pro Server can use an external Helper program for user authentication. That program should be created by your own technical staff and it can implement authentication mechanisms required at your site but not supported directly with the CommuniGate Pro Server.

The External Authenticator can also be used:

  • to automatically provision Accounts based on some external data source
  • to assist with the Router operations
  • to assist with Account provisioning.

The External Authenticator program name and its optional parameters should be specified using the WebAdmin Helpers page. Open the General page in the Settings realm, and click the Helpers link:

External Authentication
Log Level: Program Path:
Time-out: Auto-Restart:

See the Helper Programs section to learn about these options.

The External Authentication module System Log records are marked with the EXTAUTH tag.

If the External Authentication program is not running, all External Authentication requests are rejected.

To create your own External Authentication program, see the Helper Applications section to learn about the External Authentication interface protocol.

Sample External Authentication programs and scripts can be found at the Authentication Helpers site.


Account Name Harvesting

Some spammers use 'brute force' attacks on mail systems, sending random names and passwords to system POP, IMAP, and other access ports. If the system sends different error messages for the "unknown account" and "incorrect password" situations, the attacker can harvest a large portion of the system Account names and then use those names for spam mailings.

Use the WebAdmin Interface to configure the Login Security options. Open the General pages in the Settings realm, and find the Login Security panel on the Others page:

Login Security
  Hide 'Account Unknown' messages
Hide Unknown Account messages
If this option is enabled, the Server does not send the Unknown Account and Incorrect Password error messages. Instead, both messages are replaced with the Incorrect Account Name or Password error message.

The CommuniGate Pro Server can temporarily disable all types of login operation for an Account that has seen too many incorrect login attempts. The Account Settings specify a time period and the number of incorrect login attempts that a user or users can make before the Account is disabled for login operations. The Account is re-enabled after the same period of time.


Granting Access Rights to Users

In order to control, monitor, and maintain the CommuniGate Pro Server, one Postmaster Account is usually enough. But you may want to allow other users to connect to the administrator interfaces of your CommuniGate Pro Server: for example, you may want to allow an operator to monitor the Logs, but you do not want to grant that operator all Postmaster access rights.

You should be logged in as the Postmaster, or other Account with the "Can Do Everything" right in order to assign Access Rights.

To grant access rights to a user and/or to revoke those rights, open that user Account (the Account Setting page), and click the Access Rights link. The Access Rights page will appear.

The page lists all Access Rights and the rights granted to the selected user are marked.

The following access rights can be granted only to the users (accounts) in the Main Domain:

Can Do Everything (the Master right)
If a user is granted this right, it has all access rights to all System components.
Can Modify Server and Module Settings (the Settings right)
This right allows a user to change configuration of all CommuniGate Pro components and modules (SMTP, POP, Router, etc.)
Can Modify Directory Settings (the Directory right)
This right allows a user to change configuration of the System Directory
Can Modify All Domains and Accounts Settings (the All Domains right)
This setting specifies if the user is allowed to create, rename and delete Domains, Accounts and other Objects, and to change Domain, Account, and other Object Settings.
Can Read All Domains and Accounts Settings (the All Domains Read right)
This setting specifies if the user is allowed to read Domain, Account, and other Object Settings.
Can Monitor (the Monitor right)
This setting specifies if the user is allowed to view Server Logs, to monitor Server Queues, etc.

The following access rights can be granted to users in any domain:

Can Modify This Domain and its Account Settings:
This setting specifies if the user is allowed to create, remove and delete Accounts within its own domain, and to change some of the Domain Settings. You usually assign this right to a user ("domain master") who will manage the Domain.

Initially, the user Postmaster in the Main Domain has the Master Access right.

Select the desired Access Rights and click the Update button.

The Access Rights are stored in a single file for each Domain, the Access.settings file stored in the Settings subdirectory of the Domain file directory. This makes it easy to check who is granted the Server Administration rights.


Impersonating

The CommuniGate Pro Server supports impersonating - a login mode when the credentials are supplied for one Account (the Authentication Account), while a different Account (the Authorization Account) is being opened.
It can also be used for Real-Time Registration.

Impersonating is supported for PLAIN and GSSAPI Authentication methods.

When Impersonating is used, the Server checks if the authentication Account credentials are valid, and if the requested service is allowed for that Account. It also checks if the Authentication Account has the CanImpersonate Domain access right.


The SessionID Authentication Method

The CommuniGate Pro Server supports the special SessionID Authentication method. This method uses the session ID of a WebUser or XIMSS session instead of the Account password.
The method is useful for CGI programs and scripts.
This method is disabled by default (see above).

The method is a SASL method and requires "immediate" parameters in the authentication protocol command. The first parameter is the Account name, the second parameter, separated with the space symbol, is the session ID.
The SESSIONID authentication operation for the PWD module is:

AUTH SESSIONID userName session-ID

The SESSIONID authentication operation for the IMAP module is:
AUTHENTICATE SESSIONID bindata
where bindata are base64-encoded parameter data:
userName session-ID

If the user john@doe.dom has an open WebUser Session with the 114-bXaKw92JK1pZVB5taj1r ID, then the PWD command:
AUTH SESSIONID john@doe.dom 114-bXaKw92JK1pZVB5taj1r
opens the john@doe.dom account in this PWD session.


Access Control Lists (ACLs)

The Account owner can grant certain rights to other users: a right to access certain Mailboxes, a right to control telephony features, etc.

Each element of the Access Control List contains a name and a set of access rights granted to that name.

An ACL element name can be:

null@null
This ACL element specifies the access rights granted to "guests" (non-authenticated users).
anyone
This ACL element specifies the access rights granted to everybody (all authenticated accounts).
anyone@
This ACL element specifies the access rights granted to all Accounts in the same CommuniGate Pro Domain.
anyone@domainName
This ACL element specifies the access rights granted to all Accounts in the CommuniGate Pro domainName Domain. The domainName should be the real Domain name, and not a Domain Alias name.
accountName
This ACL element specifies the access rights granted to the accountName Account user in the same CommuniGate Pro Domain. The accountName should be a real Account name, and not an Account Alias or a Forwarder.
accountName@domainName
This ACL element specifies the access rights granted to an Account user in a different CommuniGate Pro Domain. The domainName should be the real Domain name, and not a Domain Alias name.
#groupName
This ACL element specifies the access rights granted to all members of the groupName Group (in the same Domain).
#groupName@domainName
This ACL element specifies the access rights granted to all members of the groupName Group in a different CommuniGate Pro Domain. The domainName should be the real Domain name, and not a Domain Alias name.

An ACL element name can have a + or a - prefix.

Account owners always have all access rights to all objects (Mailboxes, functions) in their own Accounts.

For any other someaccount Account, the effective access rights are checked.

The effective access rights are calculated in several steps:
  • If there is an ACL element for the someaccount name (without a + or a - prefix), then the Access right specified in that ACL element are used as the effective access rights.
    Otherwise
  • All ACL elements without a + or a - prefix and matching the someaccount name are merged to form the "direct" access rights.
  • All ACL elements with the - prefix and matching the someaccount name are merged to form the "removed" access rights.
  • All ACL elements with the + prefix and matching the someaccount name are merged to form the "added" access rights.
  • The "removed" access rights are removed from the "direct" access rights.
  • The "added" access rights are merged with the "direct" access rights.
  • The resulting "direct" access rights are used as the effective access rights.

When granting access rights, the real Account names, not Account Aliases should be used. If an Account j.smith has two aliases john.smith and jonny, the access rights should be granted to the name j.smith.

Examples:
Grant the Lookup, Select, and Seen access rights to all users in the same Domain, excluding the user John, who should have only the Lookup right, and the user Susan who should have the Lookup, Select, Seen, and Delete rights:
anyone@ Lookup, Select, Seen
-john Select, Seen
+susan Delete
Grant the Lookup, Select, and Seen access rights to all users in a different company2.com Domain, excluding the user john@company2.com who should have no access rights, and grant the Lookup, Select, and Delete rights to the user susan in a yet another company3.com Domain.
anyone@company2.com Lookup, Select, Seen
-john@company2.com Lookup, Select, Seen
susan@company3.com Lookup, Select, Delete

The Access Control Lists can be set and modified using the WebUser Interface, a XIMSS, a MAPI, or a decent IMAP client.


CommuniGate Pro Guide. Copyright © 2020-2023, AO StalkerSoft