 |
Security |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
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:
The CommuniGate Pro Server supports the following secure SASL authentication methods:
The CommuniGate Pro Server supports the non-standard NTLM and MSN SASL methods used in Microsoft® products.
The CommuniGate Pro Server supports the following GSSAPI authentication methods:
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 WebUser authenticaton method.
Use the WebAdmin Interface to open the Obscure page in the Settings realm to switch the Advertise Secure SASL Methods, the Advertise APOP Method, the Advertise MSN SASL Method, and the Advertise NTLM SASL Method options:
Note: these 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).
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.
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.
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.
| 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 | 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.
|
| 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. |
The OS passwords are one-way-encrypted passwords. As a result, they cannot be used for Secure Authentication Methods.
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:
The 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:
See the Helper Programs section to learn the meaning of 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.
The External Authenitcator Interface protocol is based on the generic Helper Protocol.
This manual describes the External Authenitcator Interface Version 7.
When a user should be authenticated using the clear text method, the Server sends the following
command:
nnnnnn VRFY (mode) name@domain password [loginAddress]
where:
When a user should be authenticated using a secure SASL method, the following command is sent:
nnnnnn SASL(method) (mode) name@domain password key [loginAddress]
where:
If the password is accepted, the External Authernticator should return a positive response:
nnnnnn OK
If the password was not accepted, a negative response should be returned:
nnnnnn ERROR optional-error-message
If the password is accepted, and there is an authentication response to be returned to the
client, a positive response with a quoted string should be returned:
nnnnnn RETURN "authentication-response"
SASL password verification requires that the External Authenticator program correctly implements
all supported SASL methods and algorithms. Alternatively, the External Authenticator program can return
the user plain text password, making the Server verify the password and calculate necessary authentication responses.
The user plain text password should be returned as a quoted string:
nnnnnn PLAIN "plain-text-password"
Sample session (I: - server commands sent to the program standard input, O: - responses the program writes to its standard output):
The External Authentication program can be used to process unknown names, too. For example, the program can consult an external database, check if the user exists in that database, create an Account, Alias, Group, Mailing List, or Forwarder using the CommuniGate Pro CLI/API, and return a positive response to the Server. In this case, CommuniGate Pro will re-try to open a domain object with the specified name.
To check an unknown name, the Server sends the following command:
nnnnnn NEW name@domain relayType
where:
If the program sends the OK response, the Server tries to find the name object in the domain Domain again.
If the program sends the ROUTED address response, the Server takes the supplied address response and restarts the Router procedure with this address. The routed address gets a "can Relay" attribute, unless it is specified with the [NORELAY] prefix.
If the program sends the FAILURE response, the Server Router returns a "temporary internal error" code (this code causes SMTP module to return a 4xx error code, not a permanent 5xx error code).
If the program sends any other response, the Server Router returns the "unknown user account" error.
Sample session:
The Consult External Authenticator Domain Setting tells the Server to use the External Authenticator program when an unknown name is addressed.
Sample External Authentication programs and scripts can be found at the http://www.stalker.com/CGAUTH/ site.
To prevent this type of attack, you may want to enable the Hide Unknown Account messages option, located on the Obscure page in the WebAdmin Settings realm:
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 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 you should have the "Can Modify Access Rights" 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:
The following access rights can be granted to users in any domain:
Initially, the user Postmaster in the main domain has the Unlimited 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 to whom the Server administration rights are granted.
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 and access to Personal Web Sites.
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.
Note: Before you enable this option, make sure that the address you are using is included into the Client Addresses list: otherwise you will immediately lose 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 is supported for PLAN 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 WebUser SASL method works only for programs running on the same Server computer, or for programs running on other servers in the CommuniGate Pro Cluster.
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 WebUser session ID.
The WebUser authenitcaiton 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:
