| Sun ONE Calendar Server 6.0 Administrator's Guide |
Chapter 8
Using Hosted DomainsSun ONE Calendar Server 6.0 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 DomainsThis 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). Each domain includes unique users, groups, and resources. A distinguished name (DN) describes the root of each domain.
Calendar Server 6.0 (or later) supports both of these LDAP directory schema versions for hosted domains:
- Sun ONE LDAP Schema, v.2 (compatibility or native mode)
Note
When you run the Directory Server Setup script (comm_dssetup.pl), you can choose either LDAP Schema, v.1 or LDAP Schema, v.2. Several considerations are:
Sun ONE LDAP Schema, v.2
Figure 8-1 shows an LDAP directory organization for a hosted domain installation that uses Sun ONE LDAP Schema, v.2.
Figure 8-1 LDAP Directory Organization Using LDAP Schema v.2
LDAP Schema v.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 Sun ONE Identity Server features such as the commadmin utility or Single Sign-on (SSO), LDAP Schema v.2 is required.
Sun ONE LDAP Schema, v.1
Figure 8-2 shows an LDAP directory organization for a hosted domain installation that uses Sun ONE LDAP Schema, v.1. This organization includes two trees (or nodes) for domain management:
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 v.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 unique user ID (uid) within a domain. A login to Calendar Server uses the following format:
userid[@domain-name]
If domain-name is omitted, Calendar Server uses the 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 directory that doesn’t follow the organization shown in Figure 8-2, domain-name is not required. If a domain name is specified, it will be ignored.
When a new user logs into Calendar Server for the first time, Calendar Server automatically provisions the user if local.autoprovision is set to “yes” (the default) and the domain has been assigned the calendar service. The login permission is based on the icsStatus or icsAllowedServiceAccess attribute. For more information, see Table 11-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 11-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 11-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 Calendar Server Legacy Installation
Calendar Server 6.0 supports an existing or legacy Calendar Server 5.x installation. In this case, the following parameter must be set to “no” in the ics.conf file:
service.virtualdomain.support = "no"
You will, however, need run the cs5migrate utility to migrate Calendar Server 5.x to 6.0. For migration information, see the Sun ONE Calendar Server 6.0 Installation Guide for Solaris Operating Systems.
If you decide to migrate a Calendar Server 5.x installation to use hosted domains, you must also run the csvdmig utility, See "Migration to a Hosted Domain Environment" for more information.
Creation and Management of Hosted DomainsThis section provides the following information about creating and managing hosted domains:
Running the Directory Server Setup Script
The Directory Server Setup (comm_dssetup.pl) script configures Sun ONE Directory Server 5.x for Calendar Server 6.0 (and Messaging Server 6.0). You run comm_dssetup.pl after you install Calendar Server 6.0 using the Sun Java Enterprise System installer and before you run the Calendar Server configuration program (csconfigurator.sh).
The comm_dssetup.pl script allows you to select these options:
- Directory Server 5.x installation directory path and instance you want to use for Calendar Server 6.0 (and Messaging Server 6.0).
- Directory Manager Distinguished Name (DN).
- Whether Directory Server 5.x will be used for users and groups. If yes, you must also specify the DC tree base suffix and a User and Group base suffix for your Organization tree.
- Whether to use Sun ONE LDAP Schema v.1 or v.2 (either compatibility mode or native mode). See Organization of the LDAP Directory for information about these schemas.
- To update your schema according to the version you have selected.
- To add Directory Server indexes to improve the efficiency of directory searches.
For information about comm_dssetup.pl, see the Sun ONE Calendar Server 6.0 Installation Guide for Solaris Operating Systems.
Creating New Domains
To create a new domain, use one of these utilities:
- Sun ONE Identity Server commadmin utility–To create and manage hosted domains when you are using LDAP Schema, v.2. For information about the commadmin utility, refer to the Sun ONE Messaging and Collaboration 1.0 User Management Utility Installation and Reference Guide.
- Calendar Server csdomain utility–To create and manage a new hosted domain in the LDAP directory when you are using either LDAP Schema, v.1 or LDAP Schema, v.2. This utility allows you to add, delete, and list Calendar Server attributes in the icsCalendarDomain object class and their associated values in the LDAP directory for a specific domain.
Note
Use csdomain to create domains only if you don’t want to use the Identity Server commadmin utility to manage the domain.
For LDAP Schema, v.1, both the DC Tree and the OSI tree (that is, the node to which the domain points) must already be present in the LDAP directory server, as shown in Figure 8-2. The csdomain utility does not create these trees.
Calendar Server does not support the Identity Server Console to create domains.
Using Domains Created by Messaging Server
If Sun ONE Messaging Server has already created a hosted domain, Calendar Server can provision users in that domain. To use a domain created by Sun ONE Messaging Server, follow these steps:
- Add the icsCalendarDomain object class to the o=internet domain entry in the directory server and set up your domain entries with your Calendar Server users in their respective domains. Also set icsStatus to “active” and domainAccess to the ACL you want to use for access control. For an example, see Code Example 8-1.
To modify the LDAP directory, use the Directory Server ldapmodify tool. For information about using ldapmodify, refer to the Sun ONE Directory Server Resource Kit 5.2 Tools Reference.
- If you are migrating from Calendar Server 5.x, run these utilities (if you have not already run them):
For information about running the migration utilities, refer to the Sun ONE Calendar Server 6.0 Installation Guide for Solaris Operating Systems.
Setting Domain Specific Attributes and Preferences
Each domain has a set of attributes and preferences that you can set using the csdomain utility or the commadmin utility. These attributes are part of the icsCalendarDomain object class. The attributes include preferences such as access rights, access control lists (ACLs), domain searches, access rights for domain searches, user status, and proxy logins. For a complete list, see the tables under the description of the csdomain utility:
Provisioning New Calendar Server Users
When a new user logs into Calendar Server for the first time, that user is automatically provisioned, if specific requirements are met as described in Calendar Server Logins. New users must have an LDAP user ID and password to log in.
To provision new Calendar Server users in a domain, use one of these utilities:
- Calendar Server csuser utility.
- Identity Server commadmin utility. For information about the commadmin utility, refer to the Sun ONE Messaging and Collaboration 1.0 User Management Utility Installation and Reference Guide.
Managing Domains Using Calendar Server Utilities
Use the following Calendar Server command-line utilities to manage domains in a hosted domain installation. Each utility allows you to include the -d domain option to operate on a specific target domain.
- csdomain manages Calendar Server LDAP attributes in the LDAP directory for a domain when you using LDAP Schema, v.1 or v.2. You can create a new domain as well as add, delete, and list the LDAP attributes in the LDAP directory for a domain. For more information, see "Creating New Domains".
- csuser manages Calendar Server users in a domain.
- csresource manages Calendar Server resource calendars in a domain.
- cscal manages calendars and their properties in a domain.
- csattribute manages Calendar Server LDAP attributes in the LDAP server for a domain.
Hosted Domain Configuration ParametersTable 8-1 describes the configuration parameters in the ics.conf file used for hosted domain support. If any of the following parameters 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 8-1 Configuration Parameters for Hosted Domain Support
Parameter
Description
service.virtualdomain.support
Enables ("y") or disables ("n") support for hosted (virtual) domain mode. Default is "n".
local.schemaversion
Specifies the version of the LDAP schema:
- "1" = Sun ONE LDAP Schema, v.1. See also service.dcroot.
- "2" = Sun ONE LDAP Schema, v.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:
Default is "select".
local.domain.language
Specifies the language for the domain. Default is "en" (English).
Using WCAP CommandsIf your site is configured for hosted domains, you must fully qualify each calendar ID (calid) and user IDs with the domain name in all WCAP commands. For example: jsmith@sesta.com.
Migration to a Hosted Domain EnvironmentTo migrate a site to use hosted domains, use the csvdmig utility. This utility modifies the calendar database and the LDAP directory by assigning a domain name to each calendar ID (calid).
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.
Calendar Server 6.0 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.
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 Sun ONE Calendar Server 6.0 Installation Guide for Solaris Operating Systems.
In addition to migration, you must also perform these tasks:
- Set service.virtualdomain.support to “yes” in the ics.conf file.
- Set up your directory server organization depending on the schema you are using. See "Organization of the LDAP Directory".
- Add the icsCalendarDomain object class to the o=internet domain entry in the directory server. See "Using Domains Created by Messaging Server".
- Set up the domain entries with your Calendar Server users in their respective domains. Then, set icsStatus to “active” and domainAccess to the ACL you want to use for access control.
For the most recent information, refer to the Release Notes on the following documentation Web site:
http://docs.sun.com/coll/S1_CalendarServer_60
