Directory Integration

CommuniGate Pro Domains can use the following levels of Directory integration:

• No integration; the Domain and the Domain Accounts settings are stored in .settings files, and when an Account is created, updated, renamed, or removed, Directory is not updated.
• Synchronized; the Domain and Domain Account settings are stored in the .settings files; each Account has a Directory record that stores some of the Account settings as attributes:
  • the Account name in the uid attribute
  • the Account Real Name in the cn attribute
  • the Account Certificate in the userCertificate attribute (if exists)
  • the hosting Server Main Domain name in the hostServer attribute (this attribute is needed to implement Directory-based Static Clusters)
  • an optional set of custom (and "public info") settings/attributes.
  When an Account is created, renamed, removed, or updated, the Directory is automatically updated.
• Directory-based. The Domain and the Domain Account settings are stored in the Directory records. The .settings files are not created, and the Server retrieves all settings information from the Directory.

Finally, the CommuniGate Pro can use regular (non Directory-Based) domains, but still allow Account provisioning via LDAP, so it looks like the Directory-Based Domains are used and LDAP commands can create and update Account. This feature is called LDAP-based Provisioning.

Some Domain and Account settings names may not match the standard attribute names used in the Directory Schema. For example, the Account setting Real Name has to be stored in the Directory as the cn (common name) attribute, and the custom settings surname and city (see below) should be stored as attributes sn and l.

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 Translation table to specify the name translation rules:

Attributes Translation
Name in CommuniGate	Name in Directory

Note: The Attributes Translation feature works only for the Directory Integration component of the CommuniGate Pro Server. If you access the CommuniGate Pro Directory directly (via the LDAP module, for example), no translation 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".

For each regular CommuniGate Pro Domain with the Directory setting set to Keep in Sync, and for each Directory-Based Domain a Directory Subtree is created. This Subtree has the Domain record as its root, and all Domain Account records as the Subtree elements ("leaves"). For Directory-based Domains, additional elements are created to store Account aliases, Domains settings, etc.

The Domain Subtree panel allows you to specify the location of Subtrees created for each CommuniGate Pro Domain:

Domain Subtree
Base DN:
Domain RDN Attribute:
Domain objectClass:
UID Subtree:

Base DN

This field specifies the "base" DN for all Domains in the Central Directory. You may want to set it as:

o=your company name

so each CommuniGate Pro Domain will have the following DN:

cn=domain name,o=your company name

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:

cn=domain name

In this case, specify an empty string in the Base DN field.

Domain RDN attribute

This field specifies the attribute name to use for Domain record RDNs. In most cases, the default value (cn) is the best choice. However, you can change that to the name of any other attribute defined in the Directory schema. If you set this name to o, the CommuniGate Pro Domain records will have the following DNs:

o=domain name,base DN

Note: If you specify the string dc as the Domain RDN attribute, then the DN for a CommuniGate Pro Domain mail.domain.dom will be composed as dc=mail,dc=domain,dc=dom.

Domain objectClass

This field specifies the objectClass for CommuniGate Pro Domain records in the Directory. The CommuniGateDomain objectClass defined in the CommuniGate Pro Directory Manager schema is the default value. If you choose to select a different objectClass, make sure it exists in your Directory schema.

For regular Domain, the Domain Directory record is empty. As a result, you may use any objectClass that can store 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.

UID subtree

If this field is empty, then the Domain Object (Account, Group, List, Forwarder) records are stored in the directory using the following DNs: uid=objectName,domain DN.
If the base DN is o=mycompany, and the Domain RDN attribute is cn, then the directory record for the user1 Account in the domain1.dom Domain will have the following DN:
uid=user1,cn=domain1.dom,o=mycompany
The UID subtree parameter allows you to place the objects "below" the domain tree. If the UID subtree is set to ou=People, then the record for the same Account will have the following DN:
uid=user1,ou=People,cn=domain1.dom,o=mycompany
If the Domain RDN attribute is set to dc, then the record for the same Account will have the following DN:
uid=user1,ou=People,dc=domain1,dc=dom,o=mycompany

Example:

BaseDN is an empty string, Domain RDN Attribute is cn, and three CommuniGate Pro domains (domain1.dom, domain2.dom, and domain3.dom) have been created:

