CommuniGate Pro LDAP Module
Intro
Installation
SysAdmin
Objects
Transfer
Access 
Sharing 
POP 
IMAP 
Web User 
LDAP
ACAP 
PWD 
Directory
Data Files
Clusters
WebMail
Miscellaneous
Licensing
HowTo
  • Lightweight Directory Access Protocol
  • Configuring the LDAP module
  • User Authentication
  • Central Directory
  • The mail Attribute processing

    • The CommuniGate LDAP module implements an LDAP server for TCP/IP networks.

    The LDAP protocol allows a client application (a mailer or a search agent) to connect to the Server computer and retrieve information from the server Directory. The LDAP protocol can also be used to modify data in the Directory.

    The CommuniGate Pro LDAP module supports both clear text and secure (SSL/TLS) connections.

    Lightweight Directory Access Protocol

    The CommuniGate Pro LDAP module provides access to the CommuniGate Pro Directory tree and its records.

    It is important to understand that the CommuniGate Pro LDAP module itself does not provide any Directory services. It just implements an access protocol, and the functionality it provides depends on the CommuniGate Pro Directory Manager and its units.

    Very often LDAP services are used to look for names and E-mail addresses of Server users. But since the LDAP module provides access to the entire Directory tree, it can be used to work with any type of data placed into the CommuniGate Pro Directory. While the CommuniGate Pro Directory can be stored in several Storage Units - both local and remote, the LDAP clients see the entire Directory as one large tree.

    To browse and modify the Directory, system administrators can use either LDAP clients and utilties, or the Directory Browser interface built into the CommuniGate Pro WebAdmin Interface.

    Note: while the LDAP module implements an LDAP server functionality, the CommuniGate Pro Server can also work as an LDAP client, using the LDAP protocol to access external LDAP servers and their databases. Those external Directories are presented as subtrees of the CommuniGate Pro Directory tree. See the Remote Units Directory section for more details.

    Configuring the LDAP module

    Use a Web browser to configure the LDAP module. Open the Access page in the WebAdmin Settings section.

    Serving LDAP Clients
    Log:  
    Channels: listener
    Log
    Use this setting to specify what kind of information the LDAP module should put in the Server Log. Usually you should use the Major or Problems (non-fatal errors) levels. But when you experience problems with the LDAP module, you may want to set the Log Level setting to Low-Level or All Info: in this case protocol-level or link-level details will be recorded in the System Log as well.

    The LDAP module records in the System Log are marked with the LDAP tag. Please note that LDAP is a binary protocol, so all low-level data is presented in the hexadecimal form.

    Channels
    When you specify a non-zero value for the TCP/IP Channels setting, the LDAP module creates a so-called "listener" on the specified port. The module starts to accept all LDAP connections that mail clients establish in order to updates password data. This setting is used to limit the number of simultaneous connections the LDAP module can accept. If there are too many incoming connections open, the module will reject new connections, and the user should retry later.
    If the number of channels is set to zero, the LDAP module closes the listener and releases (unbinds from) the TCP port(s).

    listener
    By default, the LDAP module Listener accepts clear text connections on the TCP port 389, and secure connections - on the TCP port 636. Follow the listener link to tune the LDAP Listener.

    Note:The pre-4.7 Netscape ® LDAP clients crash if they communicate with a very fast server returning more than 90 records. Ask your users to update to the 4.7 or later version of Netscape browser/mailer product.

    Note:The Netscape® LDAP client (version 4.7) does not correctly process the "properties" command - it always tries to connect to the port 389, even if the search was successfully made on a different (for example, secure) port.

    Sometimes you need to specify the Directory Tree Root element (an empty string) as the "search base DN". Some LDAP clients do not process this situation correctly (for example, Microsoft LDAP client silently replaces an empty Search Base string with the c=your_country string).
    In these cases you should specify the string  top  as your Search Base string. The LDAP module interpretes this string as an empty string (Directory Root DN).

    User Authentication

    The Directory Access Rights are based on the so-called Bind DNs rather than on CommuniGate Pro account names and account rights. See the Directory Manager Access Rights section for more details.

    The Directory Access Rights set by default do not require Directory (LDAP) clients to authentiate in order to retrieve any information from the Directory tree.

    When an LDAP client tries to authenticate as a certain DN, the LDAP server retrieves the Directory record with the specified DN and compares that record userPassword attribute with the password supplied by the LDAP client. If the record exists, and it contains the userPassword attribute, and the attribute value matches the supplied password, the LDAP client authentication succeeds.

    The LDAP module provides an alternative authentication method, with a CommuniGate Pro account name specified instead of a DN. In this case, the CommuniGate Pro Server opens the specfied account and compares the account password with the supplied password. If the passwords match, the Server builds a DN for the account record using the Directory Integration settings, and uses it as the Bind DN.

    Sample:

    If the Directory Integration settings are:
    Base DN:  o=myCompany
    Domain RDN attribute:  cn

    and the client has submitted the user@domain.dom name and the correct password for the user@domain.com account, then the LDAP client is authenticated with the following Bind DN:
    uid=user,cn=domain.dom,o=myCompany
    and this client can access the Directory information available for that Bind DN.

    Note: If a user tries to authenticate using the explicitly specified uid=user,cn=domain.dom,o=myCompany Bind DN, only that Directory record userPassword attribute is checked - even if the CommuniGate Pro account user@domain.dom exists, its password is not checked.
    If a user tries to authenticate using the user@domain.dom string instead of a DN, only the user@domain.dom account password is checked, even if the uid=user,cn=domain.dom,o=myCompany Directory record exists and contains the userPassword attribute.

    Note: The LDAP module uses the alternative authentication method if the specified string does not contain any equals (=) sign, or if it starts with the mail= symbols and does not contain any other equals (=) signs:

    string specified  Method used
    uid=user,cn=domain.dom,o=myCompany  userPassword record attribute
    ou=human resources,o=myCompany  userPassword record attribute
    user@domain.com  account password
    mail=user@domain.com  account password

    The LDAP module allows users to employ all authentication methods supported with the CommuniGate Pro Server.

    If the account password authentication method is used, and the specified account has the Directory Administrator access right, the LDAP client can access and modify all Directory data ("master"-type access).

    Central (users) Directory

    Very often the LDAP services are used to retrieve information about the CommuniGate Pro accounts.

    To search the Directory for CommuniGate Pro domain accounts, the LDAP clients should be tuned to point to the proper Subtree (this parameter is called "Search Base" in many LDAP clients). The Directory Subtree for the company.com domain is cn=company.com,o=MyCompany, where cn is the Domain RDN attribute, and o=MyCompany is the Base DN for CommuniGate Pro Domains. The Base DN and Domain RDN attribute are the Directory Integration settings and can be modified. If these settings are modified, the locations of domain subtrees are changed, and the LDAP clients should be reconfigured to specify the new locations in their "Search Base" settings.

    The mail Attribute processing

    Most of the LDAP clients expect to see the mail attribute in account records. By default, CommuniGate Pro does not store such an attribute in Account directory records.

    If the LDAP module has to return such a record (a record of the CommuniGateAccount object class), and that record does not contain the mail attribute, the LDAP module builds that attribute on-the-fly, using the account record DN: it takes the uid value from the DN (account name), the cn attribute value (domain name), and megres them using the @ sign to build the uidValue@cnValue mail attribute value. As a result, when an account is renamed (its record uid attribute is changed), or when the domain is renamed (the cn attribute in account DN is changed), the mail attribute is automatically updated.

    All search filters that use the mail attribute are modified internally to use the uid attribute instead.

    CommuniGate® Pro Guide. Copyright © 1998-2000, Stalker Software, Inc.