test

Sun Java System Calendar Server 6 2005Q4 Administration Guide

Chapter 11 Setting Up Hosted Domains

Calendar Server supports hosted (or virtual) domains. In a hosted domain installation, each domain shares the same instance of Calendar Server, 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.

This chapter describes these topics:

Note –

The Sun Java System Communications Services 6 2005Q4 Deployment Planning Guide discusses all the steps necessary to prepare your installation to use hosted domains.

Caution – Caution –

If your site is currently configured for multiple instances of Calendar Server or for limited virtual domain mode, contact your Sun Microsystems sales account representative for an evaluation of your migration requirements.

Overview of Hosted Domains

This section provides an overview of hosted domains, including:

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:

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:

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

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

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)

Figure 11–2 LDAP Directory Organization Using LDAP Schema 1

This diagram shows an example of a two tree, Schema 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 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:

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.

Setting up a Hosted Domain Environment

This section covers the basic tasks that you might need to perform before creating new hosted domain entries in your LDAP:

  1. Run the database migration utilities.

    If you are migrating from Calendar Server version 5, be sure that you have already run cs5migrate, csmig, and csvdmig before attempting to set up hosted domains. You can get the latest version of cs5migrate from Sun’s technical support. For more information on these migrations utilities, see Chapter 4, Database Migration Utilities.

  2. Run comm_dsseetup.pl if you have not already done so.

    It updates the ics.conf file with the parameters needed to support hosted domains.

  3. Edit the ics.conf file to enable hosted domains.

    The following table lists and describes the configuration parameters in the ics.conf file used for hosted 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") or disables ("no") support for hosted (virtual) domain mode. Default is "no".

    local.schemaversion

    Specifies the version of the LDAP schema: 

    service.dcroot

    Specifies the root suffix of the DC tree in the LDAP directory, if local.schemaversion="1".

    For example: "o=internet".

    In hosted (virtual) domain mode, Calendar Server uses the service.dcroot parameter and not the local.ugldapbasedn and local.authldapbasedn parameters.

    Conversely, in non-hosted (virtual) domain mode, Calendar Server uses the local.ugldapbasedn and local.authldapbasedn parameters and not the service.dcroot parameter.

    service.schema2root

    Specifies the root suffix underneath which all domains are found, if local.schemaversion="2".

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

  4. Create a default domain entry.

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

    For Schema 1, create a default domain (one of your hosted domains) 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 Sun LDAP Schema 1. 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

  5. Enable calendaring services for the default domain entry.

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

    For Schema 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 hosted domain:

    commadmin domain modify -D admin -w passwd -d defaultdomain -S cal,mail

  6. Create the hosted domains you want on your system.

    For instructions on how to add a hosted domain in Schema 2 mode, see Creating New Hosted Domains.

    To create a Schema 1 hosted 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

  7. Enable calendaring services for the new hosted domains, as explained in Setting up a Hosted Domain Environment.

  8. Create the calmaster site administrator user if it does not already exist.

    For Schema 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 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

  9. If the calmaster site administrator user already exists from an earlier non-hosted domain environment (Schema 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 group entry to the hosted domain.

  10. Update any administration scripts you have so that calids in the WCAP commands are fully qualified. That is, each calid must now include the domain name. For example: jsmith@sesta.com.

Using Domains Created by Messaging Server

If Messaging Server has already created hosted domains, they can be calendar enabled for either Schema 1 or Schema 2. This section covers the following topics:

Enabling Calendaring in Schema 1 Messaging Domains

To enable domains for calendaring, add the following object class and two attributes to the LDAP domain entry for each domain you want enabled for calendar:

You can do this in one of two ways: use csattribute add command or use ldapmodify as shown in the example that follows:


dn:dc=sesta,dc=com,o=internet
 changetype:modify
 add:objectclass
 objectClass:icsCalendarDomain
 add:icsStatus
 icsStatus:active
 add:icsExtendedDomainPrefs
 icsExtendedDomainPrefs:domainAccess=@@d^a^slfrwd^g;anonymous^a^r^g;@^a^s^g

Enabling Calendaring in Schema 2 Messaging Domains

If you have already migrated your existing Messaging Server LDAP entries to Schema 2 (using commdirmig), or you originally created the Messaging Server LDAP entries in Schema 2 mode, perform the following two steps to enable calendaring:

  1. Use the Delegated Administrator Utility command commadmin domain modify with the -S option to add calendar service to each domain.

    Alternately, you can use the Delegated Administrator Console to allocate service packages containing calendar service to the affected domains. To do this, use the Allocate Service Packages button on the Organization List page.

  2. Use the Delegated Administrator Utility command commadmin user modify with the -S option to add calendar service to each user in each domain you enabled for calendar.

    Alternately, you can use the Delegated Administrator Console to assign a service package containing calendar service to each user in the affected domains. To do this, use the Assign Service Package button on the User List page in each affected organization.

For the commadmin commands, see the Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide.

For more information about Delegated Administrator Console, see its online help.

For commdirmig information, see the Sun Java System Communications Services 6 2005Q4 Schema Migration Guide)