Overview of Hosted Domains

This section provides an overview of hosted domains, including:

• Organization of the LDAP Directory

• Calendar Server Logins

• Cross Domain Searches

• Support for a Non-Hosted Domains Environment

Organization of the LDAP Directory

With a hosted 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 uids 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) describes the root of each domain.

Calendar Server supports both of these LDAP directory schema versions for hosted domains:

• Sun LDAP Schema 2 (compatibility or native mode)

• Sun LDAP Schema 1

When you run the Directory Server Setup script (comm_dssetup.pl), you can choose either LDAP Schema 1 or LDAP Schema 2. Several considerations are:

• New Installation — If your site is installing Calendar Server 6 2005Q4 as a new installation, use LDAP Schema 2.

• Upgrade — If your site is upgrading from Calendar Server version 5, use the schema version as follows:

  • If you want to use Access Manager features such as single sign-on (SSO), or if you want to use Delegated Administrator, choose LDAP Schema 2.

  • If you do not have hosted domains, don’t want to use Access Manager features, or don't want to provision users with Delegated Administrator, you can use either schema version. However, use LDAP Schema 2, if possible.

Sun LDAP Schema 2

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

Figure 11–1 LDAP Directory Organization Using LDAP Schema 2

LDAP Schema 2 uses a flat LDAP directory organization, that is, the domains are all at the same level; they are not nested. For a hosted 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 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 1, but it uses the Schema 2 object classes and attributes. This is Schema 2 compatibility mode, which is called Schema 1.5 in the configuration program (csconfigurator.sh).

Sun LDAP Schema 1

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

This organization includes two trees for domain management: a DC tree and an Organization tree (OSI)

• DC tree

• Organization (OSI) tree

Figure 11–2 LDAP Directory Organization Using LDAP Schema 1

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.

If your earlier LDAP configuration did not contain a DC tree, in order to use Schema 1 mode or Schema 2 compatibility mode, you must create the DC tree nodes yourself as explained in Setting up a Hosted Domain Environment.

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

1. 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.

2. 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.

Calendar Server Logins

For a hosted domain installation, each user must have a user ID (uid) that is unique within the domain. A login to Calendar Server uses the following format:

userid[@domain-name]

If domain-name is omitted, Calendar Server uses the default domain name specified by the service.defaultdomain parameter in the ics.conf file. Thus, if a user is logging into the default domain, only the userid is required.

For an installation with a non-hosted domain environment, domain-name is not required. If a domain name is specified, it will be ignored.

If auto-provisioning is enabled, the first time a user logs in, Calendar Server creates a default calendar for the user. For information about calendar creation, see Chapter 15, Administering Calendars.

Login permission is based on the icsStatus or icsAllowedServiceAccess attribute. For more information, see LDAP Attributes and Property Names.

Cross Domain Searches

By default, users can search only within their domain for users and groups to invite to events. Cross domain searches, however, allow users in one domain to search for users and groups in other domains, as long as these requirements are met:

• Each domain can specify an access control list (ACL) in the domainAccess property of the icsExtendedDomainPrefs attribute that grants or denies cross domain searches from other domains. Thus, a domain can allow or disallow either specific domains, or all domains, from searching it.

  For a description of domainAccess, see LDAP Attributes and Property Names. For general information about ACLs, see Access Control Lists (ACLs).

• Each domain can specify the external domains its users can search. The icsDomainNames LDAP attribute specifies the external domains that a domain’s users can search when looking for users and groups (as long as the ACL for the external domain allows the search).

  For example, if icsDomainNames for the various.org domain lists sesta.com and siroe.com, users in various.org can perform cross domain searches in sesta.com and siroe.com. For a description of icsDomainNames, see LDAP Attributes and Property Names.

For instructions on how to enable cross domain searches, see Enabling Cross Domain Searches.

Support for a Non-Hosted Domains Environment

Calendar Server still supports operating in a non-hosted domains (that is, having a single domain) environment. For example, if you had an existing Calendar Server version 5 or earlier legacy installation, you can still operate in the single domain environment by setting the ics.conf parameter service.virtualdomain.support to "no". See also, Enabling Hosted Domains.

You will, however, still need to migrate the legacy version components database to the current version. For migration information, see the Chapter 4, Database Migration Utilities.