CommuniGate Pro: Central Directory

Intro
Installation
SysAdmin
Accounts
Transfer
Access
Directory
Data Files
Clusters
Miscellaneous
Licensing
HowTo

The CommuniGate Pro Server can maintain and/or use a Central Directory database. This database contains information about the CommuniGate Pro Server accounts. If your site uses a CommuniGate Pro Cluster, your Central Directory database contains information about all accounts on your site servers.


Configuring Central Directory

The System Administrator can control who can access the Central Directory database. The setting is located on the Obscure page in the Settings section:

Central Directory Options
Who can Browse: Make LDAP Server Slower

Who can Browse
If the anyone option is selected, anybody can access the Central Directory database - via LDAP or using the WebUser Interface (via the Directory link on the WebUser Interface Login page).
If the Clients option is selected, access to the Central Directory is granted to all authenticated users and to all clients connecing from the network (IP) addresses included into the Client IP Addresses list.
If the Local Users option is selected, access to the Central Directory is granted to authenticated users only. LDAP users should configure their clients to log into the server, and the WebUser Interface Directory link is availble only inside a WebUser session.


Disabled Central Directory

Each CommuniGate Pro Domain has the Central Directory setting. If that setting value is Disabled, the Server does not update the Central Directory when it creates or removes accounts in that Domain, or when account settings are updated.

If you create a new Domain, and create accounts in that domain, these accounts will not be listed in the Central Directory.


Central Directory as White Pages

You can use your Central Directory database as White Pages: if you set the Central Directory setting of some CommuniGate Pro Domain to Keep Updated, the Server will update the Central Directory when you create, remove, or rename Domain accounts, or when some domain account settings are updated.

In this mode, your CommuniGate Pro Server only updates the information in the Central Directory database, but it does not use that information for its internal purposes.

Users can search the Central Directory using their LDAP clients or the CommuniGate Pro WebUser Interface.


Bulk Updating

The System Administrator can insert records for all domain accounts into the Central Directory database. This can be useful if the domain accounts were not included into the Central Directory (the Central Directory services where disabled for that domain).
Note: the Server does not check if a record for each domain account already exists in the database. If some domain account records have already been placed into the Central Directory, the Insert All operation can either fail, or produce duplicates, depending on the type of the database used for the Central Directory.

The System Administrator can remove all domain records from the Central Directory. This is done by removing all Central Directory database records with the mail field ending with @domainname. Be careful with this operation: if the Central Directory database is shared by several servers in a cluster (see below), this operation will remove all domain records, not only the records for the accounts stored on this particular server.


Central Directory as Account Settings Storage

You can tell the CommuniGate Pro Server to use the Central Directory database as the account settings storage. Set the Central Directory Domain setting to Store Settings and the Server will not only update the Central Directory as it does in the Keep Updated mode, but it will also retrieve account settings from the Central Directory database when a domain account should be opened.

This mode is useful if the Central Directory database object is an external database - for example, an external LDAP server. In this case, the account settings are available for various application directly from that database, and they can retrieve and modify account Settings bypassing CommuniGate Pro.


Central Directory Database Object

The Central Directory database is implemented as a CommuniGate Pro database object.

When the Server is installed for the first time, the Directory database object of the default (text) type is created as the Directory.tdb file in the CommuniGate Pro base directory. You can replace that file with a database object file of any supported type. For example, you can replace it with the Directory.ldb file that specifies an external LDAP server: the .ldp database object will represent that external LDAP server in your CommuniGate Pro Server and all requests sent to the Central Directory database will be converted into LDAP requests and sent to the specified external LDAP server:


Multi-Server (Cluster) Central Directory

You may want to maintain one Central Directory for a set of several CommuniGate Pro Servers (a CommuniGate Pro Cluster). Since the Central Directory is a database object, you can use objects that provide access to the shared database storage.

For example, you can configure your CommuniGate Pro servers to use .ldb Directory.ldb files as their Central Directory database objects. All those files should point to the same external LDAP server:

When a Server A account is created, renamed, removed, or updated, that Server sends an updating request to its Central Directory database object. If that object is an .ldb object, the updating request is translated into an LDAP request and it is sent to an external LDAP server. The same happens when an account is created on the Server B. As a result, the external LDAP server maintains a Central Directory that contains records for accounts created on Server A, Server B, and any other CommuniGate Pro Server that uses this external LDAP server as its Central Directory database object.

You can use one of your CommuniGate Pro Servers (and its LDAP module) as the external LDAP server used with other Servers for their Central Directories:

When an account is created, renamed, removed, or updated on the Server A and on similarly configured Servers B, C, D, etc. - the Central Directory database object on the Server X is updated. When an account is created on the Server X, this object is updated, too. As a result, if the Central Directory object on the Server X is implemented as a text (.tdb) database file, this file will contain records for all accounts on Servers A, B and X.

When a user sends an LDAP request to the Servers A (or B):


Central Directory as a Cluster Router

You can use your Central Directory for Clustering, if:

For an account created on the Server A, the account record in the Central Directory contains the Server A Main Domain Name in the #home field. This can be used to implement static clustering.


Central Directory Fields

When the CommuniGate Pro Server starts for the first time, it creates a Text Database file Directory.tbd in its base directory.

Records in this database initially contain the following fields (attributes):

mail (key field)
full account name (accountname@domainname)
cn
account Real Name

You can stop the CommuniGate Pro Server and manually add more fields into the directory obejct file. You can add:


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