Appendix A Service Provider Administrator and Service Provider Organizations

The 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:

• Service Provider Administrator

• Organizations Managed by the Service Provider Administrator

• Creating a Provider Organization and Service Provider Administrator

• Creating Shared and Full Subordinate Organizations

• Sample Service-Provider Organization Data

This appendix describes the Service Provider Administrator role and the new organization types and explains how to create them in Delegated Administrator.

Service Provider Administrator

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

  SESTA is a full organization and has its own unique namespace. user1 in SESTA (in the sesta.com domain) has a unique user ID.

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:

• Create, delete, and modify shared and full organizations in the provider organization in which the SPA has administrative authority.

  In the example shown in Figure A–1, the SPA for the VIS provider organization can

  • Modify or delete the DEF, HIJ, and SESTA organizations

  • Create additional organizations under the VIS provider organization.

• Create, delete, and modify users in any organization under the provider organization.

• Create, delete, and modify groups in any organization under the provider organization.

• Create, delete, and modify Calendar resources in any organization under the provider organization.

• Assign OA roles to users.

  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.

• Assign the SPA role to other legitimate users under the provider organization (and remove the SPA role).

• Allocate service packages to organizations.

  For information about service packages, see Service Packages in Chapter 1, Delegated Administrator Overview.

  The SPA 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 SPA could assign the following service packages:

  • In the DEF organization:

    1,000 gold packages 500 platinum packages

  • In the HIJ organization:

    2,500 topaz packages 500 platinum packages 500 emerald packages 1,000 ruby packages

  • In the SESTA organization:

    2,000 silver packages 1,500 gold packages 100 platinum 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.

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 Creating a Provider Organization and Service Provider Administrator, later in this appendix.

Organizations Managed by the Service Provider Administrator

The SPA can create, modify, and delete the following types of organizations that are subordinate to the SPA’s provider organization:

• Full Organization

• Shared 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:

• It is subordinate to the provider organization and is created by the SPA.

• Users can be provisioned in a full organization.

  In the example shown in Figure A–1, user2 belongs to the sesta.com domain and has a mail address of user2@sesta.com.

• As a full organization, it has its own domain that no other organization can share, and it has its own unique namespace.

  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:

• It is subordinate to the provider organization and is created by the SPA.

• Users can be provisioned in a shared organization.

  In the example shown in Figure A–1, user5 belongs to the siroe.com domain and has a mail address of user5@siroe.com.

• It uses one or more of the shared domain names from the list provided by the provider organization.

  In the example shown in Figure A–1, the shared organization DEF uses the domain name siroe.com.

• Other shared organizations can share the domain name used by this organization.

  In the example shown in Figure A–1, both the DEF and HIJ organizations belong to the siroe.com domain.

• A shared organization does not have a unique namespace.

Creating a Provider Organization and Service Provider Administrator

In 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: Communications Services Delegated Administrator Classes and Attributes (Schema 2)” and “Chapter 3: Messaging Server and Calendar Server 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:

• ugldapbasedn

  Root suffix of user/group data in your directory.

  Examples:

  o=usergroup

  dc=red,dc=iplanet,dc=com

• maildomain_dn

  Complete DN of the mail domain underneath which the provider organization will be created.

  Examples:

  o=siroe.com, o=usergroup

  o=sesta.com,o=SharedDomainsRoot,o=Business,dc=red, \ dc=iplanet,dc=com

• maildomain_dn_str

  The mail domain DN with all commas (,) replaced by underscores (_).

  For example, if the mail domain DN is

  o=siroe.com,o=SharedDomainsRoot,o=Business,dc=red, \ dc=iplanet,dc=com

  The mail domain DN string will be

  o=siroe.com_o=SharedDomainsRoot_o=Business_dc=red_ \ dc=iplanet_dc=com

• providerorg

  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

• servicepackage

  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: silver

  If 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

  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

• provider_sub_org

  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

• preferredmailhost

  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

• available_domain_name

  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

• available_services

  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:5000

Parameters Defining the SPA

To create an SPA, edit the following parameters:

• spa_uid

  The user ID for the SPA user.

  Example:

  uid: user1

• spa_password

  The password for the SPA user.

  Example:

  userPassword: x12P3&qrS

• spa_firstname

  The first name of the SPA user.

  Example:

  givenname: John

• spa_lastname

  The last name of the SPA user.

  Example:

  sn: Smith

• spa_servicepackage

  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

• spa_mailaddress

  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 Parameters Defining the Provider and Subordinate Organization.

  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

You use an ldif file, da.provider.skeleton.ldif, to perform the following procedure.

To create a provider organization and Service Provider Administrator

Steps

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

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

3. 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: Communications Services Delegated Administrator Classes and Attributes (Schema 2)” and “Chapter 3: Messaging Server and Calendar Server Attributes” in the Sun Java System Communications Services Schema Reference.

4. 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 user who is 
# the Provider Administrator.
#
dn: o=<provider_sub_org>,=<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>

Creating Shared and Full Subordinate Organizations

Once you have created a provider organization and an SPA, the SPA can create and manage both shared and full organizations subordinate to the provider organization. The SPA uses the Delegated Administrator console to accomplish these tasks.

The following task outlines the key steps in creating a shared organization or a full organization. This task does not describe how to enter all the information displayed when you create an organization with the Create New Organization wizard. For detailed descriptions of the Create New Organization wizard, see the Delegated Administrator console online help.

To create a shared or full subordinate organization

Steps

1. Launch the Delegated Administrator console.

   Go to the following url:

   http://host:port/da/DA/Login

   where

   host is the Web container host machine

   port is the Web container port

   For example:

   http://siroe.com:8080/da/DA/Login

   The Delegated Administrator console log-in window appears.

2. Log in to the Delegated Administrator console using the SPA login ID and password.

   The preceding section, Creating a Provider Organization and Service Provider Administrator, describes how to create an SPA.

   The Service Provider Administrator page appears. The Organizations tab is selected by default. The page displays the organizations subordinate to the SPA's provider organization.

3. Click New Organization.

   The Create New Organization wizard appears. For details about entering and selecting information in the Create New Organization wizard, see the Delegated Administrator console online help.

4. Enter information in the Organization Information panel and click Next.

   The Contact Information panel appears.

5. Enter information in the Contact Information panel and click Next.

   The Account Information panel appears.

6. Choose whether to create a shared organization or full organization.

   In the Account Information panel, you determine whether the new organization will be shared or full.

   A shared organization uses an existing domain shared with other organizations.

   A full organization has its own unique domain.

   • To create a shared organization, click the Select from available domains radio button.

     From the drop-down list, choose a domain.

     ---

     Note –

     When you create a shared organization, the Calendar service details are inherited from the existing parent domain. Therefore, you will not enter Calendar service information for the new organization. The Calendar Service Details panel will not appear in the Create New Organization wizard. Furthermore, after the shared organization is created, Calendar Service Details do not appear in the organization's Properties page.

     ---

   • To create a full organization, click the New domain radio button.

     In the text box, enter a new mail domain name. For example: siroe.com.

     If you wish, enter alias names for the new domain in the Alias Names for the New Domain text box.

7. Enter information in the remaining panels of the Create New Organization wizard.

   For details about these panels, see the Delegated Administrator console online help.

Sample Service-Provider Organization Data

You 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–1shows 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:

• VIS provider organization. The following organizations are managed by the SPA for the VIS provider organization:

  • SESTA, a full organization. The SESTA organization has its own domain, sesta.com.

  • DEF, a shared organization. The DEF organization uses the shared domain, siroe.com.

• ESG provider organization. No subordinate organizations are defined for this provider organization.

The ldif file defines the following administrator roles for these organizations:

• An SPA for the VIS provider organization (user2@abc.com)

• An SPA for the ESG provider organization (user2_def)

• An OA for the SESTA organization (user1@abc.com)

• An OA for the DEF organization (user1_def)

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:

• VIS and ESG (provider organizations)

• DEF, a shared organization subordinate to the VIS provider organization

• SESTA, a full organization subordinate to the VIS provider organization

Figure A–3 Sample Organization Data: Directory Information Tree View

Nodes in the Sample Directory Information Tree

The nodes in the sample organization file (da.sample.data.ldif) are as follows:

• ugldapbasedn - This parameter represents the root suffix.

• o=business - A node that contains all businesses in the directory.

• o=SharedDomainsRoot - A node needed to contain the domains used by shared organizations.

  In this Directory Information Tree, shared organizations subordinate to different service provider organizations can use the same shared domain. This can be done because both the provider organizations have nodes under the SharedDomainsRoot node.

• o=ESGDomainsRoot and o=VISDomainsRoot - These nodes contain any full organizations that are subordinate to the ESG and VIS provider organizations.

  Each provider organization that manages full organizations must have a node at this level (under the root suffix).

  Multiple full organizations, each with its own domain, can exist under ESGDomainsRoot or VISDomainsRoot.

• o=siroe.com - The shared domain. It is used by the shared organization, DEF.

• o=VIS and o=ESG - These provider organization nodes contain any shared organizations subordinate to the VIS and ESG provider organizations.

  For example, the shared organization, DEF, is subordinate to the VIS provider organization.

• o=SESTA - The full organization. It has its own domain, sesta.com.

• o=DEF - The shared organization. It uses the domain siroe.com.

• ou=people - The standard LDAP organization unit required for containing users.

User DNs in the Sample Directory Information Tree

Some user DNs in the sample organization file shown in Figure A–3 are as follows:

• For the user named user1_def, who belongs to the DEF organization:

  dn: uid=user1_def,ou=People,o=DEF,o=VIS,o=siroe.com, o=SharedDomainsRoot,o=Business,ugldapbasedn

• For the user named user1, who belongs to the SESTA organization:

  dn: uid=user1,ou=People,o=SESTA,o=VISDomainsRoot, o=Business,ugldapbasedn