Definition

For Messaging Server, this attribute specifies the canonical domain name used to map a user entry to the correct organization entry when more than one organization entry exists.

The mail processes use information stored in the organization entry to locate a user's mailbox in the message store. If a user has multiple identities in different domains (associated with the different organization entries), the mail processes need to determine which organization entry to use to find the correct mailbox. The inetCanonicalDomainName attribute points to this canonical organization. If inetCanonicalDomainName were not used, a user with multiple user IDs (in multiple domains) would have a different mailbox for each domain.

Typically, the value of inetCanonicalDomainName is a fully qualified domain name, although this is not an absolute requirement.

The inetCanonicalDomainName attribute is used in LDAP Schema 2 and LDAP Schema 1. For an explanation of Schema 1 and Schema 2 LDAP structures, see the Sun Java Communications Suite Deployment Planning Guide and Sun Java Communications Suite Schema Migration Guide.

Schema 2

In Schema 2, the directory can have two types of organization nodes: base and index. Base nodes appear at the root of the directory tree and contain the organization's data (users and groups).

Typically, index nodes for the organization are created if a deployment involves more than one logical grouping of the same physical data. An index node can appear anywhere in the directory.

Moreover, some LDAP administrators need to create a directory structure in which one organization node is placed above another, and the user data exists below both organization nodes. (You might have to do this to maintain the structure of a legacy user directory or to merge an existing user domain with a recently acquired domain.)

If the directory contains multiple index nodes for the organization or nested organization nodes, a user entry can “belong” logically to more than one organization node. An application such as Messaging Server must determine which organization is the canonical one in order to resolve a domain search and correctly identify the user's mailbox.

In this situation, you must decorate all the non-canonical organization entries with the inetCanonicalDomainName attribute, which specifies the domain name of the organization's base node. Its value must be the same as that of the sunPreferredDomain attribute in the organization's base node.

If the inetCanonicalDomainName attribute is missing and there are multiple organization nodes referring to the organization's base node, the mail processes could possibly use the wrong domain name when trying to open users’ mailboxes.

Note that it serves no purpose to decorate the canonical domain entry itself with the inetCanonicalDomainName attribute. If you do, it must have the same value as sunPreferredDomain.

If you want multiple domains to have the same attribute settings, you should not create multiple organization nodes. Instead, add associatedDomain to the organization's base node to specify the DNS domain name aliases. (Add one instance of associatedDomain for each domain name alias.) If the organization's base node is not the canonical domain, then it must contain the sunPreferredDomain attribute.

Schema 1

In Schema 1, the inetCanonicalDomainName attribute is used for the same purpose as in Schema 2, but it is used with DC nodes in the DC tree.

This attribute is used when more than one DC node in a DC tree refers to the same base node of a user/group tree for a particular domain in the Organization tree. (There can be only one canonical domain name for a domain's user/group base node in the Organization tree, but there can be many DC nodes referring to the same user/group base node.)

In Schema 1, this attribute is not necessary if there is only one DC node referring to a domain's user/group base node. If the attribute is missing, the DC node entry is taken for the canonical domain name.

If this attribute is missing and there are multiple DC nodes referring to the same user/group base node, the mail processes could possibly use the wrong domain name when trying to open users’ mailboxes.

Using multiple domain nodes to point to the same user/group base node allows you to have different attribute settings (for example, to achieve different routing) for each one. If you want to be sure the two domains have the same attribute settings (for example, to ensure that they are routed identically), use aliasedObjectName on the duplicate node instead.