Chapter 1 Delegated Administrator Overview

The Communications Suite Delegated Administrator utility and console let you provision users, groups, domains, and resources in an LDAP directory used by Communications Suite applications such as Messaging Server and Calendar Server.

This chapter describes the following topics:

• Introduction to Delegated Administrator

• Scenarios for Provisioning Users

• Administrator Roles and the Directory Hierarchy

• For Former Users of iPlanet Delegated Administrator

• Service Packages

Introduction to Delegated Administrator

With Delegated Administrator, you can distribute provisioning tasks to lower-level administrators who have the authority to manage specified organizations in the LDAP directory. The power to delegate user administration offers the following advantages:

• Distributes among many administrators the potentially time-consuming responsibility for provisioning a large directory. Tens or hundreds of administrators can manage organizations within a directory that may include thousands or millions of users.

• Allows you to create organizations in the directory structure that can be managed and provisioned as distinct (or unique) units. These organizations can contain users belonging to customer businesses, corporate departments, or other groups.

Delegated Administrator provides two interfaces for provisioning users and organizations in the directory:

• Delegated Administrator Utility

• Delegated Administrator Console

These interfaces are summarized in the sections that follow.

Delegated Administrator provisions the directory to support Messaging Server and Calendar Server.

In addition, users created in Delegated Administrator will have access to Sun Java System Instant Messaging (IM) service if IM is deployed on your site. Users are automatically assigned basic IM service during user creation.

You must use the Access Manager console to set and manage IM user-access levels. In this release, the Delegated Administrator console does not provide access to IM service and does not provide an interface for managing IM user-access levels.

Delegated Administrator Utility

The Delegated Administrator utility is a set of command-line tools for provisioning Messaging Server and Calendar Server organizations, users, groups, and Calendar resources.

The Delegated Administrator utility does not offer commands for creating the Service Provider roles and organizations described in this book. To create and manage these new roles and organizations, you must use the Delegated Administrator console.

You invoke the utility with the commadmin command.

For information about the syntax and options available with the commadmin utility, see Chapter 5, Command Line Utilities.

Delegated Administrator Console

The Delegated Administrator console is a graphical user interface (GUI) for provisioning Messaging Server and Calendar Server organizations, users, groups, and Calendar resources.

For information on how to use the console, see the Delegated Administrator console online help.

Delegated Administrator and the LDAP Directory

Delegated Administrator enables you to provision users by modifying the LDAP directory. You do not need to modify the directory directly. However, it can be useful to understand the Delegated Administrator attributes added to user entries and higher-level nodes in the directory.

For information about the LDAP schema object classes and attributes that support Delegated Administrator, see “Chapter 5: Communications Suite Delegated Administrator Classes and Attributes (Schema 2)” in the Sun Java System Communications Suite Schema Reference.

Scenarios for Provisioning Users

Depending on your business needs, you can create a simple directory structure managed by a single administrator or a multi-tiered directory hierarchy in which provisioning and management tasks are delegated to lower-level administrators.

This section summarizes three scenarios of increasing complexity. It then describes the administrator roles and directory structures Delegated Administrator provides to support the requirements of these scenarios.

One-Tiered Hierarchy

In this scenario, a company or organization might support hundreds or thousands of employees or users. All users are grouped in a single organization. A single administrator role views and manages the entire group. There is no delegation of administrative tasks.

Figure 1–1 shows an example of the administrator role in a single-organization, one-tiered hierarchy.

Figure 1–1 Administrator Role in a One-Tiered Hierarchy

In this one-tiered hierarchy, the administrator is called the Top-Level Administrator (TLA).

In the example shown in Figure 1–1, the TLA directly manages and provisions the users (User1, User2, up to Usern).

If you have one organization in your directory, the TLA is the only administrator you need.

For more information, see the following sections:

• Directory Structure Supporting a One-Tiered Hierarchy

• Top-Level Administrator Roles

Two-Tiered Hierarchy

In this scenario, a large company such as an Internet Service Provider (ISP) provides services to businesses. Each business has its own unique domain, which may contain thousands or tens of thousands of users.

Instead of relying on a single Top-Level Administrator (TLA) to manage and provision all the domains, this scenario supports the delegation of tasks to lower-level administrators.

In a two-tiered hierarchy, the directory contains multiple organizations. A separate organization is created for each hosted domain.

