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:
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:
- 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:
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:
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:
- 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:
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
<[email protected]> = dan%[email protected]._via
<[email protected]> = ed%[email protected]._via
<[email protected]> = fred%[email protected]._via
;
; SV3 accounts
<[email protected]> = gil%[email protected]._via
<[email protected]> = hugh%[email protected]._via
<[email protected]> = judy%[email protected]._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 ( [email protected],
[email protected], [email protected], etc.), routing for all SV2 Accounts
can be specified with one Router record:
- <*[email protected]> = *-uk%[email protected]._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.
|
