InetCanonicalDomainName LDAP Attribute
- directory string (UTF-8), single-valued
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.
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.
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.
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
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
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.
Example 1 - Schema 2
Suppose the directory contains a base node,
o=sesta, to store a corporation's user data. In addition, there is an index node,
o=sesta2, which points to an overlapping subset of users. In this example,
sesta.com is the canonical domain name.
To identify the actual organization node, you must decorate the non-canonical organization entry (the index node) with the value of the canonical organization node,
dn:o=sesta2,o=sesta,o=rootsuffix inetDomainBaseDN:o=sesta,o=rootsuffix inetCanonicalDomainName:sesta.com
Example 2 - User Login with inetCanonicalDomainName
Assume the two organization nodes,
o=sesta2, are decorated as shown in Example 1. The user
jdoe logs in to Messaging Server with the following user ID:
In this example, there can be only one LDAP entry for the user
In this case, Messaging Server performs one or more lookups to determine
jdoe's canonical user ID, which consists of the user's
uid followed by @ and the user's canonical domain name.
Messaging Server looks up the value of the
inetCanonicalDomainName attribute in the
sesta2 organization entry. It then replaces the original domain name in the login ID,
sesta2, with the canonical domain name,
Using the canonical user ID, Messaging Server opens
jdoe's correct mailbox, which displays all of
jdoe's messages, including messages sent to
firstname.lastname@example.org, and to any other domain or alias domain associated with
Example 3 - User Login without inetCanonicalDomainName
Assume the same directory tree layout as is shown in Example 1, but now
inetCanonicalDomainName is not used. The user
jdoe logs in to Messaging Server with the following user ID:
As in Example 2 (shown above), there can be only one LDAP entry for the user
In this case, Messaging Server performs the same lookups it performs in Example 2.
However, because the
sesta2 organization entry does not contain the
inetCanonicalDomainName attribute, Messaging Server uses the user ID
<uid>@sesta2.com to determine which mailbox to open. A second mailbox associated with the
sesta2 domain is created (or, if it already exists, opened).
In this mailbox, the user
jdoe sees only messages sent to the
jdoe has no access to any other messages. All other messages are contained in the mailbox associated with the canonical domain.
Example 4 - Schema 1
In a Schema 1 scenario, if two DC Tree nodes exist,
dc=sesta2, both referring to the user/group base node
o=sesta, then you must specify the canonical domain name as follows:
dn:dc=sesta2,dc=com,o=internet inetDomainBaseDN: o=sesta.com inetCanonicalDomainName:sesta.com