To search for Accounts in these Domain subtrees, LDAP clients should have the string

cn=domainN.dom

specified in their "Base Object" or "Search Base" settings.

Example:

BaseDN is o=acme, Domain RDN Attribute is cn, and three CommuniGate Pro domains (domain1.dom, domain2.dom, and domain3.dom) have been created:

To search for Accounts in these Domain subtrees, LDAP clients should have the string

cn=domainN.dom,o=acme

specified in their "Base Object" or "Search Base" settings.

Example:

BaseDN is o=acme, Domain RDN Attribute is dc, and three CommuniGate Pro domains (domain1.dom, domain2.dom, and domain3.dom) have been created:

To search for Accounts in these Domain subtrees, LDAP clients should have the string

dc=domainN,dc=dom,o=acme

specified in their "Base Object" or "Search Base" settings.

After you have decided how to organize your Domains Subtree, you can create additional Directory Storage Units to store your Domain and Account data in several units (if necessary). For example, if you want to use your CommuniGate Pro Directory Manager to store information not related to CommuniGate Pro Accounts, 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).

The CommuniGate Pro Server has a predefined set of Account Settings (see the Accounts section for more details). The Directory Integration settings include a panel that allows you to specify additional, Custom settings for CommuniGate Pro Accounts:

Custom Account Settings
System	Public Info

You can use these Custom Account Settings to store additional information about your users: locations, phone numbers, demographic data, etc.

The System custom settings can be modified by Server administrators and Domain administrators with the Basic Domain Access Right.

The Public Info custom settings can be modified by the users themselves.

To add a Custom Setting, type its name into the last (empty) field and click the Update button.

Additional (custom) Account Settings are stored in Account Directory records (these records have the CommuniGateAccount objectClass).

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.

Example:

To add the telephoneNumber setting to all CommuniGate Pro Accounts, add the name telephoneNumber to the Custom Account Settings table.
If a Local Storage Unit is used to store CommuniGate Pro Domains and Accounts subtree, no additional action is needed: the telephoneNumber attribute is already included into the CommuniGateAccount object class description in all Local Unit Schemas.

Example:

To add the surname setting to all CommuniGate Pro Accounts, add the name surname to the Custom Account Settings table, and add the pair (surname, sn) to the Attribute Renaming table, so the surname Account Settings will be stored in Directory records as sn attributes.
If a Local Storage Unit is used to store CommuniGate Pro Domains and Accounts subtree, no additional action is needed: the sn attribute is already included into the CommuniGateAccount object class description in all Local Unit Schemas.

Example:

To add the BirthDay setting to all CommuniGate Pro Accounts, add the name BirthDay to the Custom Account Settings table.
If a Local Storage Unit is used to store CommuniGate Pro Domains and Accounts subtree, add the BirthDay attribute to the Local Unit Schema, and add the newly created BirthDay attribute name to the list of Optional Attributes of the CommuniGateAccount object class.
If a Remote Storage Unit is used to store CommuniGate Pro Domains and Accounts subtree, update the Directory Schema on the remote LDAP server to allow directory records of the CommuniGateAccount object class to include the BirthDay 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 the none 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:

Real Name:
surname:
city:
CommuniGate   Password:
telephoneNumber:

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.

Regular CommuniGate Pro Domains do not rely on Directory data. All Domain and Account settings are stored in files inside the CommuniGate Pro file directories and CommuniGate Pro Server reads those files when it needs to retrieve Domain and Account settings. Regular Domains can store copies of some Account Settings in Directory records.

The directory record for a Regular Domain is created when the Server needs to store a directory record for any object in that Domain. For example, when the Server needs to create a directory record for the Account john in the dom1.dom Domain, it creates the cn=dom1.dom record first (if it does not exist), and then the Server creates the uid=john,cn=dom1.dom record for the Account john.

When the Directory Integration Domain Setting is set to Keep In Sync:

• A directory record is created for each object (Account, Group, Mailing List, Forwarder) created in that Domain.
• A directory record is removed when an object is removed from that Domain.
• Directory record DNs are renamed when Domain objects are renamed.
• Directory records are updated when Domain Accounts settings are updated.

None of these actions takes place when the Domain Directory Integration settings is set to Disabled.

