 |
CommuniGate Pro: Directory Integration |
|||||||||||||||||||||||||||||||
|
|
CommuniGate Pro Domains can use the following levels of Directory integration:
When you need to add an attribute to your Directory Schema, always try to use attribute names specified in one of the LDAP Internet Standards (RFCs). If this attribute should be used for Directory Integration (i.e. it will be used to store some Domain or Account setting value), you may want to use the Attribute Renaming capability to "map" CommuniGate Pro Domain or Account setting name on some Directory Attribute name.
Use the Attributes Renaming table to specify the name translation rules:
Note: The Attributes Renaming feature works only for Directory Integration component of the CommuniGate Pro Server. If you access the CommuniGate Pro Directory directly (via the LDAP module, for example), no renaming takes place: LDAP clients should specify the Directory Attribute names, and the returned records have Directory Attribute names, not CommuniGate Pro Domain and Account setting names - "cn", not "RealName" and "userPassword", not "Password".
The Domain Subtree panel allows you to specify the location of Subtrees created for each domain:
When a domain is placed into the Directory, a record with its DN is created. If the Base DN does not exist, the Directory Manager may return an error. Use the Create It button to create an empty record with the Base DN.
If you are an ISP you may want to give each domain you host the top-level DN:
Note: If you specify the string dc as the Domain RDN attribute, then the DN for a CommuniGatePro domain mail.domain.dom will be formed as dc=mail,dc=domain,dc=dom.
For regular domains, the domain Directory record is empty. As a result, you may use any objectClass that can include the cn attribute (or the attribute you have specified in the Domain RDN attribute setting).
For Directory-based Domains, the domain Directory record contains all domain settings, so the objectClass for these records should support all attributes included into the CommuniGateDomain objectClass.
After you have decided how to organize your Domains Subtree, you can create additional Directory Storage Units to store your domains and account data in several units (if necessary). For examlpe, if you want to use your CommuniGate Pro Directory Manager to store various non-account related information, and you want all Domain and Account information to be stored either on a remote LDAP server or in a dedicated Local Storage Unit, you can create a Storage Unit MyDomains for the Directory Integration Base DN subtree (o=acme in the examples listed above). In this case, all Domains and Account records will be stored in that MyDomains Storage Unit (in a separate local unit or on a remote LDAP server), while all records that do not have the o=acme suffix will be stored in other Storage Units:
Note:If you change any Domain Subtree setting, the existing Subtree is not modified. Carefully select the proper values for the Domain Subtree settings before you start any Directory Integration activity. If you need to change these settings later, it is your responsibility to move the existing Domain Subtree to the new location (specified with the new BaseDN) and/or to change RDNs of the existing domain records (if you have changed the Domain RDN Attribute setting).
You can use these Custom Account Settings to store additional information about your users: locations, phone numbers, demographic data, etc.
To add a Custom Setting, type its name into the last (empty) field.
Additional (custom) Account Settings are stored in Account Directory records (these records
have the CommuniGateAccount Object Class).
When you select a name for a new Custom Account Setting, either use a name of an attribute already specified for
CommuniGateAccount object class in the Directory Schema, or use the Directory Integration
Attribute Renaming feature and map the new Custom Account Setting name onto a name of
any already specified attribute.
Note: account records in the Directory always contain the sn attribute to make them compatible with the standard LDAP Directory Schema. If you do not include this attribute into the Custom Account Settings set, CommuniGate Pro stores account records with the sn attribute containing an empty string.
After you have specified some Custom Account Settings, their names appear on the Account Settings pages. You can use those pages or CLI to add and update the Custom Setting values for all CommuniGate Pro Accounts:
Note: if you rename a custom attribute name or remove it, the attribute values are not modified in the Directory - you are effectively changing the Directory Integration parameters, not the Directory data itself. To update the actual Directory data (for example, to remove all telephoneNumber attribute values from the Directory), use LDAP utilities and/or applications.
Account records for Regular Domain accounts have the following DNs:
Directory records for Regular Domain accounts use the uid attribute for their RDNs, and account record DNs are
The directory record for a Regular Domain is created when the Server needs to store a direcory record for an account in that domain. For example, when the Server needs to create a directory record for the account john in the domain1.dom domain, it creates the cn=domain1.dom record first (if it does not exist), and then creates the uid=john,cn=domain1.dom record for the account john.
When the Directory Integration Domain Setting is set to Keep In Sync:
Directory records for Regular Domain Accounts contain the following attributes:
Use the Delete All button to delete the regular Domain and all its Account records from the Directory. The operation deletes only those Account records that contain the hostServer attribute and the value of that attribute is equal to the Main Domain name of this CommuniGate Pro Server.
Use the Insert All button to create a directory record for this regular Domain and to create directory records for all its accounts.
Note: if you have created several Accounts in the regular Domain when its Directory Integration setting was set to Diabled, and then you switched that setting to Keep In Sync, you may see error reports when you try to rename, remove or received those accounts: the Server tries to update the directory records for those accounts, but those Directory records do not exist. Before you switch the Directory Integration setting from Disabled to Keep In Sync, press the Delete All, then - the Insert All buttons to synchronize the Directory and the current Domain Accounts set.
It is important to understand that Directory Integration for Regular Domains is a one-way relationship: if you change attributes of account records in the Directory (using any LDAP utility), the actual Account Settings will not be modified - CommuniGate Pro always uses data in the settings files, and never reads data from the Directory when it needs to retrieve settings for Regular Domains or settings for those domains Accounts. CommuniGate Pro Regular Domains and Accounts manager only updates the Directory, but it never reads the data from the Directory.
For each Directory-based Domain a Directory record of the CommuniGateDirectoryDomain objectClass is created.
This record stores all Domain Settings.
DNs for Directory-based Domains are built in the same way they are built for Regular Domain
records.
For each account in a Directory-based Domain a Directory record of the CommuniGateAccount objectClass is created.
This record stores all Account Settings (including the Custom Settings).
DNs for accounts in the Directory-based Domains are built in the same way they are built for Regular Domain Account
records.
Directory records for Directory-based Domain Accounts must contain the storageLocation attribute. This attribute specifies the location of the account file directory (for the Multi-mailbox accounts) or the location of the account INBOX file (for single-mailbox accounts). The location is specified as a file path relative to the base directory of the CommuniGate Pro Server hosting this account.
If a CommuniGate Pro server has to open an account in a Directory-based domain, and the account storageLocation attribute starts with the asterisk (*) symbol, the CommuniGate Pro Server creates the account file directory (for multi-mailbox accounts) and other required account files and file directories.
Directory records are created for aliases of Directory-based Domain Accounts.
Alias records have the same DN as Accounts (uid=aliasname,domain DN).
Alias records have the standard alias objectClass,
and their aliasedObjectName attribute specifies the DN of the original account record.
The shared Directory Unit can implemented as a Local Storage Unit on one of the CommuniGate Pro Servers, or it can be hosted on some third-party Directory Server.
To simplify the setup, especially if you have many CommuniGate Pro Servers, it is recommended to create the Remote Storage Units for the <root> Subtrees. To create such a Unit, remove the default Main Local Unit first:
When an Account is created, renamed, removed, or updated on one of the sv*.corp.com Servers, the Directory Unit on the Shared Directory Server is updated. As a result, the Shared Directory contains records for all Accounts created on all sv*.corp.com Servers.
When any Server creates an Account and places a record into the Shared Directory, it stores the Server Mail Domain name as the record hostServer attribute.
The Shared Directory can be used to route Shared Domain mail to the proper location (Server). After you enable the Directory-Based Routing Setting in the CommuniGate Pro General->Cluster Settings, the address routing mechanism is modified:
This Distributed Domain configuration is useful for multi-location and international organizations and corporations where all employee accounts should be in the same domain, but each organizational unit is served with its own Server. The DNS MX records for the such a Distributed Domain should point to any or to all Servers hosting that domain. When a Server receives mail for a Distributed Domain, it either delivers the mail locally (if the addressed Account is hosted on that Server), or relays mail to Server specifed in the hostServer attribute of the Account Directory record.
Usually, one of the Servers (the "main location") hosts most of the Distributed Domain Accounts. It is recommended to host the Shared Directory on that CommuniGate Pro Server to minimize the delays introduced with the Directory lookups. Other CommuniGate Pro Server serving this Distributed Domain can be configured to reroute all mail to non-local objects of the Distributed Domain to that "main location" Server. In the Distributed Domain Settings, set the Mail To Unknown option to
This method eliminates a need for "remote location" Servers to communicate with the Directory when they have to route addresses. The "remote location" Servers communicate with the Directory only when a Distributed Domain Accounts are created, renamed, or removed, or when a WebMail or LDAP user requests a Directory search operation. This can drastically improve the "remote location" Servers performance if the communication links between them and the Shared Directory Server are slow and/or unreliable.
In asymmetric, "main/remote location" configurations, the high-priority MX records for the Distributed Domain should point to the "main location" Server, while "remote location" Server names can be used for low-priority MX records. It is not not recommended to use Directory-based Domains for Distributed Domains if connections between "remote location" Servers and the Shared Directory is slow and/or unreliable.
The Distributed Domains concept is the foundation of the CommuniGate Pro Static Clusters.
For small Distributed Domains, routing can be impemented using regular CommuniGate Pro Router records. If the Distributed Domain has the same Accounts as shown in the example above, the SV1 server should have the following records in its Router:
While this method does not require any Directory activity, it is hardly acceptable for Domains with more than 30-100 Accounts, unless names of Accounts hosted on different Servers can be easily expressed using the Router wildcard symbols. For example, if all Accounts hosted on the Server SV2 end with the -uk suffix (dan-uk@corp.com, ed-uk@corp.com, fred-uk@corp.com, etc.), routing for all SV2 Accounts can be specified with one Router record:
