InetCanonicalDomainName LDAP Attribute



 Syntax 

 directory string (UTF-8), single-valued 

 OID 

 2.16.840.1.113894.1009.1.101.0.1053.1.1 



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&#x27;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  attribute points to this canonical organization. If  were not used, a user with multiple user IDs (in multiple domains) would have a different mailbox for each domain.

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

The  attribute is used in LDAP Schema 2 and LDAP Schema 1. For an explanation of Schema 1 and Schema 2 LDAP structures, see the  and.

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&#x27;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&#x27;s mailbox.

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

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

Note that it serves no purpose to decorate the canonical domain entry itself with the  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  to the organization&#x27;s base node to specify the DNS domain name aliases. (Add one instance of  for each domain name alias.) If the organization&#x27;s base node is not the canonical domain, then it must contain the   attribute.

Schema 1

In Schema 1, the  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&#x27;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&#x27;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&#x27; 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  on the duplicate node instead.

Example 1 - Schema 2

Suppose the directory contains a base node,, to store a corporation&#x27;s user data. In addition, there is an index node,, which points to an overlapping subset of users. In this example,  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=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,  and , are decorated as shown in Example 1. The user  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 &#x27;s canonical user ID, which consists of the user&#x27;s   followed by @ and the user&#x27;s canonical domain name.

Messaging Server looks up the value of the  attribute in the   organization entry. It then replaces the original domain name in the login ID,, with the canonical domain name,.

Using the canonical user ID, Messaging Server opens  correct mailbox, which displays all of  &#x27;s messages, including messages sent to , to  , 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  is not used. The user  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  organization entry does not contain the   attribute, Messaging Server uses the user ID   to determine which mailbox to open. A second mailbox associated with the  domain is created (or, if it already exists, opened).

In this mailbox, the user  sees only messages sent to the   domain;   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,  and , both referring to the user/group base node  , 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