Sun Java System Calendar Server 6.3 Administration Guide

Chapter 10 Setting Up a Multiple Domain Calendar Server 6.3 Environment

This chapter contains overview material and instructions on how to set up a multiple domain environment for the first time.

Tip –

In the past, domains in a multiple domain environment have been referred to as both hosted domains, and virtual domains. These terms are interchangeable in this document.

This chapter covers the following topics:

10.1 Overview of Multiple Domains in Calendar Server Version 6.3

Calendar Server 6.3 features multiple domains as the default, and only, way to organize your user and group LDAP entries. That is, you must have at least one domain under the root node and all of your user and group entries must reside under a domain node. In earlier versions of Calendar Server, the use of domains to contain user and group entries was optional. You could run Calendar Server without using domains at all. That is no longer true for Calendar Server 6.3; you must have at least one (default) domain.

In a multiple domain environment, each domain shares the same instance of the Calendar Server system, which allows multiple domains to exist on a single server. Each domain defines a name space within which all users, groups, and resources are unique. Each domain also has a set of attributes and preferences that you specifically set. All user and calendar IDs for domains must be fully qualified.

The configuration program asks you for the necessary information to set up the default domain. When the configuration program is done and you have created all of the domains you need, before copying your user and group LDAP entries to the desired domains, you must prepare the user and group entries by running the migration utilities to convert your non-domain user and group LDAP entries to domain ready user and group entries. The utilities to run are csmig and csvdmig.

If you are upgrading to Calendar Server 6.3 from a non-domain version of Calendar Server, you have several choices to make:

You can choose to move to a single default domain mode.

In which case, you must move your user and group records under the domain node in LDAP.
You can choose to move to a multiple domain mode and distribute the users and groups amongst multiple domains.

Use Delegated Administrator to create more domains.

If you wish to distribute your existing users into multiple domains, you need to run the migration utilities to add fully qualified domain names to your database user IDs and calendar IDs. This way you can distribute your users among the domains you created with Delegated Administrator. Create the domains before you run the configuration program.

If you had hosted (multiple) domains set up prior to upgrading to the current version, your user IDs and calendar IDs need not be altered. However, there are some new ics.conf parameters that need to be configured, as shown in the following section:10.4 Additional Parameters Required for Multiple Domain Mode in Calendar Server Version 6.3.

Caution –

If your site is currently configured for multiple instances of Calendar Server on a single machine, or if you have implemented a limited virtual domain mode, contact your Sun Microsystems sales account representative for an evaluation of your migration requirements.

10.2 Setting up a Multiple Domain Environment for Calendar Server Version 6.3 for the First Time

To move from a non- or single domain environment to a multiple domain environment, you might need to perform the following tasks before creating any LDAP entries:

Run the database migration utilities.

If you are migrating from Calendar Server version 5, be sure that you have already run csmig, csvdmig, cs5migrate, and cs5migrate before attempting to set up multiple domains. For more information on these migrations utilities, see Chapter 3, Database Migration Utilities for Calendar Server 6.3.
Run the comm_dsseetup.pl if you have not already done so.
Log in as an administrator with permission to change the configuration.
Stop Calendar Server services by issuing the stop-cal command.

Edit the ics.conf file to enable multiple domains.

The following table lists and describes the configuration parameters in the ics.conf file used for multiple domain support. If any of the parameters listed in this table are not in the ics.conf file, add the parameter and its associated value to the file and then restart Calendar Server for the values to take effect.

Parameter	Description
`service.virtualdomain.support`	Enables (`"yes"`) support for multiple domains. Default is `"yes"`. Note – Do not change this parameter to `“no”` even if you are going to operate in a single domain. The current version of Calendar Server requires this to be `“yes”`.
`local.schemaversion`	Specifies the version of the LDAP schema: `"1"` for 10.3.3 Sun LDAP Schema Version 1 for Calendar Server Version 6.3. See also `service.dcroot`. `"1.5"` or `"2"` for 10.3.2 Sun LDAP Schema Version 2 for Calendar Server Version 6.3. See also `service.schema2root`. Default is `"2"`.
`service.dcroot`	For multiple domain support, this replaces `local.ugldapbasedn` and `local.authldapbasedn`. If `local.schemaversion="1"` or `local.schemaversion="1.5"`, specifies the root suffix of the DC tree, underneath which all domains are found. For example: `"o=internet"`.
`service.schema2root`	if `local.schemaversion="2"`, specifies the root suffix of the Organization Tree, underneath which all domains are found. For example: `"o=sesta.com"`.
`service.defaultdomain`	Specifies the default domain for this instance of Calendar Server. Used when a domain name is not supplied during a login. For example: `"red.sesta.com"`.
`service.loginseparator`	Specifies a string of separators used for the `login-separator` when Calendar Server parses `"userid[login-separator]domain"`. Calendar Server tries each separator in turn. Default is `"@+"`.
`service.siteadmin.userid`	Specifies the user ID of the domain administrator. For example: `DomainAdmin@sesta.com`.
`service.virtualdomain.scope`	Controls cross domain searching: `"primary"` Search only within the domain where the user is logged in. `"select"` Search in any domain that allows the search. Default is `"select"`.
`local.domain.language`	Specifies the language for the domain. Default is `"en`" (English).

