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.

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, OS Passwords, 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, OS Passwords, 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, OS Passwords, 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 quicky, 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.

The other password is the "OS password". The user may be registered with the
Server OS and the CommuniGate Pro Server can check the supplied password against the
password set in the Server OS registration information for this user.

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 the OS password, 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 enchanced 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, but cannot use the OS passwords -
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
encypted 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 OS Password or 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 non-crypted user passwords.

OS Passwords

When the Server checks the OS password, it composes the username string using the
Account OS User Name setting. When the default setting
* is used, the composed OS user name is the same as the Account name. By changing the
OS User Name settings you can use different OS usernames for Accounts in different CommuniGate
Pro domains.

Server Operating System

Notes about OS Passwords

Microsoft Windows 95/98/ME

OS does not support passwords, the Use OS Password option does not work.

Microsoft Windows 200x/XP/NT/Vista

The Windows NT domain authentication system is used. The Windows account used to run the CommuniGate Pro Messaging Server
should have the Act as part of the operating system privilege.

The --BatchLogon command line option can be used to tell the Server
to use the LOGON_BATCH authentication method (if the option is not present,
the LOGON_NETWORK method is used).

The Server checks if the composed OS user name contains the percent (%) symbol.
If the symbol is found, the part of the name before that symbol is used as the Windows
account name, and the part after that symbol is used as the Windows domain name.
If Accounts in the company1.dom CommuniGate Pro domain have the OS User Name setting
set to *%comp1, then the OS user name for the CommuniGate Pro Account joe will be joe%comp1, and the
CommuniGate Pro Server will use the Windows LogonUser API to try to authenticate
the mail client as the Windows user joe in the Windows domain comp1.

Unix-based systems

The passwd and shadow or other OS-supported authentication mechanisms are used.

OS/400 systems

The user profile authentication mechanisms are used.

OpenVMS systems

The supplied user name and password strings are converted to uppercase, and then the OpenVMS authentication mechanisms are used.

BeOS

OS does not support passwords, the Use OS Password option does not work.

Kerberos Authentication

The CommuniGate Pro Server supports the Kerberos authentication method. The Kerberos
method is based on the "tickets" that client applications send to the server. These tickets
are issued by Kerberos authorities (Key Distribution Centers, KDC) that share a common "key"
with the Server. See the Kerberos documentation for the details.

To support Kerberos Authentication, you need to add Kerberos Server key(s) to the
CommuniGate Pro Server, on the per-domain basis. Create a server "principal" in your KDC database.
The principal name should be equal to the name of CommuniGate Pro Domain or one of its Domain
Aliases. Export the created key as a keytab file.

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.com

19-05-2004 17:36:33

6

RC4-HMAC

REALM1.COM

(3)imap/domain1.com

21-05-2004 17:32:35

9

DES-MD5

REALM1.COM

(3)imap/domain1.com

24-05-2004 12:41:55

10

DES-MD5

REALM1.COM

(3)imap/domain1.com

24-05-2004 17:33:27

13

DES-CRC32

Each Domain can have several Kerberos Keys. To add Keys, click the browser file-select button and select
the keytab file exported from KDC. Click the Import Keys button to add keys from the file to the
set of the Domain Kerberos Keys.

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

When the Server receives a Kerberos Ticket, it extracts the Server Name ("sname") from the Ticket.
If the Server Name has only 1 component (domain.dom), this component is used as the target Domain name (ticket-domain-name).
If the Server Name has 2 or more components (service/domain.dom), then the second component is used.
The Server then builds a fictitious E-mail address LoginPage@ticket-domain-name and tries to route this address.
This is the same routing mechanism as one used for finding the target Domain for HTTP requests.

If the target Domain is found, the Server looks for the proper key in the list of the Kerberos
Keys for that Domain. If the Key is found, and the Ticket and Authorization info can be decrypted with
that Key, the user is authenticated. The name of the Account is taken from the Client Name specified
in the Ticket. That name must be a "simple" name, i.e. it cannot contain @ or % symbols.

CommuniGate Pro adds the name of the target Domain to the retrieved user name and uses the resulting
E-mail address as the name of the Account to open.

Note: The Kerberos Authentication mechanism does NOT run the resulting user name via the Router.
If it would use the Router, a name in one Domain could be routed to a name in a different Domain, so
the Kerberos Keys valid for one Domain would provide access to Accounts in a different Domain. As a side
effect, the Account Aliases cannot be used in Kerberos tickets.

Only Accounts with enabled Kerberos Authentication method can be accessed using Kerberos tickets.

Integrating with Microsoft Active Directory

You may want to use Microsoft Active Directory as your Kerberos Key Distribution Center (KDC).
Follow these steps:

create an Active Directory account cgatepro (you may want to use a different name)

If you want to use Kerberos Authentication (Single Sign-on) with Microsoft browsers, please
read the "HTTP-Based Cross-Platform Authentication via the Negotiate Protocol" article in
the Microsoft documentation set (MSDN).

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 is
interpreted as the name of the CommuniGate Pro Account to log into.

Note: The Certificate Authentication mechanism does NOT run the provided E-mail address via the Router.
If it would use the Router, a name in one Domain could be routed to a name in a different Domain, so
the Trusted Certificates valid for one Domain would provide access to Accounts in a different Domain. As a side
effect, the Account Aliases cannot be used with the Certificate Authentication mechanism.

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

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

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

Suspend Account after

failed logins within

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.

Account Password Attacks

The CommuniGate Pro server can temporarily disable all types of login operation for an
Account that has seen too many incorrect login attempts. The Login Security panel shown above
allows you to 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 intefraces 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 Everying" 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 Everying (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 Users 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 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 one file for each domain, the Access.settings file
stored in the Settings subdirectory of the domain directory. This makes it easy to check who is granted
the Server Administration rights.

Restricting Access

If you do not plan to support mobile users, you may want to restrict access to
the Server accounts. Use the following option on the Client IP Addresses page:

Logins from Non-Client Addresses

When the "probibit" option is selected, all "login" operations
(needed for POP, IMAP, SIP, XMPP, WebUser Interface, ACAP, PWD, etc.) are
accepted only from the Server computer itself, and from the Client IP Addresses.

When an access module accepts a connection from an unlisted network address, and this
option is selected, the module sends an error code to the client application, and
the connection is closed immediately. Links with the rest of the Internet will be used
only for mail Transfer, Real-Time Signals
exchange, and for HTTP access to Account File Storage.

When this option is selected, the SMTP AUTH operation can be used only if a client
mailer or server connects from the network address included into Client Addresses list.

When this option is selected, any Signaling operation that requires authentication
can be used only if a client device or server connects from the network address included
into Client Addresses list.
Note: Before you enable this option, make sure
that the network address you are currently using is included into the Client Addresses list: otherwise
you will immediately lose HTTP Admin access to the Server.

You can also specify the access restrictions on the lower (TCP) connection level. For
each service (module), open the Listener page and specify
the addresses the service (module) should or should not accept connections from. If a connection
comes from an address that is not included into the Grant list or is included
into the Deny list, the connection is closed immediately, and no module-level
operations are performed.

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
Authorisation 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 CanImpersonateDomain access right.

The SessionID Authentication Method

The CommuniGate Pro Server supports the special SessionID Authenticaton 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:

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.