 |
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:
CommuniGate Pro Server supports the non-standard NTLM and MSN SASL methods used in Microsoft® products.
Besides, 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.
Use the WebAdmin Interface to open the Obscure page in the Settings realm to switch the Advertise Secure SASL Methods, the Advertise MSN SASL Method, and the Advertise NTLM SASL Method options:
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. Since this is a one-way encryption, such passwords cannot be used for secure (SASL) Authentication Methods. Use this option only if you need compatibility with legacy password strings, but cannot use the OS passwords.
The U-crypted passwords can have some special format, so they are recognized as MD5- and SHA1- digested passwords, not as Unix-crypted passwords. 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.
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 9x | OS does not support passwords, the Use OS Password option does not work. |
| Microsoft Windows NT/2000 | 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 any other OS-supported authentication mechanisms are used. |
| OS/400 systems | The user profile 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.
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:
When the External Authenticator option is enabled, the Server starts the specified program as a separate OS process.
The Server then sends commands to the External Authenticator process via the process standard input and reads responses from the process standard output. Each command starts with a sequence number, and the response produced with the External Authenticator process starts with the same number. This method allows the External Authenticator program to process several requests simultaneously, and it can return responses in any order.
Commands and responses are text lines, ending with the EOL symbol(s) used in the Server OS.
Note: communication between the Server and an External Authentication program takes place via OS pipes, and many programming libraries buffer output data sent to pipes. Check that your External Authentication program uses some form of the flush command after it sends its response to its standard output, otherwise the response will never reach the Server.
The Interface Version command is used to provide compatibility between different versions of External Authenticator
programs and different versions of the CommuniGate Pro server. The server sends this command specifying the protocol version
it implements:
nnnnnn INTF serverInterfaceVersion
where:
The External Authenticator program should return the OK response and the supported protocol version.
nnnnnn OK programInterfaceVersion
If the returned number is smaller than the Server protocol version, the Server will use this (older) protocol version.
This manual describes the External Authenitcator Interface Version 2.
When a user should be authenticated using the clear text method, the Server sends the following
command:
nnnnnn VRFY name@domain password
or
nnnnnn VRFY (mode) name@domain password
where:
When a user should be authenticated using a secure SASL method, the following command is sent:
nnnnnn SASL(method) name@domain password key EOL
or
nnnnnn SASL(method) (mode) name@domain password key EOL
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
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 process several requests simultaneously: it can read the next request before sending responses for all previously received requests. The program can return responses in any order, specifying the correct sequence numbers:
Sample session:
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
Sample session:
The Consult External Authenticator Domain Setting tells the Server to use the External Authenticator program when an unknown name is addressed.
When the Server shuts down or when it needs to stop the External Authentication program, it closes the process standard input. The External Authentication program detects the end-of-file condition and it should quit within 5 seconds.
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.
To specify the server SSL/TLS processing parameters, open the Obscure page in the Settings section of the WebAdmin Interface:
A server must possess a so-called "private key" and a "certificate" that contains a public key. When a client starts to establish a secure connection, the server sends its certificate to the client. The client:
The Certificates themselves use the Public Key cryptography, too. The Certificate contains the information about the server and the information about the organization or entity that has issued the Certificate. The entire Certificate is digitally signed using the Private Key of the issuer, and it is practically impossible to forge a certificate without make the digital signature invalid.
Modern browsers and mail clients have the Public Keys of several "known authorities" (issuers) built-in. As a result, they can verify the digital signatures of the Certificates issued by those "known authorities". It is assumed that such "known authorities" take reasonable steps to ensure that they issue a Certificate for abc.def domain to the legal owner of that domain.
When the CommuniGate Pro Server starts, it generates a Test Certificate. The Test Certificate has the Server Main Domain name as its Subject and Stalker Software, Inc. as the Certificate issuer. The Test Certificate expires 30 days after the Server start time.
You can configure a CommuniGate Pro Domain to use this Test Certificate, but you should use this feature for testing purposes only.
To enter the domain Private Key and Certificate, use the WebAdmin Interface and follow the Security link on the Domain Settings page. The Domain Security page will open:
This option allows you to specify which private keys and certificates the CommuniGate Pro Server should use when a client wants to establish a secure (SSL/TLS) connection with this Domain.Note: depending on your server hardware platform, it can take up to several minutes to generate a 2048-bit Key.
Only after you assign a Private Key, the Certificate-related fields will appear on the Security page.
You can use any third-party program (such as OpenSSL) to generate a Private Key in the so-called PEM format (as shown below), and assign that Key to the Domain. Select "Custom" in the Size: field and click the Generate Key button. A multi-line text field appears. Copy the PEM-encoded Key into that text field, and click the Generate Key button:
Note: Because of the export regulations, some US-made products (such as Netscape 4.x) disable strong (more than 512 bit) cryptography for SSL/TLS "shared secret" exchange. Those products expect a server to send them a temporary 512-bit key instead, with the generated longer key being used for certificate validation only. If your users employ software products with disabled strong cryptography, generate and use 512-bit keys only: in this situation longer keys will only increase the server load without any increase in the security level. Alternatively, you can use special Certificates (see below) issued by VeriSign and other companies. Those Certificates contain supplementary attributes that tell "weak" products to lift the restrictions and use strong cryptography instead. If you want to use those special certificates, you should generate 1024-bit or 2048-bit keys.
If the Private Key was set correctly, and the Key can be used for public/private key cryptography, you will see the following panel:
If the Key Test field indicates an error, the generated Private Key cannot be used for public/private key cryptography.
Use the Remove button if you want to remove the entered Domain Private Key. Since the Domain Certificate can be used with one and only one Private Ke, it becomes useless when you delete the Private Key, so the existing Domain Certificate will be removed, too.
To accept secure connections, the Domain must have a certificate issued for that domain. Please note that the clients compare the name in the Certificate to the name they used to connect to the Server. If a CommuniGate Pro Domain has domain aliases, attempts to connect to the Server using a domain alias name will result in warning messages on the client workstations notifying users about the name mismatch. Since the certificate can contain only one name, select the name (real Domain name or one of the Domain Aliases) that your users will use in the mail client settings. If your CommuniGate Pro Domain name is company.dom, and that domain name does not have a DNS A-record, but the Domain has an Alias mail.company.dom that has an A-record pointing to the CommuniGate Pro Server, your users will use the mail.company.dom name in their client settings and WebUser Interface URLs, so the Domain Certificate should be issued for the mail.company.dom name rather than the company.dom name.
To create a Certificate, fill the fields in the Certificate Attributes table:
All other fields are optional.
You can create a Self-Signed Certificate if you do not want to use any external authority. Click the Generate Self-Signed button and the CommuniGate Pro Server creates a so-called self-signed certificate: the issuer will be same entity you have specified, and the entire certificate will be signed using the Domain Private Key. When a Domain has a Self-Signed Certificate, client applications will warn user that the addressed server has presented a certificate "issued by an unknown authority". Users can "install" self-signed certificates to avoid these warnings.
To receive a Certificate from an external source ("trusted authority"), click the Generate Signing Request button. A text field containing the PEM-encoded CSR (Certificate Signing Request) will appear:
Copy the CSR text and submit it to the Certification Authority (CA) of your choice. You can submit via E-mail or using a Web form on the CA site. The Certification Authority should send you back the signed Certificate in the PEM-format. Enter that Certificate into the bottom field and click the Set Certificate button.
If the Certificate is accepted, the Certificate information is displayed:
The Certificate panel shows the information about the issuer (the Certificate Authority), the information about the "subject" (the data you have entered and the domain name) and the validity period of this Certificate.Note: the entered Private Key and Certificate will be used for the Domain secure communications ONLY if the Secure Certificate To Use option is set to Custom.
Note: the Certificate contains the domain name as a part of the "Subject" data. If you rename the CommuniGate Pro Domain, the domain name in the certificate does not change, and the client applications may start to warn users about the name mismatch.
Click the Remove Certificate button to remove the Domain Certificate.
When you receive a Certificate from a Certificate Authority that is not listed among the "trusted authorities" in the client software settings, that intermediate Certificate Authority (CA) should also give you its own Certificate signed with a "trusted authority". That Certificate should be in the same PEM format as your Domain Certificate:
The CA Chain may include several certifcates: the first one certifies the issuer of the Domain certificate you have entered, but it itself may be issued by some intermediate authority. The next certiciate certifies that intermediate authority, etc. The last certificate in the chain should be issued by some authority "known" to client browser/mailer software - usually, some "root" authority.
If your CA Chain contains several certificates, enter all of them (PEM-encoded) into the Certificate Authority Chain field, with the "root" certificate being the last one in the list.
Click the Set CA Chain button to assign the Certificate Authority Chain to the Domian. If all certificates in the Chain are decoded successfully and their format is correct, the list of CA Chain certificates is displayed:
Note: CommuniGate Pro checks only the format of each certificate in the Chain. It does not check that each certificate really certifies the issuer of the previous certificate and that the last certificate in the Chain is issued by a "known" authority.
When set, the Certificate Authority Chain is sent to clients together with the Domain Certificate.
Click the Remove CA Chain button to remove the Certificate Authority Chain from the Domain Security Settings.
Your users can "install" your Server domain certificates into their mailers and browsers. Once installed into the client software, a certificate becomes a "trusted" one. For some programs (such as Mac versions of Microsoft Outlook and Outlook Express) installing an "untrusted" certificate is the only way to enable secure communications.
To install a domain certificate, the user should use a browser application and connect to the login page of the WebUser Interface for the selected domain. If the domain has an enabled Certificate, the Secure Certificate link appears. The user should click on that link to download the domain certificate and "open" it. The browser should allow the user to verify the certificate and install it as a "trusted" certificate.
