Sun Java System Communications Services 6 2005Q1 Delegated Administrator Guide |
Chapter 1
Delegated Administrator OverviewThe Communications Services Delegated Administrator utility and console let you provision users, groups, domains, and resources in an LDAP directory used by Communications Services applications such as Messaging Server.
This chapter describes the following topics:
IntroductionWith 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:
These interfaces are summarized in the sections that follow.
Delegated Administrator Utility
The Delegated Administrator utility is a set of command-line tools for provisioning Messaging Server and Calendar Server users. (In previous releases, the Delegated Administrator utility was called the User Management Utility.)
With the Delegated Administrator utility, you can provision organizations, users, groups, and Calendar resources.
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 users and organizations.
To provision groups and Calendar resources, use the Delegated Administrator utility. Do not use the Delegated Administrator console. In this release of Delegated Administrator, the console cannot be used to provision 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: Classes and Attributes Used by Communications Services Delegated Administrator (Schema 2)” in the Sun Java System Communications Services Schema Reference.
Scenarios for Provisioning UsersDepending 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:
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:
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 business organizations for new customers and assign Organization Administrators (OAs) to manage users in those business 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 HierarchyThis 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 Step 6, Organization Distinguished Name (DN) 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:
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.
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:
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, Delegated Administrator Command Line Interfaces in Chapter 5, "Command Line Utilities."
Organization Administrator Role
The OA has the authority to perform the following tasks:
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.
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, Delegated Administrator Command Line Interfaces in Chapter 5, "Command Line Utilities."
For Former Users of iPlanet Delegated AdministratorCommunications Services 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 Service Delegated Administrator.
Table 1-1 lists and defines the administrator roles in each version of Delegated Administrator.
Service PackagesA 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 entries.
In the Delegated Administrator console, you perform the following Service-package tasks:
When you assign a Service package to a user, all the attributes and values in the Service package are automatically assigned to the user.
Class-of-Service Definitions
This release provides one Class-of-Service definition for Messaging Server users. Table 1-2 shows the LDAP attributes defined for mail users:
For more information about these attributes, see “Chapter 3: Attributes” in the Sun Java System Communications Services Schema Reference.
These mail-service attributes are defined in a Class-of-Service definition called standardMail. When you configure Delegated Administrator, the standardMail definition is installed in the directory.
The standardMail Class-of-Service definition is as follows:
In addition to the mail attributes, the standardMail definition defines the service type as a mail user in the attribute daServiceType.
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 standardMail Class-of-Service definition provided by Delegated Administrator.
Class-of-Service Templates
Based on the attributes available in a Class-of-Service definition, you can create your own Service packages that define different levels of service for different users.
Default Class-of-Service Template
By default, the Delegated Administrator configuration program (config-commda) installs an ldif file, cos.default.ldif, in the directory. This ldif file provides a generic Class-of-Service template called defaultmail.
The following Class-of-Service template is included in the cos.default.ldif file:
dn: cn=defaultmail,o=cosTemplates,<ugldapbasedn>
changetype: add
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
mailquota: -2
cn: defaultmail
NOTE: When the Delegated Administrator configuration program installs the defaultmail template in the directory, the variable <ugldapbasedn>, shown above, is replaced by your root suffix (such as o=usergroup).
In the default Class-of-Service template (defaultmail), only one mail service attribute is defined—mailquota. Its value is -2, which indicates that the mail quota for this service is the system default.
Sample Class-of-Service Templates
You can choose to load additional sample service packages when you run the Delegated Administrator configuration program, config-commda. (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 tree.
The cos.sample.ldif file includes the following sample Class-of-Service templates:
Each template contains specific values for one or more of the attributes listed in the Class-of-Service definition. The templates are prototype examples of Service packages.
For example, the platinum Class-of-Service template is included in the cos.sample.ldif file:
dn: cn=platinum,o=cosTemplates,$rootSuffix
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
cn: platinum
mailMsgMaxBlocks: 800
mailQuota: 4000000000
mailMsgQuota: 6000
mailAllowedServiceAccess: +imap:ALL$+pop:ALL$+smtp:ALL$+http:ALL
NOTE: When the Delegated Administrator configuration program installs the sample Class-of-Service templates in the directory, the variable $rootSuffix, shown above, is replaced by your root suffix (such as o=usergroup).
For a list of the mail-service values for all sample Class-of-Service templates, see Mail Service Levels in the Sample Class-of-Service Templates at the end of this chapter.
Creating Your Own Service Packages
The Class-of-Service templates described in this chapter are meant to be examples. Most likely you will have to create your own Service packages with attribute values appropriate for the users 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 Service packages in the directory.
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".
Sample Service Package Assigned to an LDAP User Entry
When you use Delegated Administrator to assign a Service package to a user, a single attribute (inetCOS) is added to the user entry in the LDAP directory. The value of the inetCOS attribute assigns the entire Service package to the user. (inetCOS is a multi-valued attribute.)
For example, suppose you assign the platinum package to a user. The following attributed is added to the user entry:
The platinum package contains the following values for mail service attributes. Thus, assigning the platinum package has the effect of adding these attributes to the user entry:
Location of Class-of-Service Definitions and Packages
In the LDAP Directory Information Tree (DIT), the Class-of-Service definition is located in a node directly under the root suffix. Because it is stored at the top of the DIT, the Service packages can be assigned to all user entries in the directory.
Figure 1-7 shows the location of the Service definitions and packages in the DIT. There are two example packages, Gold and Silver.
Figure 1-7
Location of Class-of-Service Definitions and Packages in the Directory Tree
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 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.
Mail Service Levels in the Sample Class-of-Service Templates
This section lists the mail-service levels provided by the sample Class-of-Service templates. The attribute values in these templates are examples only and not derived from a real installation.
Platinum
mailMsgMaxBlocks: 800
mailquota: 10000000
mailmsgquota: 6000
mailAllowedServiceAccess: +imap:ALL$+pop:ALL$+smtp:ALL$+http:ALLGold
mailMsgMaxBlocks: 700
mailquota: 8000000
mailmsgquota: 3000
mailAllowedServiceAccess: +imap:ALL$+pop:ALL$+smtp:ALL$+http:ALLSilver
mailMsgMaxBlocks: 300
mailquota: 6291456
mailmsgquota: 2000
mailAllowedServiceAccess: +pop:ALL$+imap:ALL$+smtp:ALL$+http:ALLBronze
mailMsgMaxBlocks: 700
mailquota: 5242288
mailmsgquota: 3000
mailAllowedServiceAccess: +pop:ALL$+imap:ALL$+smtp:ALL$+http:ALLRuby
mailMsgMaxBlocks: 600
mailquota: 1048576
mailmsgquota: 2000
mailAllowedServiceAccess: +pop:ALL$+smtp:ALL$+http:ALLEmerald
mailMsgMaxBlocks: 600
mailquota: 2097152
mailmsgquota: 2000
mailAllowedServiceAccess: +pop:ALL$+smtp:ALL$+http:ALLDiamond
mailMsgMaxBlocks: 5000
mailquota: 3145728
mailmsgquota: 3000
mailAllowedServiceAccess: +imap:ALL$+smtp:ALL$+http:ALLTopaz
mailMsgMaxBlocks: 3000
mailquota: 4194304
mailmsgquota: 2000
mailAllowedServiceAccess: +imap:ALL$+smtp:ALL$+http:ALL