Each organization is assigned to an Organization Administrator (OA). The OA is responsible for the users in that organization. An OA cannot view or modify directory information outside the OA’s own organization.

Figure 1–2 shows an example of the administrator roles in a two-tiered hierarchy.

Figure 1–2 Administrator Roles in a Two-Tiered Hierarchy

In the example shown in Figure 1–2, the TLA creates and manages OA1, OA2, up to OAn. Each OA manages the users in one organization.

If you need multiple organizations in your directory, you should create the TLA and OAs to administer the organizations and their users.

For more information, see the following sections:

• Directory Structure Supporting a Two-Tiered Hierarchy

• Top-Level Administrator Role

• Organization Administrator Role

Three-Tiered Hierarchy

In this scenario, a company such as an ISP offers services to hundreds or thousands of small businesses, each of which requires its own organization.

The ISP may support millions of end-users requiring mail services. Moreover, the ISP may work with third-party resellers who manage the end-user businesses.

Each day, dozens of new organizations might have to be added to the directory.

In a two-tiered hierarchy, the TLA would have to create all these new organizations.

In a three-tiered hierarchy, management tasks are delegated to a second level of administrators. This second level of delegation can ease the management of a large customer base supported by a large LDAP directory.

To support this hierarchy, Delegated Administrator introduces a new role, the Service Provider Administrator (SPA).

The SPA’s scope of authority lies between that of the Top-Level Administrator (TLA) and the Organization Administrator (OA).

Figure 1–3 shows an example of the administrator roles in a three-tiered hierarchy.

Figure 1–3 Administrator Roles in a Three-Tiered Hierarchy

In a three-tiered hierarchy, the TLA delegates administrative authority to Service Provider Administrators (SPAs). The SPAs can create subordinate organizations for new customers and assign Organization Administrators (OAs) to manage users in those organizations.

If you need multiple organizations that are themselves divided into subgroups or organizations, you can use a three-tiered hierarchy that implements the TLA, SPA, and OA roles.

For information about the SPA role, see Appendix A, Service Provider Administrator and Service Provider Organizations.

Administrator Roles and the Directory Hierarchy

This section shows sample Directory Information Trees that implement one- and two-tiered hierarchies. It then describes the tasks that can be performed by the Top-Level Administrator and Organization Administrator.

Directory Structure Supporting a One-Tiered Hierarchy

When you configure Delegated Administrator by running the configuration program, config-commda, you create a Top-Level Administrator (TLA) and a default organization.

One-Tiered Hierarchy: Default Organization Under the Root Suffix

By default, the configuration program places the default organization under the root suffix.

The Directory Information Tree will look similar to the one shown in Figure 1–4.

Figure 1–4 shows a sample Directory Information Tree organized in a one-tiered hierarchy (default configuration).

Figure 1–4 One-Tiered Hierarchy: Sample Directory Information Tree (default)

One-Tiered Hierarchy: Default Organization at the Root Suffix

When you run the configuration program, config-commda, you can choose to create the default organization at the root suffix instead of under it. For configuration details, see Configuring the Delegated Administrator Server in Chapter 3, Configuring Delegated Administrator.

In this situation, the Directory Information Tree will look similar to the one shown in Figure 1–5.

However, if you create the default organization at the root suffix, this configuration of the LDAP directory cannot support multiple hosted domains. To support hosted domains, the default organization must be under the root suffix.

Figure 1–5 shows a sample one-tiered hierarchy in which the default organization is created at the root suffix.

Figure 1–5 One-Tiered Hierarchy: Default Organization at Root Suffix

Directory Structure Supporting a Two-Tiered Hierarchy

After Delegated Administrator has been configured with the config-commda program, the TLA can create additional organizations, as shown in Figure 1–6.

Figure 1–6 shows a sample Directory Information Tree organized in a two-tiered hierarchy.

Figure 1–6 Two-Tiered Hierarchy: Sample Directory Information Tree

Top-Level Administrator Role

The TLA has the authority to perform the following tasks:

• Create, delete, and modify organizations.

  In the example shown in Figure 1–6, the TLA can modify or delete siroe.com or sesta.com and can create additional organizations.

  Note that in this example, the two organizations are also unique (hosted) domains.

• Create, delete, and modify users.

• Create, delete, and modify groups.

• Create, delete, and modify Calendar resources.

• Assign OA roles to users. For example, the TLA could assign an OA role to the user johna in the siroe.com organization.

  The TLA also can remove the OA role from a user.

• Assign TLA roles to other users. The TLA also can remove the TLA role from a user.

• Assign service packages to organizations.

  For information about service packages, see Service Packages, later in this overview.

  The TLA can assign specified types of service packages to an organization and determine the maximum number of each package that can be used in that organization.

  For example, the TLA could assign the following service packages:

  • In the siroe.com organization:

    1,000 gold packages

    500 platinum packages

  • In the sesta.com organization:

    2,000 silver packages

    1,500 gold packages

    100 platinum packages

    The TLA can perform the preceding tasks by using the Delegated Administrator console or by executing Delegated Administrator utility (commadmin) commands.

    For a description of the commadmin commands, see Table 5–1 in Chapter 5, Command Line Utilities.

Organization Administrator Role

The OA has the authority to perform the following tasks within the OA’s organization:

• Create, delete, and modify users.

  In the example shown in Figure 1–6, if the user johna is assigned the OA role in the siroe.com organization, johna can manage users in siroe.com.

• Create, delete, and modify groups.

• Create, delete, and modify Calendar resources.

• Assign the OA role to other users.

• Assign and remove service packages for users.

The OA cannot perform any of these tasks for users, groups, or resources outside the OA’s organization.

For example, if johna is the OA for siroe.com in Figure 1–6, johna cannot manage users, groups, or resources in sesta.com.

The OA can perform the preceding tasks by using the Delegated Administrator console or by executing Delegated Administrator utility (commadmin) commands.

For a description of the commadmin commands available to the OA, see Table 5–1 in Chapter 5, Command Line Utilities.

For Former Users of iPlanet Delegated Administrator

Communications Suite Delegated Administrator is designed for provisioning users in an LDAP Schema 2 directory.

Users of previous versions of Messaging Server who have an LDAP Schema 1 directory may have used iPlanet Delegated Administrator, a deprecated tool. If you still have a Schema 1 directory, you should use iPlanet Delegated Administrator to provision users.

iPlanet Delegated Administrator uses slightly different terms for the administrator roles than those currently used by Communications Suite Delegated Administrator.

Table 1–1 lists and defines the administrator roles in each version of Delegated Administrator.

Service Packages

A service package is implemented by the Class-of-Service mechanism in the LDAP directory. This mechanism lets you set values for predefined attributes that are installed in the directory when you configure Delegated Administrator. A service package adds the characteristics of the service to user or group entries.

Delegated Administrator provides sample Class-of-Service templates.

You can also create your own service packages.

In the Delegated Administrator console, you can assign the sample packages and your own packages to users or groups.

Types of Service Packages

A service package includes the following components:

• Access Manager service

• Service bundle (mail service and/or calendar service)

• LDAP object (users or groups)

Delegated Administrator automatically provides Access Manager service with every service definition. When you assign a service package to a user or group, Delegated Administrator takes the Access Manager object classes and attributes from the service definition and adds them to the LDAP entry.

Do not change or delete the Access Manager portion of any service package.

When you create a service package, you can configure its service bundle and LDAP object.

Service Bundles

Delegated Administrator provides two types of service: mail service and calendar service.

A service package bundles one or more services, together with a set of attributes associated with that service. Thus, an individual service package can contain the following combinations of services:

• Mail service only

• Calendar service only

• Mail and calendar service

Only the mail service package templates have LDAP attributes associated with the mail Class-of-Service definition. The Calendar service package templates do not include attributes associated with the Calendar service definition.

Packages Defined for Particular LDAP Objects

A service package is defined either for users or for groups. You cannot assign the same service package to a user and a group.

Delegated Administrator provides service packages with the following service bundles and LDAP objects:

• User mail service

• User calendar service

• User mail and calendar service

• Group mail service

• Group calendar service

• Group mail and calendar service

About Groups

In Delegated Administrator, a group is an entry in the LDAP directory that comprises a list of users. Characteristics of the group are not passed on to the users who are members of the group. For example, when you assign a service package to a group, the service package attributes are not inherited by the members of the group. The user entries in the directory are not subordinate to (do not “belong” to) the group entry.

When a mail service package is assigned to a group, the group becomes a mailing list, which is used by Messaging Server.

When calendar service is assigned to a group, the members of the group share group invitations and other calendar information managed by Calendar Server.

A mail group does not have its own mailbox; a message sent to the group address is delivered to the mailboxes of the individual members of the group.

However, a calendar group does have its own calendar; an invitation sent to the group is displayed on the group calendar and on the calendars of the individual members of the group.

Service Packages Provided by Delegated Administrator

When you configure Delegated Administrator, you can choose to install a set of predefined, sample Class-of-Service templates. The Delegated Administrator console displays these templates.

(When you run the configuration program, select Load sample service packages in the Service Package and Organization Samples panel.) The configuration program adds the cos.sample.ldif file to the LDAP directory.

You can use the sample templates to provide services and mail attributes to users and groups. For a list of the templates with their attribute values, see Sample Class-of-Service Templates.

Figure 1–7 shows the user service package templates.

Figure 1–7 All User Service Packages page — sample templates displayed

Figure 1–8 shows the group service package templates.

Figure 1–8 All Group Service Packages page — sample templates displayed

Service-Package Tasks

In the Delegated Administrator console, you perform the following service-package tasks:

• Allocate service packages to organizations. By allocating some (or all) packages to an organization, you make those packages available to users or groups in the organization.

  For each package, you allocate a specified number of packages.

  For example, for the ABC organization, you might allocate 5,000 gold service packages, 10,000 venus service packages, and 500 atlantic service packages.

• Assign service packages to users.

• Assign service packages to groups.

Guidelines for Assigning Service Packages

• The service packages allocated to an organization make up the pool from which service packages can be assigned to users or groups in the organization.

• You can assign multiple service packages to a user or group.

• When you assign a service package to a user or group, all the attributes and values in the service package are automatically assigned to the user or group.

• To assign only calendar service to a user, use the standardUserCalendar service package. Calendar service does not have any associated attributes.

  Assigning the standardUserCalendar service package is equivalent to using the -s cal option in the commadmin user create or commadmin user modify command.

For instructions on how to allocate and assign service packages, see the Delegated Administrator console online help.

Creating Your Own Service Packages

The Class-of-Service templates described in this chapter are meant to be examples. Most likely you will want to create your own service packages with attribute values appropriate for the users and groups in your installation.

To create your own service packages, you can use a Class-of-Service template stored in the da.cos.skeleton.ldif file. This file was created specifically for use as a template for writing service packages. It is not installed in the LDAP directory when Delegated Administrator is configured.

You can copy and edit the da.cos.skeleton.ldif file and use an LDAP directory tool such as ldapmodify to install your customized Class-of-Service templates in the directory.

The Delegated Administrator console displays your customized templates along with the sample templates. In the console, the Class-of-Service template is called a service package. When you can assign a service package either to a user or to a group, Delegated Administrator populates the user or group LDAP entry with a complete service package, including Access Manager service.

For instructions on using the da.cos.skeleton.ldif file to configure your own service packages, see Create Service Packages in Chapter 3, Configuring Delegated Administrator.

Limitations in Viewing an Extended Service Package

You can extend the Delegated Administrator service package definition by adding any attribute to the definition entry.

However, in this release of Delegated Administrator, the console allows you to view only the predefined attributes provided when Delegated Administrator is configured. The Delegated Administrator console does not display any attributes you add to a service package definition.

In this release, you also should not remove the predefined attribute definitions from the Class-of-Service definitions provided by Delegated Administrator.

Sample Service Package Assigned to an LDAP Entry

When you use Delegated Administrator to assign a service package to a user or group, a single attribute (inetCOS) is added to the user or group entry in the LDAP directory. The value of the inetCOS attribute assigns the entire service package to the user or group, including the service and any attributes associated with that service. (inetCOS is a multi-valued attribute.)

For example, suppose you assign the platinum package to a user. The following attribute is added to the user entry:

inetCOS: platinum

The platinum package provides mail service to the user. The package also contains the following values for mail attributes. Thus, assigning the platinum package has the effect of adding these attributes to the user entry:

mailMsgMaxBlocks: 800
mailQuota: 10000000
mailMsgQuota: 6000
mailAllowedServiceAccess: +imaps:ALL$+pops:ALL$+smtps:ALL$+http:ALL

The Access Manager service definition provides the object classes and attributes required for the mail and/or calendar service. When you assign the service package, Delegated Administrator adds these object classes and attributes to the user or group entry.

Sample Class-of-Service Templates

This section lists the sample Class-of-Service templates and mail attribute values provided by the templates.

These templates are contained in the cos.sample.ldif file.

Mail Service Attributes

Mail service includes LDAP attributes defined for mail users. Table 1–2 defines these attributes.

For more information about these attributes, see “Chapter 3: Messaging Server and Calendar Server Attributes” in the Sun Java System Communications Suite Schema Reference.

User Mail Sample Templates

Platinum

mailMsgMaxBlocks: 800 
mailquota: 10000000 
mailmsgquota: 6000 
mailAllowedServiceAccess: +imaps:ALL$+pops:ALL$+smtps:ALL$+http:ALL
daServiceType: mail user

Gold

mailMsgMaxBlocks: 700
mailquota: 8000000
mailmsgquota: 3000
mailAllowedServiceAccess: +imaps:ALL$+pops:ALL$+smtps:ALL$+http:ALL
daServiceType: mail user

Silver

mailMsgMaxBlocks: 300
mailquota: 6291456
mailmsgquota: 2000
mailAllowedServiceAccess: +pop:ALL$+imap:ALL$+smtp:ALL$+http:ALL
daServiceType: mail user

Bronze

mailMsgMaxBlocks: 700
mailquota: 5242288
mailmsgquota: 3000
mailAllowedServiceAccess: +pop:ALL$+imap:ALL$+smtp:ALL$+http:ALL
daServiceType: mail user

Ruby

mailMsgMaxBlocks: 600
mailquota: 1048576
mailmsgquota: 2000
mailAllowedServiceAccess: +pops:ALL$+smtps:ALL$+http:ALL
daServiceType: mail user

Emerald

mailMsgMaxBlocks: 600
mailquota: 2097152
mailmsgquota: 2000
mailAllowedServiceAccess: +pop:ALL$+smtp:ALL$+http:ALL
daServiceType: mail user

Diamond

mailMsgMaxBlocks: 5000
mailquota: 3145728
mailmsgquota: 3000
mailAllowedServiceAccess: +imaps:ALL$+smtps:ALL$+http:ALL
daServiceType: mail user

Topaz

mailMsgMaxBlocks: 3000
mailquota: 4194304
mailmsgquota: 2000
mailAllowedServiceAccess: +imap:ALL$+smtp:ALL$+http:ALL
daServiceType: mail user

User Calendar Sample Templates

None (standardUserCalendar)

There is no predefined Class-of-Service template that provides calendar service and contains attribute values. Calendar service is provided without associated attributes.

Because no sample template exists, Delegated Administrator generates a default service package, without a template, directly from the User Calendar Class-of-Service definition. Its name is the same as that of the Class-of-Service definition: standardUserCalendar.

This service package provides calendar service only.

User Mail and Calendar Sample Templates

The following sample templates apply both mail and calendar service.

Mercury

mailMsgMaxBlocks: 800
mailquota: 10000000
mailmsgquota: 6000
mailAllowedServiceAccess: +imaps:ALL$+pops:ALL$+smtps:ALL$+http:ALL
daServiceType: mail user
daServiceType: calendar user

Venus

mailMsgMaxBlocks: 700
mailquota: 8000000
mailmsgquota: 3000
mailAllowedServiceAccess: +imaps:ALL$+pops:ALL$+smtps:ALL$+http:ALL
daServiceType: mail user
daServiceType: calendar user

Earth

mailMsgMaxBlocks: 300
mailquota: 6291456
mailmsgquota: 2000
mailAllowedServiceAccess: +pop:ALL$+imap:ALL$+smtp:ALL$+http:ALL
daServiceType: mail user
daServiceType: calendar user

Mars

mailMsgMaxBlocks: 700
mailquota: 5242288
mailmsgquota: 3000
mailAllowedServiceAccess: +pop:ALL$+imap:ALL$+smtp:ALL$+http:ALL
daServiceType: mail user
daServiceType: calendar user

Group Mail Sample Templates

Atlantic

mailMsgMaxBlocks: 800
daServiceType: mail group

Pacific

mailMsgMaxBlocks: 900
daServiceType: mail group

Indian

mailMsgMaxBlocks: 1000
daServiceType: mail group

Arctic

mailMsgMaxBlocks: 1200
daServiceType: mail group

Group Calendar Sample Templates

None (standardGroupCalendar)

There is no predefined Class-of-Service template that provides calendar service to groups and contains attribute values. Calendar service is provided without associated attributes.

Because no sample template exists, Delegated Administrator generates a default service package, without a template, directly from the Group Calendar Class-of-Service definition. Its name is the same as that of the Class-of-Service definition: standardGroupCalendar.

This service package provides calendar service (to groups) only.

Group Mail and Calendar Sample Templates

The following sample templates apply both mail and calendar service to groups.

Nile

mailMsgMaxBlocks: 1600
daServiceType: mail group
daServiceType: calendar group

Amazon

mailMsgMaxBlocks: 1800
daServiceType: mail group
daServiceType: calendar group

Thames

mailMsgMaxBlocks: 2000
daServiceType: mail group
daServiceType: calendar group

Danube

mailMsgMaxBlocks: 2200
daServiceType: mail group
daServiceType: calendar group

Class-of-Service Definitions

This release of Delegated Administrator provides a Class-of-Service definition for each type of service package:

• User mail service

• User calendar service

• User mail and calendar service

• Group mail service

• Group calendar service

• Group mail and calendar service

When you configure Delegated Administrator, the Class-of-Service definitions are installed in the directory.

In each definition, the daServiceType attribute determines the type of service package with the following syntax:

daServiceType: <service type> <target>

where service type is mail service, calendar service, or both, and target is either user or group.

Mail Service for Users

The user mail service is defined in a Class-of-Service definition called standardUserMail:

# 
#  Definition for user mail service bundle 
#
dn: cn=standardUserMail,<ugldapbasedn>
changetype: add
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleObject
objectclass: cosSuperDefinition
objectclass: cosClassicDefinition
cosTemplateDn: o=mailuser,o=cosTemplates,<ugldapbasedn>
cosSpecifier: inetCos
cosAttribute: mailAllowedServiceAccess
cosAttribute: mailMsgMaxBlocks
cosAttribute: mailquota
cosAttribute: mailmsgquota
daServiceType: mail user


NOTE: When the Delegated Administrator configuration program installs the
standardUserMail definition in the directory, the variable 
<ugldapbasedn>, shown above, is replaced by your root suffix 
(such as o=usergroup).

The daServiceType attribute defines this as a mail service for users.

Calendar Service for Users

The user calendar service is defined in a Class-of-Service definition called standardUserCalendar:

# 
#  Definition for user calendar service bundle 
#
dn: cn=standardUserCalendar,<ugldapbasedn>
changetype: add
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleObject
objectclass: cosSuperDefinition
objectclass: cosClassicDefinition
cosTemplateDn: o=calendaruser,o=cosTemplates,<ugldapbasedn>
cosSpecifier: inetCos
cosAttribute: icsPreferredHost
cosAttribute: icsDWPHost
cosAttribute: icsFirstDay
daServiceType: calendar user


NOTE: When the Delegated Administrator configuration program installs the
standardUserCalendar definition in the directory, the variable 
<ugldapbasedn>, shown above, is replaced by your root suffix 
(such as o=usergroup).

The daServiceType attribute defines this as a calendar service for users.

The calendar service definition also includes calendar attributes such as icsPreferredHost.

However, Delegated Administrator does not provide service-package templates that specify values for these attributes. The Delegated Administrator console provides one service package with calendar service only: the standardUserCalendar service package. This package does not include calendar attributes.

Mail and Calendar Service for Users

The user mail and calendar service is defined in a Class-of-Service definition called standardUserMailCalendar:

# 
#  Definition for user mail and user calendar service bundle 
#
dn: cn=standardUserMailCalendar,<ugldapbasedn>
changetype: add
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleObject
objectclass: cosSuperDefinition
objectclass: cosClassicDefinition
cosTemplateDn: o=mailcalendaruser,o=cosTemplates,<ugldapbasedn>
cosSpecifier: inetCos
cosAttribute: icsPreferredHost
cosAttribute: icsDWPHost
cosAttribute: icsFirstDay
cosAttribute: icsQuota
cosAttribute: mailAllowedServiceAccess
cosAttribute: mailMsgMaxBlocks
cosAttribute: mailquota
cosAttribute: mailmsgquota
daServiceType: calendar user
daServiceType: mail user


NOTE: When the Delegated Administrator configuration program installs the
standardUserMailCalendar definition in the directory, the variable 
<ugldapbasedn>, shown above, is replaced by your root suffix 
(such as o=usergroup).

The two daServiceType attribute entries define this as a calendar service and mail service for users.

Mail Service for Groups

The group mail service is defined in a Class-of-Service definition called standardGroupMail:

# 
#  Definition for group mail service bundle 
#
dn: cn=standardGroupMail,<ugldapbasedn>
changetype: add
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleObject
objectclass: cosSuperDefinition
objectclass: cosClassicDefinition
cosTemplateDn: o=mailgroup,o=cosTemplates,<ugldapbasedn>
cosSpecifier: inetCos
cosAttribute: mailMsgMaxBlocks
daServiceType: mail group


NOTE: When the Delegated Administrator configuration program installs the
standardGroupMail definition in the directory, the variable <ugldapbasedn>, 
shown above, is replaced by your root suffix (such as o=usergroup).

The daServiceType attribute defines this as a mail service for groups.

Calendar Service for Groups

The group calendar service is defined in a Class-of-Service definition called standardGroupCalendar:

# 
#  Definition for group calendar service bundle 
#
dn: cn=standardGroupCalendar,<ugldapbasedn>
changetype: add
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleObject
objectclass: cosSuperDefinition
objectclass: cosClassicDefinition
cosTemplateDn: o=calendargroup,o=cosTemplates,<ugldapbasedn>
cosSpecifier: inetCos
cosAttribute: icsdoublebooking
cosAttribute: icsautoaccept
daServiceType: calendar group


NOTE: When the Delegated Administrator configuration program installs the
standardGroupCalendar definition in the directory, the variable <ugldapbasedn>, 
shown above, is replaced by your root suffix (such as o=usergroup).

The daServiceType attribute defines this as a calendar service for groups.

The calendar service definition also includes calendar attributes such as icsdoublebooking.

However, Delegated Administrator does not provide service-package templates that specify values for these attributes. The Delegated Administrator console provides one service package for groups with calendar service only: the standardGroupCalendar service package. This package does not include calendar attributes.

Mail and Calendar Service for Groups

The user mail and calendar service is defined in a Class-of-Service definition called standardGroupMailCalendar:

# 
#  Definition for group mail and group calendar service bundle 
#
dn: cn=standardGroupMailCalendar,<ugldapbasedn>
changetype: add
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleObject
objectclass: cosSuperDefinition
objectclass: cosClassicDefinition
cosTemplateDn: o=mailcalendargroup,o=cosTemplates,<ugldapbasedn>
cosSpecifier: inetCos
cosAttribute: mgrpMsgMaxSize
cosAttribute: mailMsgMaxBlocks
daServiceType: calendar group
daServiceType: mail group


NOTE: When the Delegated Administrator configuration program installs the
standardGroupMailCalendar definition in the directory, the variable 
<ugldapbasedn>, shown above, is replaced by your root suffix 
(such as o=usergroup).

The two daServiceType attribute entries define this as a calendar service and mail service for groups.

Location of Class-of-Service Definitions and Packages

In the LDAP Directory Information Tree (DIT), the Class-of-Service definitions are located in a node directly under the root suffix. Because they are stored at the top of the DIT, the service packages can be assigned to all user entries in the directory.

Figure 1–9 shows the location of the service definitions and packages in the DIT.

Figure 1–9 Location of Class-of-Service Definitions and Packages in the Directory Tree

Each type of Class-of-Service template is located under its own node. Thus, a template providing mail service to users is located under the Mail User node. This structure enables Delegated Administrator to use the correct Class-of-Service definition (such as standardUserMail) when it assigns a service package to a user or group.

Delegated Administrator uses the classic Class-of-Service definition.

For more information about the Class-of-Service mechanism, see the Sun Java System Directory Server Administration Guide. Specifically, see “Defining Class-of-Service (CoS)” in “Chapter 5: Managing Identity and Roles.”

The Sun Java System Directory Server Administration Guide also describes related topics such as determining which service attribute value takes precedence if an attribute defined in a service package assigned to a user already exists in that individual user entry.