The following diagram illustrates what happens when the dom1.dom Domain has the Directory Integration option set to Keep In Sync, and an Account is created in that Domain:

In this example:

• The WebAdmin or CLI interface is used to create the john Account in the dom1.dom Domain.
• The Account john is created, and the supplied settings (together with the Account Template) are used to compose the initial Account Settings.
• The Account Manager executes the AddRecord Directory operation to create a record in the Directory.
  The Directory record DN is composed using the global Directory Integration Settings. If the default settings are used, the Directory record DN is uid=john,cn=dom1.dom.
  Some of the initial Account Settings are converted into Directory attributes and stored into the newly created Directory record.

Now Directory search operations (initiated with an LDAP client or the WebUser Interface) can display the record for the newly created account.

Directory records for Regular Domain Accounts contain the following attributes:

• uid - the Account name
• cn - the Account "Real Name"
• sn - an empty string if this attribute is not included into Custom Account Settings
• hostServer - the Main Domain name of the CommuniGate Pro Server that hosts this Account
• userCertificate - the Account Certificate (if exists)
• custom settings (see above)
• userPassword - the Account password (optionally)
• other standard settings - (optionally)

The Regular Domains panel located on the Directory Integration page of the WebAdmin Interface allows you to specify these options:

Regular Domains
Copy into Account records:	Passwords
	Standard Settings

Copy Password

If this option is selected, the Directory records for Regular Domain Accounts will contain the Account Password attribute (usually it is renamed into the userPassword attribute).

Copy Standard Settings

If this option is selected, the Directory records for Regular Domain Accounts will contain all CommuniGate Pro standard Settings for those Accounts (excluding the RealName and userCertificate settings that are always being stored and the Password setting that it controlled using a separate option).

The following diagram illustrates what happens when the dom1.dom Domain has the Directory Integration option set to Keep In Sync, and Domain Account settings are updated:

In this example:

• The UpdateAccount operation is initiated with a WebAdmin or CLI Interface command.
• The Account john Settings are modified using the supplied new settings and the updated settings are stored in the CommuniGate Pro Account data files.
• If the dom1.dom Domain Directory Integration setting is set to Keep In Sync, the Account Manager executes the UpdateRecord Directory operation to update the Account record in the Directory.

Note: 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 Accounts in those Domains. The CommuniGate Pro Manager for regular Domains and Accounts only updates the Directory, but it never reads the Account record data back from the Directory.

The following diagram illustrates what happens when the dom1.dom Domain has the Directory Integration option set to Keep In Sync, and a Domain Account is renamed:

In this example:

• The RenameAccount operation is initiated with a WebAdmin or CLI Interface command.
• The Account john and its files are renamed.
• If the dom1.dom Domain Directory Integration setting is set to Keep In Sync, the Account Manager executes the RenameRecord (modifyDN) Directory operation to rename the Account record in the Directory.

The following diagram illustrates what happens when the dom1.dom Domain has the Directory Integration option set to Keep In Sync, and a Domain Account is removed:

In this example:

• The RemoveAccount operation is initiated with a WebAdmin or CLI Interface command.
• The Account john and its files are removed.
• If the dom1.dom Domain Directory Integration setting is set to Keep In Sync, the Account Manager executes the DeleteRecord Directory operation to remove the Account record from the Directory.

The Directory Integration panel on the Domain Settings page has the Delete All button. Use this button to delete the Domain record and all Domain Object records from the Directory. The operation deletes only those records that contain the hostServer attribute and that attribute value is the same as the Main Domain name of this CommuniGate Pro Server.

The Directory Integration panel on the Domain Settings page has the Insert All button. Use this button to create a directory record for this Domain and to create directory records for all Domain Objects.

Note: If you have created several Accounts in the regular Domain when its Directory Integration setting was set to Disabled, the Directory does not contain records for those Accounts. If later you switch that setting to Keep In Sync, you will see error reports when you try to rename, remove, or update those Accounts: the Server tries to update the Directory records for those Accounts, but the Directory records do not exist.

Before you switch the Directory Integration setting from Disabled to Keep In Sync, click the Delete All button, and then click Insert All button to synchronize the Directory and the current Domain Objects set.

CommuniGate Pro allows you to use the LDAP protocol to create, update, rename, and remove Accounts:

