![]() |
CommuniGate Pro: 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:
If you create a new Domain, and create accounts in that domain, these accounts will not be listed in the Central Directory.
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.
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.
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.
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:
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 a user sends an LDAP request to the Servers A (or B):
When the Central Directory is accessed using the WebUser Interface, the search requests are processed in the similar way.
This architecture implements a real "Central" Directory for a set of Servers (for a Cluster): for each Server, the Central Directory database contains the same infromation and all information updates are synchronised.
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.
Records in this database initially contain the following fields (attributes):
You can stop the CommuniGate Pro Server and manually add more fields into the directory obejct file. You can add: