inetCanonicalDomainName
Origin
Messaging Server 5.0
Syntax
cis, single-valued
Object Classes
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.
Examples
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, inetCanonicalDomainName:sesta.com:
dn:o=sesta,o=rootsuffix sunPreferredDomain:sesta.com
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=sesta and o=sesta2, are decorated as shown in Example 1. The user jdoe logs in to Messaging Server with the following user ID:
jdoe@sesta2.com
In this example, there can be only one LDAP entry for the user jdoe.
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, sesta.
Using the canonical user ID, Messaging Server opens jdoe's correct mailbox, which displays all of jdoe's messages, including messages sent to jdoe@sesta2.com, to jdoe@sesta.com, and to any other domain or alias domain associated with jdoe.
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:
jdoe@sesta2.com
As in Example 2 (shown above), there can be only one LDAP entry for the user jdoe.
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 sesta2 domain; 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=sesta and dc=sesta2, both referring to the user/group base node o=sesta, then you must specify the canonical domain name as follows:
dn:dc=sesta,dc=com,o=internet inetDomainBaseDN:o=sesta.com
dn:dc=sesta2,dc=com,o=internet inetDomainBaseDN: o=sesta.com inetCanonicalDomainName:sesta.com
OID
2.16.840.1.113730.3.1.701
- © 2010, Oracle Corporation and/or its affiliates