test

Comparison of Sun Java System LDAP Schema Modes for Communications Suite Products

Differences Between the Three Schema Modes

This section contains more information about the three schema types described earlier: Schema version 1, Schema version 2 native mode and Schema version 2 compatibility mode. This section contains the following topics:

For more detailed information about domain structures for Schema version 1 mode and Schema version 2 mode, see the inetCanonicalDomainName in Sun Java Communications Suite 5 Schema Reference.

How Domain Searches Work

Schema version 1 mode

The DC tree domain entry is found using an LDAP lookup. Messaging Server lookup code builds the DN needed for the lookup using the domain specified to the right of the separator (@) in the email address. For Calendar Server the DN is created from the domain name in the fully qualified unique identifier, uid. Once retrieved, the entry is processed as described in How Alias Domains Are Handled In Schema Version 1 Mode.

Tip –

For Messaging Server, if the original search did not find a match in the DC tree, the DOMAIN_UPLEVEL option can be used to search a domain from one level higher in the tree. You must set this option to a value of either 1 or 3 to enable uplevel searches. The default is for this feature to be turned off.

For more information on this option, see the Sun Java System Messaging Server 6.3 Administration Guide.

Schema version 2 native mode

This mode implements the Access Manager model, with all domain nodes residing directly below the root node. Messaging Server and Calendar Server retrieve the correct LDAP domain entry using a search template. The system compares each node with the search criteria until it finds the correct domain. All domains are treated as if they were at the same level. There is no hierarchical structure for retrieval. once retrieved, the entry is processed as described in How Alias Domains are Handled in Schema Version 2 Native Mode.

Schema Version 2 compatibility mode

Search queries are constructed using templates as with native mode, but the LDAP entry retrieved is in the DC tree. Once retrieved, the domain LDAP entry is processed as if it were Schema version 1 mode. For more information, see How Alias Domains are Handled in Schema Version 2 Compatibility Mode.

Note –

While earlier Calendar Server versions supported multiple domains, it was optional. In a non-domain environment, all user and group records are located directly under the root, with no domain node present. However, starting with Calendar Server 6.3, the system default is for multiple domains. That is, the system assumes at least one domain below the root for all schema modes.

How Alias Domains Are Handled In Schema Version 1 Mode

When the system finds the DC tree domain node with the appropriate name, it checks to see if it's an alias, index node, or the canonical domain. The canonical DC tree domain has the same name as the Organization tree containing the user and group records. This is the official name of the domain. For Messaging Server, this canonical domain name determines the name of the domain in the message store hierarchy where users' inboxes are located. The system retrieves the DN for the corresponding Organization tree domain from the inetDomainBaseDN attribute found in the DC tree canonical domain.

If the DC tree domain does not have the same name as the corresponding Organization tree domain, it is not the canonical domain. It is an alias, or an index node, and must carry either the inetCanonicalDomainName attribute or the aliasedObjectName attribute.

When a DC tree domain node carries the aliasedObjectName attribute, it is an alias that contains no routing or access control information. The attribute value is used to find the DC tree canonical domain node where the routing and access control information for this alias resides.

When a DC tree domain node carries the inetCanonicalDomainName attribute, it is an index node. This type of alias contains its own routing and access control information, which can be different than the information carried on the DC tree canonical domain. The system uses the value of the inetCanonicalDomainName attribute to find the name of the Organization tree domain node, under which user and group records for this index node alias reside.

If neither the aliasedObjectName attribute, nor the inetCanonicalDomainName attribute is present in the DC tree domain, then the system assumes it is the canonical domain and uses the value of the inetDomainBaseDN attribute to find the Organization tree domain.

How Alias Domains are Handled in Schema Version 2 Native Mode

In Schema version 2 native mode, as implemented for use with Access Manager, no hierarchy is allowed. That is, all domain nodes (base nodes) must reside directly below the root node. Index nodes are not allowed. This means a loss of functionality from Schema version 1 mode since index nodes containing alternate routing and access control information can't be created. However, aliases with the same routing information as the base node can be created by adding one associatedDomain attribute for each alias domain name to the Organization node domain entry. Note that the inetCanonicalDomainName attribute is not used.

In Schema version 2 native mode without Access Manager, both base and index nodes can be created in the Organization tree using a hierarchical structure. Index nodes can contain different routing and access control information, similar to index nodes found in the DC tree for Schema version 1 mode. Index nodes are decorated with the inetCanonicalDomainName attribute, as in Schema version 1 mode. However, the alias domains found in Schema version 1 mode don't exist in Schema 2 native mode. They have been replaced by the use of the associatedDomain attribute decorating the canonical domain.

How Alias Domains are Handled in Schema Version 2 Compatibility Mode

In Schema version 2 compatibility mode, the domain structure is the same as in Schema version 1 mode. Aliasing works the same way as described for Schema version 1 mode. The only difference is that the Organization tree domain nodes each carry an icsStatus attribute.