Chapter 5 Setting Up Hosted Domains

Previous Contents Index Next
Sun Java System Calendar Server Administration Guide

Chapter 5
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:

Overview of Hosted Domains

Organization of the LDAP Directory

Calendar Server Logins

Cross Domain Searches

Support for a Non-Hosted Domains Environment

Migrating to a Hosted Domain Environment

Using Domains Created by Messaging Server

Note

The Sun Java System Calendar Server Deployment Planning Guide (/docs/cd/E19263-01/816-6709) discusses all the steps necessary to prepare your installation to use hosted domains.

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

Note

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 2004Q2 as a new installation, use LDAP Schema 2.

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

If you want to use Identity Server features such as the commadmin utility or single sign-on (SSO), choose LDAP Schema 2.

If you don’t want to use Identity Server features, you can use either version. However, use LDAP Schema 2, if possible.

Sun LDAP Schema 2

Figure 5-1 shows an LDAP directory organization for a hosted domain installation that uses Sun LDAP Schema 2.

Figure 5-1  LDAP Directory Organization Using LDAP Schema 2

LDAP Schema 2 uses a flat LDAP directory organization. For a hosted domain installation, the first level entries (varriusDomain, sestaDomain, and siroeDomain in the figure) must be parallel in the directory organization. These entries cannot be nested.

If you want to use Identity Server features such as the User Management Utility (commadmin) or single sign-on (SSO), Schema 2 is required.

Sun LDAP Schema 1

Figure 5-2 shows an LDAP directory organization for a hosted domain installation that uses Sun LDAP Schema 1.

This organization includes two trees (or nodes) for domain management:

DC tree

Organization (OSI) tree

Figure 5-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 OSI tree (node). Within each domain, the identifiers for Calendar Server users, resources, and groups must be unique.

In a hosted domain installation using LDAP Schema 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 OSI tree.

In the OSI 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 13, "Administering Calendars."

Login permission is based on the icsStatus or icsAllowedServiceAccess attribute. For more information, see Table D-17.

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 Table D-16. 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 Table D-17.

To set the icsDomainNames and icsExtendedDomainPrefs LDAP attributes, use the Calendar Server csdomain utility. If you add or update domain LDAP attributes using csdomain (or another utility such as commadmin or ldapmodify), restart Calendar Server for the new values to take effect.

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 5.x or earlier legacy installation, you can still operate in the single domain environment.

In this case, the following parameter must be set to “no” in the ics.conf file:

service.virtualdomain.support = "no"

You will, however, still need to migrate the pre-6.x Calendar Server components database to the current version. For migration information, see the Chapter 4, "Migration Utilities".

Migrating to 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:

If you are also migrating from Calendar Server 5.x, be sure that you have already run cs5migrate before attempting to set up hosted domains. You can get the latest version of cs5migrate from Sun’s technical support.

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.

Table 5-1 lists and describes the configuration parameters in the ics.conf file used for hosted domain support.

If any of the parameters listed in Table 5-1 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.

Table 5-1  Configuration Parameters for Hosted Domain Support

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:

"1" = Sun LDAP Schema 1. See also service.dcroot.

"2" = Sun LDAP Schema 2. See also service.schema2root.

Default is "1".

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: "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 = "select"

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

Use the csvdmig utility to modify the calendar database and the LDAP directory by assigning a domain name to each calendar ID (calid).

The csvdmig migration utility makes these changes:

Converts calendar IDs (calids) from the format userid[:calendar-name] to userid@domain[:calendar-name].

Converts access control list (ACL) rules from the format userid to userid@domain.

Converts directory server user entries for the icsCalendar, icsCalendarOwned, and icsSubscribed attributes from the format userid[:calendar-name] to userid@domain[:calendar-name].

For information about running csvdmig, refer to the Chapter 4, "Migration Utilities"

Caution

Before you run csvdmig, first check with your Sun Microsystems technical support or sales account representative to ensure that you have the latest version of the utility.

Unlike pre-6.0 versions of Calendar Server, the current version does not support multiple instances of Calendar Server on the same server.

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.

Enable calendaring services for the default domain entry.

For Schema 1: Add the icsCalendarDomain object class to the o=internet domain entry in LDAP using ldapmodify.

For Schema 2: After configuring commadmin, modify the default domain (created by the commadmin configuration program) to add Calendar (and Mail) services. In the following example, calendar and mail services are added to the default domain (blue.sesta.com):

commadmin domain modify -D admin -w passwd -d blue.sesta.com -S cal,mail -H luna.blue.sesta.com

If the calmaster site administrator user does not already exist, create it using the commadmin user create command as illustrated in the following example, the calmaster is created for sesta.com:

commadmin user create -D admin -w passwd -F Calendar -L Administrator -l calmaster -W calmasterpasswd -d blue.sesta.com -S cal

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 for Schema 1

Enabling Calendaring for Schema 2

Enabling Calendaring for Schema 1

To enable domains for calendaring perform the following tasks:

Add the icsCalendarDomain object class to the LDAP entry for each domain you want enabled for Calendar Server users.

In each domain you enabled in Step 1, set the attribute value of icsStatus to “active”.

In each domain you enabled in Step 1, set the icsExtendedDomainPrefs attribute option domainAccess value to the ACL you want to use for access control.

You can do this in one of two ways: use csattribute add command or use ldapmodify as shown in Code Example 5-1.

Code Example 5-1  Modifying the Domain LDAP Entry

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

If you want domain-level administrators for your calendar system, then add a calmaster user to each domain, adding the appropriate access control.

For each domain you enabled, all of the existing users must also be calendar enabled using the csuer enable command.

For instructions on using the csattribute and csuser utilities, see Appendix D, "Calendar Server Command-Line Utilities Reference".

Enabling Calendaring for Schema 2

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, use the following steps to enable Calendaring:

Add the calendar service to the domains using the commadmin domain modify command with the -S option.

Enable each user in the affected domains by assigning calendar services to them using the commadmin user modify command with the -S option.

For the commadmin commands, see the Sun Java System Communications Services User Management Utility Administration Guide.

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

Previous      Contents      Index      Next

Copyright 2004 Sun Microsystems, Inc. All rights reserved.


Note	The Sun Java System Calendar Server Deployment Planning Guide (/docs/cd/E19263-01/816-6709) discusses all the steps necessary to prepare your installation to use hosted domains.


Note	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 2004Q2 as a new installation, use LDAP Schema 2. Upgrade. If your site is upgrading from Calendar Server 5.x, use the schema version as follows: If you want to use Identity Server features such as the commadmin utility or single sign-on (SSO), choose LDAP Schema 2. If you don’t want to use Identity Server features, you can use either version. However, use LDAP Schema 2, if possible.

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: "1" = Sun LDAP Schema 1. See also service.dcroot. "2" = Sun LDAP Schema 2. See also service.schema2root. Default is "1".
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: "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 = "select"	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).


Caution	Before you run csvdmig, first check with your Sun Microsystems technical support or sales account representative to ensure that you have the latest version of the utility. Unlike pre-6.0 versions of Calendar Server, the current version does not support multiple instances of Calendar Server on the same server. 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.