LDAP direct Provisioning

DisabledEnabled

When this option is enabled, the LDAP module checks the names (DNs) specified in update operations. If the DN looks like a DN of a CommuniGate Pro Account, the LDAP module does not perform the requested operation with the Directory. Instead, it executes the CreateAccount, UpdateAccount, RenameAccount, or RemoveAccount operations for the specified Account and Domain.

The diagram below illustrates how the LDAP AddRecord operation works in this case:

In this example:

• The LDAP module received an AddRecord request from an LDAP client. The client asks the LDAP module to create a record with the uid=john,cn=dom1.dom DN.
• The LDAP module checks the DN and sees that it looks like the record DN for the CommuniGate Pro Account john in the CommuniGate Pro Domain dom1.dom, and the CommuniGate Pro Domain dom1.dom does exist.
• Instead of performing the requested AddRecord operation with the Directory, the LDAP module executes the CreateAccount(john) operation in the dom1.dom Domain.
• The Account john is created, and the supplied LDAP attributes (together with the Account Template) are used to compose the initial Account Settings.
• If the dom1.dom Domain Directory Integration setting is set to Keep In Sync, the Account Manager executes the AddRecord Directory operation to create a record in the Directory.

Note: the Directory Integration settings are used to convert LDAP record attribute names into the CommuniGate Pro attribute names. For example, the LDAP AddRecord request can contain the cn attribute. This attribute is stored in the Account settings as the Account RealName setting. When the Account Manager adds a record to the Directory, it converts the RealName Account setting back into the cn record attribute.

Note: all LDAP AddRecord request attributes will be stored as the Account Settings if the LDAP client has authenticated itself as an Account with All Domain and Account Settings access right. But only the attributes specified with the Directory Integration parameters will be copied into the new Directory record. The Directory record will also contain the attributes not included into the original LDAP AddRecord request, but specified in the Account Template.

Note: the LDAP Provisioning feature detects the unixPassword attributes and converts them into Password settings after adding a leading 0x02 byte. See the Account Import section for the details.

The following diagram illustrates how the LDAP ModifyRecord operation can be used to modify Account Settings:

In this example:

• The LDAP module received a ModifyRecord request from an LDAP client. The client asks the LDAP module to update a record with the uid=john,cn=dom1.dom DN.
• The LDAP module checks the DN and sees that it looks like the record DN for the CommuniGate Pro Account john in the CommuniGate Pro Domain dom1.dom, and the CommuniGate Pro Domain dom1.dom does exist.
• Instead of performing the requested ModifyRecord operation with the Directory, the LDAP module executes the UpdateAccount(john) operation in the dom1.dom Domain.
• The Account john Settings are modified using the supplied LDAP attributes.
• If the dom1.dom Domain Directory Integration setting is set to Keep In Sync, the Account Manager executes the ModifyRecord Directory operation to modify a record in the Directory.

The following diagram illustrates how the LDAP ModifyDN operation can be used to rename Accounts:

In this example:

• The LDAP module received a ModifyDN request from an LDAP client. The client asks the LDAP module to change the uid=john,cn=dom1.dom record DN.
• The LDAP module checks the DN and sees that it looks like the record DN for the CommuniGate Pro Account john in the CommuniGate Pro Domain dom1.dom, and the CommuniGate Pro Domain dom1.dom does exist. It also checks that the new name (uid=john1) looks like some CommuniGate Pro Account record DN.
• Instead of performing the requested ModifyDN operation with the Directory, the LDAP module executes the RenameAccount(john,john1) operation in the dom1.dom Domain.
• The Account john is renamed into john1.
• If the dom1.dom Domain Directory Integration setting is set to Keep In Sync, the Account Manager executes the ModifyDN Directory operation to change the Account record DN in the Directory.

The following diagram illustrates how the LDAP DeleteRecord operation can be used to remove Accounts:

In this example:

• The LDAP module received a DeleteRecord request from an LDAP client. The client asks the LDAP module to delete the uid=john,cn=dom1.dom record.
• The LDAP module checks the DN and sees that it looks like the record DN for the CommuniGate Pro Account john in the CommuniGate Pro Domain dom1.dom, and the CommuniGate Pro Domain dom1.dom does exist.
• Instead of performing the requested DeleteRecord operation with the Directory, the LDAP module executes the DeleteAccount(john) operation in the dom1.dom Domain.
• The Account john is deleted.
• If the dom1.dom Domain Directory Integration setting is set to Keep In Sync, the Account Manager executes the DeleteRecord Directory operation to remove the Account record DN from the Directory.

When LDAP Provisioning is enabled, the LDAP module uses special processing for some search requests, too. If

• the search request Base DN looks like a DN of some CommuniGate Pro Account, and
• the search request "scope" parameter is "base",

the LDAP module calls the Account Manager directly and retrieves the effective settings for the specified Account (i.e. the Account settings as well as all its Default Settings). The module converts these settings into Directory attributes, and sends them back to the LDAP client as a search result record.
If the authenticated LDAP user does not have the Domain Administrator access right for the target Account Domain, only the Real Name, User Certificate, Custom, Public Info, and mail attributes are retrieved.

The CommuniGate Pro Server software implements Directory-based Domains. Directory-based Domains and all their Accounts keep all their settings in the Directory - there is no .settings files for those Domains and Accounts.

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 (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.

• If the storageLocation attribute contained only one asterisk, then the new account location path is composed in the same way it is composed for new accounts in the Regular CommuniGate Pro Domains, using the path for the Domain file directory and the Foldering Domain Setting.

Directory records are created for aliases of Directory-based Domain Accounts.
Alias records have the same DNs 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 following diagram illustrates how the LDAP AddRecord operation can be used to create an Account in the Directory-based Domain:

In this example:

• The LDAP module received an AddRecord request from an LDAP client. The client asks the LDAP module to create a new record with the uid=john,cn=dom1.dom DN.
• The LDAP module creates a new record in the Directory and stores all supplied attributes in it. The response is sent back to the LDAP client and the operation is completed.
• Any Server component tries to open the account john in the Directory-Based Domain dom1.dom. The request is sent to the Directory and the record with the uid=john,cn=dom1.dom DN is retrieved.
• The storageLocation attribute in the retrieved record contains the asterisk (*) symbol. The Server creates the Account files on disk, and updates the Directory record, storing the file path to the Account files in the storageLocation attribute.
• The Account john is opened and the requested operation is executed.

Since the Account in the Directory-based Domains do not store their settings in the CommuniGate Pro data files, the settings are retrieved from the account Directory record every time an account has to be opened. The following diagram illustrates this procedure

Since the Directory records are the only source of the Account settings, modifying Directory record attributes effectively modifies the Account Settings:

In this example:

• The LDAP module received a ModifyRecord request from an LDAP client. The client asks the LDAP module to change attributes in theuid=john,cn=dom1.dom record.
• The LDAP module tells the Directory to modify the specified record. The response is sent back to the LDAP client and the operation is completed.
• Any Server component tries to open the account john in the Directory-Based Domain dom1.dom. The request is sent to the Directory and the record with the uid=john,cn=dom1.dom DN is retrieved and its attributes are used as Account Settings. Since the attribute value has been modified, the Account Setting set with that attribute is effectively modified.

Several CommuniGate Pro Servers can use the same physical Directory (Directory Unit) to keep all their Domain Integration Records.

The shared Directory Unit can be implemented as a Local Storage Unit on one of the CommuniGate Pro Servers, or it can be hosted on some third-party Directory Server.

• Specify the same Domains Subtree parameters on all CommuniGate Pro Servers.
• On all CommuniGate Pro Server (except the one that will host the shared Directory) create Remote Storage Units for the same Subtrees. The Remote Storage Unit Subtree parameter should be either the same as the Domains Subtree Base DN parameter, or should be its parent, so the entire Domains Subtree will be stored in those Remote Storage Units.
• Configure all those Storage Units to point to the server that will host the shared Directory.

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:

In this example:

• One CommuniGate Pro Server is used to host the Shared Directory.
• The SV1 and SV2 CommuniGate Pro Servers are configured to use that Shared Directory: they both have Remote Storage Units SHR for their <root> Directory Subtrees, and those Units point to the Directory hosting Server.
• All Servers have the same Directory Integration settings - the Domain Subtree Base DN is o=acme for all Servers.
• The actual o=acme record is created in the Main Local Storage Unit on the Directory Hosting Server.
• The Directory records for:
  • the dom1.dom Domain created on the SV1 Server,
  • the dom2.dom Domain created on the SV2 Server, and
  • the dom3.dom Domain created on the Directory Hosting Server
  are stored in the Main Local Storage Unit on the Directory Hosting Server

When several CommuniGate Pro Servers use a Shared Directory to keep all their Domain Integration Records, these Servers can be used to serve the same Domain (or the same Domains). Such a Domain is called a Distributed Domain, and each Server hosts a subset of that Domain Accounts. The Distributed Domain should not be a Main Domain of any CommuniGate Pro Server:
In this example:

• Three CommuniGate Pro Servers (with the sv1.corp.dom, sv2.corp.dom, and sv3.corp.dom Main Domains) all have the same corp.dom Secondary Domain. Some Accounts are created in the corp.dom Domain on each Server.
• The Domain Subtree Base DN is set to an empty string (<root>) on all CommuniGate Pro Servers.
• The Shared Directory is hosted on a separate device/server, but in reality one of the CommuniGate Pro Servers can act as the Shared Directory Host.
• The Directory Integration option of the corp.dom Domain is set to Keep In Sync on all Servers.

When an Account is created, renamed, removed, or updated on one of the sv*.corp.dom 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.dom Servers.

When any Server creates an Account and places a record into the Shared Directory, it stores the Server Main Domain name as the record hostServer attribute.

The Shared Directory can be used to route Distributed Domain mail to the proper location (Server). Open the General page in the WebAdmin Settings realm, then open Cluster settings page, and enable the Directory-Based Clustering. The address routing mechanism is modified:

• When the CommuniGate Pro Server receives a mail for one of its local Domains, it checks if a local Domain object (Account, Alias, Mailing List, Group, Forwarded) exists.
• If no local object is found in the addressed Domain, the Server checks the Directory.
• If the Directory contains a record for the specified object (uid=objectName,cn=domainName), the record hostServer attribute is checked.
• If the hostServer attribute is absent, or if it contains the Main Domain Name of this CommuniGate Pro Server, an error message is generated. Otherwise, the address is rerouted to the proper relaying module (SIP or SMTP), to the remove server with the hostserver name.

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 specified in the hostServer attribute of the Account Directory record.

Note: the names and IP addresses for "distributed" systems should be entered into the "Static Members" table on the Clusters WebAdmin page.

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. Open the Distributed Domain Settings, and set the Mail/Signal To Unknown options to

Reroute To: *%domain.dom@mainserver._via

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 Accounts are created in, renamed, or removed from a Distributed Domain, and when a WebMail, XIMSS, SIP, 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 recommended to use Directory-based Domains for Distributed Domains if connections between "remote location" Servers and the Shared Directory are slow and/or unreliable.

The Distributed Domains concept is the foundation of the CommuniGate Pro Static Clusters.

For small Distributed Domains, routing can be implemented 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:

; SV2 accounts
<dan@corp.dom>  =  dan%corp.dom@sv2.corp.dom._via
<ed@corp.dom>   =   ed%corp.dom@sv2.corp.dom._via
<fred@corp.dom> = fred%corp.dom@sv2.corp.dom._via
;
; SV3 accounts
<gil@corp.dom>  =  gil%corp.dom@sv3.corp.dom._via
<hugh@corp.dom> = hugh%corp.dom@sv3.corp.dom._via
<judy@corp.dom> = judy%corp.dom@sv3.corp.dom._via

While this method does not require any Directory activity, it is hardly acceptable for Domains with more than few dozen 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.dom, ed-uk@corp.dom, fred-uk@corp.dom, etc.), routing for all SV2 Accounts can be specified with one Router record:

<*-uk@corp.dom> = *-uk%corp.dom@sv2.corp.dom._via

The CommuniGate Pro Dynamic Cluster maintains cluster-wide Directory Integration settings: the cluster-wide Attribute Renaming table, Domain Subtree, and Custom Attributes settings are used with all Accounts in Shared Domains, while "regular" settings are used for all Accounts in "local" Domains.

When you open the Directory Integration WebAdmin page on a Cluster Member, the page contains a link that allows you to switch the Cluster-wide Settings.