Create a default domain entry.

For Schema version 2, the default domain is created by the Delegated Administrator configuration program (config-commda).

For Schema version 1, create a default domain (one of your multiple domains), placing it one or more levels under your DC tree root suffix, depending on your DC tree structure. For example, if your root suffix is o=internet, then the next level down node could be com, as shown in 10.3.3 Sun LDAP Schema Version 1 for Calendar Server Version 6.3. However, your default domain would be one node lower, such as sesta.com. Use csdomain to create DC tree nodes, as illustrated in the example that follows:
```
csdomain -n o=com,dc=com,o=internet create comcsdomain
    -n o=sesta.com,dc=sesta,dc=com,o=internet create sesta.com
```
Enable calendaring services for the default domain entry.

For Schema version 1: Add the icsCalendarDomain object class to the o=sesta.com domain entry in LDAP using csattribute.

For Schema version 2: After configuring Delegated Administrator, modify the default domain (created by the Delegated Administrator configuration program) to add Calendar (and Mail) services. In the following example, calendar and mail services are added to a domain:

commadmin domain modify -D admin -w passwd -d defaultdomain -S cal,mail
Create as many domains as you want on your system.

For instructions on how to add a domain in Schema version 2 mode, see 13.2 Creating New Calendar Server Domains.

To create a Schema version 1 domain, use csdomain create, as illustrated in the example that follows:
```
csdomain -n o=red.sesta.com,dc=red,dc=sesta,dc=com 
   create red.sesta.com
```
Add calendar (and mail, if wanted) services for the new domains.
Create the calmaster site administrator user if it does not already exist.

For Schema version 2, create the calmaster user using the commadmin user create command as illustrated in the following example:
```
commadmin user create -D admin -w passwd -F Calendar
    -L Administrator -l calmaster -W calmasterpasswd -d sesta.com -S cal
```
Note –
To create the calmaster using the Delegated Administrator Console's Create New User wizard, see the Delegated Administrator online help.

For Schema version 1, create the calmaster user on the organization tree with csuser as illustrated in the following example:
```
csuser o=sesta.com,o=rootsuffix -d sesta.com
    -g Calendar -s Administrator -ycalmasterpasswordcreate calmaster
```
If the calmaster site administrator user already exists from an earlier non-domain environment (Schema version 1), move it to the default domain by performing the following steps:
1. Perform an LDAP dump of the existing calmaster LDAP entry and save it in a temporary file, such as /tmp/calmaster.ldif.
2. Delete the existing calmaster LDAP entry on the organization tree root suffix using ldapdelete, as follows:
```
#ldapdelete -D "cn=Directory Manager" -w password 
   uid=calmaster,ou=People,o=rootsuffix
```
3. Modify the calendar administrator’s group entry (update the uniqueMember attribute) to reflect the changes as shown in the LDIF example that follows:
  dn:cn=Calendar Administrators,ou=Groups,o=rootsuffix changetype:modifyreplace:uniqueMember uniqueMember:uid=calmaster,ou=People,o=sesta.com,o=rootsuffix
  It is not necessary to move the administrator's group entry to the domain.
Update any administration scripts you have so that all calendar IDs (calid) in the WCAP commands are fully qualified. That is, each calid must now include the domain name. For example: jsmith@sesta.com.

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.

10.4 Additional Parameters Required for Multiple Domain Mode in Calendar Server Version 6.3

Starting with Calendar Server 6 , every deployment is configured for multiple domains. If you are upgrading from an older version of Calendar Server, and did not have hosted (multiple) domains configured, you must add the parameters, as shown, for your schema mode:

10.4.1 Schema Version 1 Parameter Additions for Calendar Server Version 6.3

The following list of parameters should be added to the configuration file (ics.conf), if they do not already exist.

service.dcroot

service.defaultdomain

service.loginseparator

service.virtualdomain.support set to "yes"

service.virtualdomain.scope

service.siteadmin.userid

service.siteadmin.cred

local.schemaversion set to "1"

10.4.2 Schema Version 2 Parameter Additions for Calendar Server Version 6.3

The following list of parameters should be added to the configuration file (ics.conf), if they do not already exist:

service.dcroot

service.defaultdomain

service.loginseparator

service.virtualdomain.support set to "yes"

service.virtualdomain.scope

service.siteadmin.userid

service.siteadmin.cred

local.schemaversion set to "2"

service.schema2root

10.5 Calendar Server 6.3 Logins

For a multiple 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.

If autoprovisioning 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 D.9.3 LDAP Attributes and Property Names.

10.6 Migrating from a Non-Domain Environment in Calendar Server Version 6.3

In Calendar Server version 5.0 and earlier, there were no domains. Therefore, the user and calendar ID's were not required to be fully qualified. That is, they did not need a domain name to be part of the ID such as jdoe@domain.com. If your uid's and calid's were not fully qualified before installing the current version of Calendar Server, your data does not have to be altered. The system assumes any unqualified uid's and calid's it encounters to belong to the default domain. If you want to implement multiple domains, however, you must migrate your LDAP and components databases to indicate which domain each user belongs to.

In addition, your data might need to be migrated in other ways. There are several migration programs. Check the migration information found in Chapter 3, Database Migration Utilities for Calendar Server 6.3.