Sun Java System Communications Services 6 2005Q1 Delegated Administrator Guide |
Appendix A
Service Provider Administrator and Service Provider OrganizationsThe Delegated Administrator console provides a new administrator role, the Service Provider Administrator (SPA), as well as new types of organizations that can be created in the directory.
This appendix describes the following topics:
This appendix describes the Service Provider Administrator role and the new organization types and explains how to create them in Delegated Administrator.
Service Provider AdministratorThe Delegated Administrator console lets you delegate administrative tasks to a new role, the Service Provider Administrator (SPA), who can create and manage new types of subordinate organizations.
The SPA’s scope of authority lies between that of the Top-Level Administrator (TLA) and the Organization Administrator (OA).
With the SPA, you can create a three-tiered administrative hierarchy, as described in Three-Tiered Hierarchy in Chapter 1, “Delegated Administrator Overview.”
This second level of delegation can ease the management of a large customer base supported by a large LDAP directory. For example, an ISP may offer services to hundreds or thousands of small businesses, each of which requires its own organization. Each day, dozens of new organizations might have to be added to the directory.
If you used a two-tiered hierarchy, the TLA would have to create all these new organizations. Now the TLA can delegate these tasks to SPAs.
The SPAs can create subordinate organizations for new customers and assign OAs to manage users in those organizations.
Figure A-1 shows a logical view of a sample three-tiered organizational hierarchy.
Figure A-1
Directory Using a Service Provider Administrator: Logical View
The example in Figure A-1 shows one provider organization. However, a directory can contain multiple provider organizations.
In this example, administrative tasks are delegated as follows:
- The SPA has the authority to manage the VIS provider organization and all organizations under it. The SPA role is assigned to user1 in the DEF organization.
- The Organization Administrator named OA1 manages DEF, a shared organization. This OA role is assigned to user2 in the DEF organization.
- OA2 manages HIJ, a shared organization. This OA role is assigned to user4 in the HIJ organization.
- OA3 manages SESTA, a full organization. This OA role is assigned to user1 in the SESTA organization.
For definitions of provider and subordinate organizations, see Organizations Managed by the Service Provider Administrator.
Service Provider Administrator Role
The SPA can perform the following tasks:
In the example shown in Figure A-1, the SPA for the VIS provider organization can
For example, in the sample organization shown in Figure A-1, the SPA could assign an OA role to user2 in the SESTA organization. user2 could then manage users in the SESTA organization.
The SPA also can remove the OA role from a user.
For information about Class-of-Service packages, see Service Packages in Chapter 1, “Delegated Administrator Overview.”
The SPA can assign specified types of Class-of-Service packages to an organization and determine the maximum number of each package that can be used in that organization.
For example, the SPA could assign the following Class-of-Service packages:
The SPA can use the Delegated Administrator console to perform these tasks. In this release, the Delegated Administrator utility does not include command options to perform these tasks.
Note
The TLA can modify or delete any existing shared organization or full organization. The TLA also can manage users in those organizations.
The TLA can remove the SPA role from a user but cannot assign the SPA role through the console. For a list of constraints in this release of Delegated Administrator, see Considerations for This Release.
For a complete description of the administrative tasks performed by the TLA, see Administrator Roles and the Directory Hierarchy in Chapter 1, “Delegated Administrator Overview.”
Assigning the SPA Role to a User
The SPA role must be assigned to a user in an organization designated for SPAs and subordinate to the provider organization that the SPA will manage.
In the example shown in Figure A-1, assume you need to create an SPA for the provider organization named VIS. You could assign the SPA role to user1 in the organization DEF.
The SPA must reside in a subordinate organization because a provider organization node does not contain any users.
Thus, before a provider organization can be managed by an SPA, at least one organization must be created under it. This organization should be designated to hold users who are assigned the SPA role. For more information, see Creating a Provider Organization and Service Provider Administrator, later in this appendix.
Considerations for This Release
In this release of Delegated Administrator, you cannot use the Delegated Administrator console or utility to create an SPA or a provider organization.
To create an SPA or provider organization, you must manually modify the custom service-provider template, da.provider.skeleton.ldif.
For instructions on using the custom service-provider template to perform these tasks, see and Creating a Provider Organization and Service Provider Administrator, later in this appendix.
Organizations Managed by the Service Provider AdministratorThe SPA can create, modify, and delete the following types of organizations that are subordinate to the SPA’s provider organization:
The provider organization, full organization, and shared organization are described in the sections that follow.
Provider Organization
A provider organization is a node in the LDAP directory that logically contains full organizations and shared organizations. The provider organization node has attributes that allow the SPA to manage subordinate organizations.
In the LDAP directory, a provider organization must be located under a mail domain. For an example, see Sample Service-Provider Organization Data, later in this appendix.
A provider organization cannot contain user entries. Instead, users are provisioned in the organizations created under the provider organization.
A provider organization stores directory information about the organizations created under it. For example:
- Whether the provider organization can contain shared organizations, full organizations, or both
- Domain names that can be used by the shared organizations created under this provider organization
- The types and number of Class-of-Services packages available to the organizations created under this provider organization
- The organization designated to be the home of the SPA for the provider organization.
Full Organization
A full organization has the following characteristics:
In the example shown in Figure A-1, user2 belongs to the sesta.com domain and has a mail address of user2@sesta.com.
In the example shown in Figure A-1, the full organization, SESTA, has the domain name sesta.com.
Shared Organization
A shared organization has the following characteristics:
In the example shown in Figure A-1, user5 belongs to the siroe.com domain and has a mail address of user5@siroe.com.
In the example shown in Figure A-1, the shared organization DEF uses the domain name siroe.com.
In the example shown in Figure A-1, both the DEF and HIJ organizations belong to the siroe.com domain.
Creating a Provider Organization and Service Provider AdministratorIn this release of Delegated Administrator, you must use the custom service-provider template (da.provider.skeleton.ldif) provided by Delegated Administrator to create your own provider organizations and SPAs.
Note
You also can install a sample provider organization (with subordinate organizations) and a sample SPA in your directory when you run the Delegated Administrator configuration program. You do this by choosing to Load Sample Organizations in the configuration program.
However, the sample organization template (da.sample.data.ldif) is meant to be used as an example, not as a template for creating your own provider organizations. For details about this example, see Sample Service-Provider Organization Data, later in this appendix.
Once you have created a provider organization and an SPA, the SPA can log into the Delegated Administrator console, create and manage subordinate organizations, and assign the SPA role to other users in the SPA’s organization. However, these SPAs can only manage the same provider organization.
To create another provider organization and an SPA to manage it, you should use the custom service-provider template again.
This section contains the following topics:
- Entries Created by the Template shows an example of the organizations created when an edited copy of the template is installed in the directory.
- Information Needed to Create a Provider Organization, Subordinate Organization, and SPA defines the parameters in the template required to create a provider organization, a subordinate shared organization, and an SPA.
- Steps for Creating a Provider Organization and Service Provider Administrator explains how to edit the template and install the information in your directory.
- Custom Service-Provider Template is a listing of the template.
Entries Created by the Template
When you install your edited copy of the custom service-provider template in the directory, the following entries are created:
- A provider organization
- A subordinate shared organization designated to hold the SPA user
- One user in the subordinate organization to whom the SPA role is assigned
- A placeholder node under which full organizations can be created. These full organizations will be managed by the SPA for this provider organization.
Figure A-2 shows an example of the entries created by installing the template. It is a Directory Information Tree (DIT) view of the organizations.
Figure A-2 is only an example. Your organization names, SPA user name, and DIT structure should be specific to your own installation.
Figure A-2
Custom Service-Provider Template: Directory Information Tree View
Nodes in the Sample Installed Custom Service-Provider Template
The nodes in the example shown in Figure A-2 are as follows:
- o=usergroup - The root suffix for user/group data.
- o=siroe.com - The mail domain used by the provider organization.
- o=MyProviderOrg - The provider organization node.
- o=MySPAUserOrg - The subordinate shared organization designated to hold the provider organization users, including the user assigned the SPA role.
- ou=people - The standard LDAP organization unit required for containing users.
- uid=user1 - The uid of the user in the MySPAUserOrg organization who is assigned to be the SPA.
- o=MyProviderOrgDomainsRoot - The placeholder node for holding full organizations subordinate to the MyProviderOrg provider organization.
Information Needed to Create a Provider Organization, Subordinate Organization, and SPA
To create a provider organization, one subordinate organization, and an SPA, you need to replace parameters in the custom service-provider template with information specific to your installation.
As you read about these parameters, you can look at a listing of the da.provider.skeleton.ldif shown in Custom Service-Provider Template. Or open the actual ldif file, located in the following directory:
da_base/lib/config-templates
For definitions of the attributes associated with these parameters, see “Chapter 5: Classes and Attributes Used by Communications Services Delegated Administrator (Schema 2)” and “Chapter 3: Attributes” in the Sun Java System Communications Services Schema Reference.
Parameters Defining the Provider and Subordinate Organization
To create a provider organization and subordinate organization, edit the following parameters:
Name of the provider organization. The directory node where the provider organization resides will be given this name.
This parameter is used multiple times in the da.provider.skeleton.ldif template.
Examples:
sunProviderOrgDN: o=MyProviderOrg,o=siroe.com,o=usergroup
o=MyProviderOrg
sunBusinessOrgBase: o=MyProviderOrgdomainsroot, o=usergroup
Name of a Service package that can be assigned to users in the organizations subordinate to the provider organization. This is a multivalued parameter.
In the “Provider Organization” section of the da.provider.skeleton.ldif file, you will see the following attribute:
sunIncludeServices: <servicepackage>
For each Service package you want to include in the provider organization, add one instance of the sunIncludeServices attribute and servicepackage parameter. Only those Service packages listed here can be assigned to users in subordinate organizations.
Example:
sunIncludeServices: gold
sunIncludeServices: platinum
sunIncludeServices: ruby
sunIncludeServices: silverIf you do not use the sunIncludeServices attribute (if you delete the line containing the servicepackage parameter), all Service packages in the directory can be assigned.
Domain name that can be assigned to subordinate organizations in the provider organization. This is a multivalued parameter.
In the “Provider Organization” section of the da.provider.skeleton.ldif file, you will see the following attribute:
sunAssignableDomains: <domain_name>
The domain names in the sunAssignableDomains attribute are a subset (some or all) of the names listed in the mail domain organization’s sunPreferredDomain and associatedDomain attributes. (The mail domain is the organization under which this provider organization is created.)
For each domain name you want to include in the provider organization, add one instance of the sunAssignableDomains attribute and domain_name parameter. Only the domain names listed here can be assigned to subordinate organizations.
Example:
sunAssignableDomains: siroe.com
sunAssignableDomains: siroe.net
sunAssignableDomains: varrius.com
sunAssignableDomains: sesta.com
sunAssignableDomains: sesta.net
Name of the shared organization in which the SPA user resides. When you install the edited ldif information in the directory, this organization is created as shared and subordinate to the provider organization. It is designated as the organization that contains the SPA user. Other users who are assigned the SPA role for this provider organization must reside in this subordinate shared organization.
In the “Provider Organization” section of the da.provider.skeleton.ldif file, you will see the following attribute:
sunProviderOrgDN:
o=<provider_sub_org>,o=<providerorg>,<maildomain_dn>The sunProviderOrgDN attribute identifies the organization designated for provider organization users, particularly the SPA user.
Example:
sunProviderOrgDN:
o=MySPAUserOrg,o=MyProviderOrg,o=siroe.com,o=usergroup
Machine name of the preferred mail host for the provider organization’s subordinate organization (in which the SPA user resides). You must use a fully qualified domain name (FQDN).
In the “Shared Subordinate Organization” section of the da.provider.skeleton.ldif file, you will see the following attribute:
preferredMailHost: <preferredmailhost>
Example:
preferredMailHost: mail.siroe.com
Domain name that can be assigned to a user in a particular subordinate organization. This is a multivalued parameter.
The values for available_domain_name are a proper subset of the values given for the sunAssignableDomains: <domain_name> attribute and parameter. Whereas domain_name applies to the entire provider organization, available_domain_name applies to a single subordinate organization.
In the “Shared Subordinate Organization” section of the da.provider.skeleton.ldif file, you will see the following attribute:
sunAvailableDomainNames: <available_domain_name>
For each domain name you want this subordinate organization to inherit from the list of domain names in the provider organization’s sunAssignableDomains attribute, add one instance of the sunAvailableDomains attribute and available_domain_name parameter. Only the domain names listed here can be assigned to the subordinate organization.
Example:
sunAvailableDomainNames: siroe.com
sunAvailableDomainNames: siroe.net
sunAvailableDomainNames: varrius.com
Service package available to a particular subordinate organization. This is a multivalued parameter.
The Service packages assigned to the subordinate organization are a subset of those assigned to the entire provider organization with the sunIncludeServices attribute.
In the “Shared Subordinate Organization” section of the da.provider.skeleton.ldif file, you will see the following attribute:
sunAvailableServices: <available_services>
The format of the available_services parameter is
Service package name: count
where count is an integer. If count is absent, the default value is an unlimited number.
For each Service package you want this subordinate organization to inherit from the Service packages available in the provider organization’s sunIncludeServices attribute, add one instance of the sunAvailableServices attribute and available_services parameter.
Example:
sunAvailableServices: gold:1500
sunAvailableServices: platinum:2000
sunAvailableServices: silver:5000Parameters Defining the SPA
To create an SPA, edit the following parameters:
The Service package assigned to the SPA user. For information about Service packages, see Service Packages in Chapter 1, “Delegated Administrator Overview.”
Example:
inetCos: platinum
The mail address of the SPA user. The domain part of the mail address must be one of the domain values that replace the available_domain_name parameter. That is, it must be a domain that has been made available for use in the subordinate organization in which the SPA user resides. For more information, see available_domain_name.
Example:
mail: user1@siroe.com
For instructions in how to edit the custom service-provider template and install the information in your directory, see Steps for Creating a Provider Organization and Service Provider Administrator.
Steps for Creating a Provider Organization and Service Provider Administrator
To create a provider organization and a Service Provider Administrator, follow these steps:
- Create a mail domain in the directory.
If you have not already done so, create a mail domain in your directory. The provider organization and its subordinate shared organizations will use this mail domain.
- Copy and rename the da.provider.skeleton.ldif file.
When you install Delegated Administrator, the da.provider.skeleton.ldif file is installed in the following directory:
da_base/lib/config-templates
- Edit the following parameters in your copy of the da.provider.skeleton.ldif file. Replace the parameters with the correct values for your installation.
For definitions of the parameters, see Information Needed to Create a Provider Organization, Subordinate Organization, and SPA.
Some parameters are used more than once in the ldif file. You must search for and replace all instances of each parameter.
A few parameters represent values for multivalued attributes. You can copy and edit these parameters, together with their associated attribute names, to allow multiple instances of these attributes in your ldif file. Multivalued parameters are noted below.
- <ugldapbasedn>
- <maildomain_dn>
- <maildomain_dn_str>
- <providerorg>
- <servicepackage> (multivalued)
- <domain_name> (multivalued)
- <provider_sub_org>
- <preferredmailhost>
- <available_domain_name> (multivalued)
- <available_services> (multivalued)
- <spa_uid>
- <spa_password>
- <spa_firstname>
- <spa_lastname>
- <spa_servicepackage>
- <spa_mailaddress>
For definitions of the attributes associated with these parameters, see “Chapter 5: Classes and Attributes Used by Communications Services Delegated Administrator (Schema 2)” and “Chapter 3: Attributes” in the Sun Java System Communications Services Schema Reference.
- Use the LDAP directory tool ldapmodify to install the provider organization and SPA in the directory.
For example, you could run the following command:
ldapmodify -D <directory manager> -w <password>
-f <da.provider.finished.ldif>where
<directory manager> is the name of the Directory Server administrator.
<password> is the password of the Directory Service administrator.
<da.provider.finished.ldif> is the name of the edited ldif file to be installed as a new provider organization and SPA in the directory.
Custom Service-Provider Template
The template (da.provider.skeleton.ldif) contains parameters that you must modify to create a new provider organization and SPA.
The listing below shows the sections of the ldif file that have parameters. The listing does not include the entire file. Entries and ACIs required to support Access Manager are not included here.
You should only modify the parameters in the ldif file. Do not modify the sections of the file related to Access Manager.
da.provider.skeleton.ldif File (Relevant Sections)
#
# The following parameterized values must be replaced.
#
# <ugldapbasedn> :: Root suffix for user/group data
# <maildomain_dn> :: Complete dn of the mail domain underneath which the
# provider organization will be created.
# <maildomain_dn_str> :: The maildomain dn with all ',' replaced by '_'. E.g.
# dn --> o=siroe.com,o=SharedDomainsRoot,o=Business,
# dc=red,dc=iplanet,dc=com
# dn_str --> o=siroe.com_o=SharedDomainsRoot_o=Business_
# dc=red_dc=iplanet_dc=com
# <providerorg> : Organization value for provider node.
# <servicepackage> :: One for each service package to include.
# All service packages in the system may be assigned
# by leaving this value empty.
# <domain_name> :: One for each DNS name which may be assigned to a
# subordinate organization.
# These names form a proper subset (some or all) of the
# names listed in the <maildomain> organization's
# sunpreferreddomain and associateddomain attributes.
# <provider_sub_org> :: Organization value for the shared subordinate
# organization in which the Provider Administrator resides.
# <preferredmailhost> :: Name of the preferred mail host for the provider's
# subordinate organization.
# <available_domain_name> :: one for each DNS name that an organization allows an
# organization admin to use when creating a user's mail
# address. This is a proper subset of the values given
# for <domain_name> (sunAssignableDomains attribute).
# <available_services> :: One for each service packags available to an
# organization (sunAvailableServices attribute). These
# service packages form a proper subset of the ones
# assigned to a provider organization - <servicepackage> # (sunIncludeServices attribute). Form is
# <service package name>:<count>
# where count is an integer. If count is absent then
# default is unlimited.
# <spa_uid> :: The uid for the service provider administrator.
# <spa_password> :: The password for the service provider administrator.
# <spa_firstname> :: First name of the service provider administrator.
# <spa_lastname> :: Last name of the service provider administrator.
# <spa_servicepackage> :: Service package assigned to the service provider
# administrator.
# <spa_mailaddress> :: The spa's mail address. The domain part of the mail
# address must be one of the values used for
# <available_domain_name>.
#
#
# Provider Organization
#
dn: o=<providerorg>,<maildomain_dn>
changetype: add
o: <providerorg>
objectClass: top
objectClass: sunismanagedorganization
objectClass: sunmanagedorganization
objectClass: organization
objectClass: sunManagedProvider
sunAllowBusinessOrgType: full
sunAllowBusinessOrgType: shared
sunBusinessOrgBase: o=<providerorg>domainsroot,<ugldapbasedn>
sunIncludeServices: <servicepackage>
sunAssignableDomains: <domain_name>
sunAllowMultipleDomains: true
sunAllowOutsideAdmins: false
sunProviderOrgDN: o=<provider_sub_org>,o=<providerorg>,<maildomain_dn>
# .
# .
# [Entries and ACIs required by Access Manager]
# .
# .
#
# Full Organizations node
#
dn: o=<providerorg>DomainsRoot,<ugldapbasedn>
changetype: add
o: <providerorg>DomainsRoot
objectClass: top
objectClass: organization
objectClass: sunmanagedorganization
# .
# .
# [Entries and ACIs required by Access Manager]
# .
# .
#
# Provider Admin Role shared organizations
#
dn: cn=Provider Admin Role,o=<providerorg>,<maildomain_dn>
changetype: add
cn: Provider Admin Role
objectClass: ldapsubentry
objectClass: nssimpleroledefinition
objectClass: nsroledefinition
objectClass: nsmanagedroledefinition
objectClass: iplanet-am-managed-role
objectClass: top
iplanet-am-role-description: Provider Admin
#
# Provider Admin Role full organizations
#
dn: cn=Provider Admin Role,o=<providerorg>DomainsRoot,<ugldapbasedn>
changetype: add
cn: Provider Admin Role
objectClass: ldapsubentry
objectClass: nssimpleroledefinition
objectClass: nsroledefinition
objectClass: nsmanagedroledefinition
objectClass: iplanet-am-managed-role
objectClass: top
iplanet-am-role-description: Provider Admin
#
# Shared Subordinate Organization. Includes 1 users who is the Provider Administrator.
#
dn: o=<provider_sub_org>,o=<providerorg>,<maildomain_dn>
changetype: add
preferredMailHost: <preferredmailhost>
sunNameSpaceUniqueAttrs: uid
o: <provider_sub_org>
objectClass: inetdomainauthinfo
objectClass: top
objectClass: sunismanagedorganization
objectClass: sunnamespace
objectClass: sunmanagedorganization
objectClass: organization
objectClass: sunDelegatedOrganization
objectClass: sunMailOrganization
sunAvailableDomainNames: <available_domain_name>
sunAvailableServices: <available_services>
sunOrgType: shared
sunMaxUsers: -1
sunNumUsers: 1
sunMaxGroups: -1
sunNumGroups: 0
sunEnableGAB: true
sunAllowMultipleServices: true
inetDomainStatus: active
sunRegisteredServiceName: GroupMailService
sunRegisteredServiceName: DomainMailService
sunRegisteredServiceName: UserMailService
sunRegisteredServiceName: iPlanetAMAuthService
sunRegisteredServiceName: UserCalendarService
sunRegisteredServiceName: iPlanetAMAuthLDAPService
sunRegisteredServiceName: DomainCalendarService
# .
# .
# [Entries and ACIs required by Access Manager]
# .
# .
dn: ou=People,o=<provider_sub_org>,o=<providerorg>,<maildomain_dn>
changetype: add
ou: People
objectClass: iplanet-am-managed-people-container
objectClass: organizationalUnit
objectClass: top
dn: ou=Groups,o=<provider_sub_org>,o=<providerorg>,<maildomain_dn>
changetype: add
ou: Groups
objectClass: iplanet-am-managed-group-container
objectClass: organizationalUnit
objectClass: top
# .
# .
# [Entries and ACIs required by Access Manager]
# .
# .
#
# User - provider administrator
#
dn: uid=<spa_uid>,ou=People,o=<provider_sub_org>,o=<providerorg>,<maildomain_dn>
changetype: add
sn: <spa_lastname>
givenname: <spa_firstname>
cn: <spa_firstname> <spa_lastname>
uid: <spa_uid>
iplanet-am-modifiable-by: cn=Top-level Admin Role,<ugldapbasedn>
objectClass: inetAdmin
objectClass: top
objectClass: iplanet-am-managed-person
objectClass: iplanet-am-user-service
objectClass: iPlanetPreferences
objectClass: person
objectClass: organizationalPerson
objectClass: inetuser
objectClass: inetOrgPerson
objectClass: ipUser
objectClass: inetMailUser
objectClass: inetLocalMailRecipient
objectClass: inetSubscriber
objectClass: userPresenceProfile
objectClass: icsCalendarUser
mailhost: <preferredmailhost>
mail: <spa_mailaddress>
maildeliveryoption: mailbox
mailuserstatus: active
inetCos: <spa_servicepackage>
inetUserStatus: Active
nsroledn: cn=Provider Admin Role,o=<providerorg>,<maildomain_dn>
userPassword: <spa_password>
Sample Service-Provider Organization DataYou can choose to install sample organization data (defined in an ldif file) in your directory when you run the Delegated Administrator configuration program, config-commda. (When you run the configuration program, select Load sample organizations in the Service Package and Organization Samples panel.) The configuration program adds the da.sample.data.ldif file to the LDAP directory tree.
This ldif file is meant to be used as an example, not as a template for creating your own provider organizations. To create a new provider organization, see Information Needed to Create a Provider Organization, Subordinate Organization, and SPA.
Organizations Provided by the Sample Data
Figure A-1 shows a logical view of the organizational structure provided by the sample ldif file. (Figure A-1 adds a shared organization, HIJ, that does not exist in the file.)
The sample ldif file contains the following organizations under the root-suffix nodes:
The ldif file defines the following administrator roles for these organizations:
Logical Hierarchy and the Directory Information Tree
In a three-tiered directory hierarchy, a Directory Information Tree (DIT) does not look exactly like the logical view shown in Figure A-1. Organizations are implemented in the DIT in a somewhat different hierarchy.
For example, in a DIT, full domains must reside directly under the root suffix. Therefore, domain nodes are added under the root suffix to store LDAP information for shared domains (used by shared organizations) and for full organizations (which have their own domains).
Sample Organization Data: Directory Information Tree View
Figure A-3 shows a Directory Information Tree (DIT) view of the sample organization data.
The example shown in Figure A-3, like the logical view shown in Figure A-1, contains the following organizations:
Nodes in the Sample Directory Information Tree
The nodes in the sample organization file (da.sample.data.ldif) are as follows:
User DNs in the Sample Directory Information Tree
Some user DNs in the sample organization file shown in Figure A-3 are as follows: