10.3 How the Multiple Domains Feature in Calendar Server Version 6.3 Influences Your Schema Choices

This section contains conceptual information you can use to better understand the process for implementing multiple domains and what it has to do with choosing a schema version.

This section contains the following topics:

10.3.1 Overview of Multiple Domains and the Implications for Schema Choice for Calendar Server Version 6.3

With a multiple domain installation, the LDAP directory is organized into distinct, non-intersecting sections, each of which represents a domain found in the Domain Name System (DNS). User, group and resource unique IDs are unique within each domain. For example, there can be only one user in each domain with the uid of jdoe. A distinguished name (DN) is a fully qualified domain name.

Calendar Server supports both of these LDAP directory schema versions: Schema version 1 and Schema version 2. When you run the Directory Server Setup script (comm_dssetup.pl), you can choose either LDAP Schema version 1 or LDAP Schema version 2. Use Schema version 2, unless you have specific reasons for using Schema version 1

The following are two reasons to use Schema version 1:

You already have Schema version 1 and you are not planning on using Delegated Administrator for populating LDAP.
You already have Schema version 1 and you are not planning to use Access Manager features.

10.3.2 Sun LDAP Schema Version 2 for Calendar Server Version 6.3

The following graphic shows an LDAP directory organization for a multiple domain installation that uses Sun LDAP Schema version 2.

Figure 10–1 LDAP Directory Organization Using LDAP Schema Version 2

This diagram shows an example of a pure Schema version
2 environment using only a single tree, an Organization tree, and no DC tree.

LDAP Schema version 2 uses a flat LDAP directory organization, that is, the domains are all at the same level; they are not nested. For a multiple domain installation, the first level entries (as shown by varriusDomain, sestaDomain, and siroeDomain in the graphic) must be parallel in the directory organization. These entries cannot be nested.

If you want to use Access Manager features such as single sign-on (SSO), or use Delegated Administrator to provision users, Schema version 2 is required. However, there is a hybrid variation, a two tree scheme that uses both the DC tree and the Organization tree, much like Schema version 1, but it uses the Schema version 2 object classes and attributes. This is Schema version 2 compatibility mode, which is called Schema version 1.5 in the configuration program (csconfigurator.sh).

10.3.3 Sun LDAP Schema Version 1 for Calendar Server Version 6.3

The graphic that follows shows an example of an LDAP directory organization for a multiple domain installation that uses Sun LDAP Schema version 1.

This organization includes two trees for domain management:

DC tree
Organization (OSI) tree

Figure 10–2 LDAP Directory Organization Using LDAP Schema Version 1

This diagram shows an example of a two tree, Schema version
1, LDAP organization.

The DC tree (node) is similar to the DNS, which determines a domain entry given the domain name. The inetdomainbasedn LDAP attribute points to the base DN, which is the root of the domain’s users, resources and groups in the organization tree (node). Within each domain, the identifiers for Calendar Server users, resources, and groups must be unique.

Note –

If your earlier LDAP configuration did not contain a DC tree, in order to use Schema version 1 mode or Schema version 2 compatibility mode, you must create the DC tree nodes yourself as explained in 10.2 Setting up a Multiple Domain Environment for Calendar Server Version 6.3 for the First Time. However, Schema version 2 is the preferred mode.

In a multiple domain installation using LDAP Schema version 1, a directory search requires these two steps to find an entry:

In the DC tree, the search operation locates the domain entry that contains the value of the DN pointing to the base DN (inetDomainBaseDN attribute) of domain in the organization tree.
In the organization tree, the search operation locates the domain entry and then searches from that entry’s base DN to find the user, resource, or group within the domain.