Chapter 1   Provisioning Concepts and Technologies


This chapter describes the concepts and technology of provisioning the iPlanet Message Server. It contains the following sections:

• "iPlanet Messaging Server Namespace"

• "iPlanet Messaging Server Data Model"

• "ACI Architecture"

• "Class of Service"

Provisioning the iPlanet Message Server

---

Provisioning is the adding, modifying or deleting of iPlanet Messaging Server user, mailing list, system administrator, and domain entries in the directory server. The messaging server queries the directory for information about these elements as needed.

There are four provisioning interfaces in the iPlanet Messaging Server:

• The iPlanet Delegated Administrator for Messaging console

• The iPlanet Delegated Administrator for Messaging command line utilities

• The iPlanet Messaging Server Administration Console

• The Messaging Server LDAP directory

This guide describes how to provision through LDAP. Reference may be made to other methods of provisioning, but the focus of this manual is provisioning through LDAP.

iPlanet Messaging Server Namespace

---

As installed, the iPlanet Messaging Server namespace consists of two directory information trees (DIT), an Organization Tree and a Domain Component Tree (DC Tree). Organization Trees contain the user and group entries. The DC Tree mirrors the local DNS structure and is used by the system as an index to the Organization Tree(s) containing the data entries (see Figure 1-2). The DC Tree also contains the domain's operating parameters such as smart hosts, routing hosts, domain disk quota, and so on.

The sections below describe the two-tree mechanism—how it works and why it was chosen. Further information, including how to port existing DITs to the iPlanet Messaging Server's two-tree mechanism, is provided in the iPlanet Messaging Server Migration Guide.

How the Two-tree Namespace Mechanism Works

This section describes how the iPlanet Messaging Server uses the two-DIT mechanism.

When the iPlanet Messaging Server searches for user/group entries, it first looks at the user/group's domain node in the DC Tree and extracts the value of the inetDomainBaseDN attribute. This attribute holds a DN reference to the organization subtree containing the actual user/group entry.

Using this model, the iPlanet Messaging Server can support entries stored in any type of directory Tree, provided that a domain component node in the DC Tree points to the node in the Organization Tree under which the users for that domain can be found. This relationship is reflected in the example shown in Figure 1-1 where the dotted line indicates the value of inetDomainBaseDN. Note that the node names in the Organization Tree do not have to match those in the DC Tree.

Figure 1-1    iPlanet Messaging Server Directory Structure—Example

In this example, data entries are added and modified under the Organization Tree, but the message server actually references the DC Tree. Let's consider three users:

	User 1	User 2	User 3
Name:	John Doe	John Doe	Jane Doe
Domain:	siroe.com	west.siroe.com	varrius.org
UID:	jdoe	jdoe	jdoe
Login:	jdoe@siroe.com	jdoe@west.siroe.com	jdoe@varrius.org

The login is derived from the UID and domain. In each of these cases, the server looks at the domain part of the login (the value after the @ sign) and retrieves the DN from the inetdomainbasedn attribute of the corresponding DC node. It then searches the subtree pointed at by the DN for a user entry where the UID equals the local part of the login (the value before the @ sign).

John Doe in west.siroe.com logs into the server using the login jdoe@west.siroe.com. The server follows the DN reference (inetdomainbasedn) in the DC node for west.siroe.com over to the subtree o=west.siroe.com, o=isp. It then searches for a user entry where the uid=jdoe in this subtree.

At installation, the iPlanet Messaging Server creates a default DC Tree and Organization Tree that is mapped to your existing DNS. When directory domain nodes are added using the Delegated Administrator command imadmin domain create, corresponding nodes are created in both the DC Tree and the Organization Tree. If you create nodes using the LDAP interface, you must create a node for the domain in the DC Tree, and a domain for the data in the Organization Tree. This is described in the iPlanet Messaging Server Migration Guide.

---

Note	In order for mail to be delivered you must make sure that the domain has an MX record in the DNS.

---

Why Two Directory Information Trees?

Although the iPlanet Messaging Server supports a single DC Tree containing configuration and user/group data, as installed, the iPlanet Messaging Server creates both a DC Tree and Organization Tree. This dual-tree mechanism provides the following enhancements:

• The ability to adopt existing directory deployments into iPlanet Messaging Server by creating a DC Tree that maps to existing DITs.

• The partitioning of data for organization-specific access control. That is, each organization can have a separate subtree in the DIT where user and group entries are located. Access to that data can be limited to users in that part of the subtree. This allows localized applications, such as iPlanet Delegated Administrator for Messaging to operate securely.

• The ability to have a distinct namespace for subdomains. For example, west.siroe.com and siroe.com may be mapped to separate organization subtrees allowing the creation of user entries with the same UID in each one of them.

Mapping an Existing DIT to iPlanet Messaging Server

The two-tree mechanism allows mapping existing DITs to the iPlanet Messaging Server. This is shown in the figure below which depicts an existing NMS DIT (o=siroe.com) mapped to a DC Tree in the iPlanet Messaging Server. This process is described in detail in the iPlanet Messaging Server Migration Guide.

Figure 1-2    Mapping Existing DIT to iPlanet Messaging Server—Example

Partitioning Data for Access Control

The two-tree mechanism provides for data partitioning and access control within each partition. This feature is important in a multi-tenant directory since it is a strict requirement that one customer cannot access data pertaining to other customers stored in the same directory tree. Data partitioning and access control permit outsourcing of applications to distinct customer organizations in a secure manner such that user/group data for each organization can be stored separately from other organizations. An example of this type of application is the iPlanet Delegated Administrator for Messaging.

For this reason, outsourced messaging customers are represented in a well-defined subtree (typically a domain) within the overall DIT. This subtree is used to store all service data belonging to the customer. This concept is depicted in Figure 1-3.

Figure 1-3    Partitioning Data for TEST Access Control—Example

Providing Distinct Namespaces for Subdomains

The two-tree mechanism provides distinct namespaces for subdomains. This allows the same login name to be used in subdomains, for example, jdoe@siroe.com and jdoe@west.siroe.com can be two separate and legal email addresses. This is shown in Figure 1-1.

iPlanet Messaging Server Data Model

---

The basic data model of the iPlanet Messaging Server object classes is to extend LDAP entry types (for example, user, group, domain) created by core object classes by overlaying them with shared classes (object classes can be shared by more than one service) and service-specific object classes (classes specific to a certain type of server). This relationship is depicted in the table below.

Table 1-1    Entry types and Corresponding Object Classes

	Core Classes	Shared Classes	Messaging Server Classes
DC Tree Domain	domain, inetdomain		mailDomain, nsManagedDomain, icsCalendarDomain
Org. Tree Domain	organization		nsManagedDomain
Email User	person, inetUser, organizationalPerson, inetOrgPerson	ipUser, userPresenceProfile	inetMailUser, inetLocalMailRecipient, nsManagedPerson
Group	groupOfUniqueNames		inetMailGroup, inetLocalRecipient, inetMailGroupManagement, nsManagedMailList
Family Account	inetManagedGroup		nsManagedDept

Using email user type as an example, the following object classes provide the following types of attributes:

person provides attributes for describing a person.

organizationalPerson provides attributes for describing a person belonging to an organization.

inetOrgPerson provides basic internet user attributes.

ipUser holds the personal address book attribute, the class of service template, and the DN of the family account as applicable.

inetUser represents a user account and is used in conjunction with inetMailUser and ipUser for creating a mail account.

inetSubscriber is an optional object class that represents a subscriber account. It provides account ID and challenge/response attributes.

inetMailUser represents a mail account and provides most of the user specific mail account attributes.

inetLocalMailRecipient represents a local (intra-organizational) email recipient specifying the recipient's email address(es), and providing routing information pertinent to the recipient.

ACI Architecture

---

Access Control Information instructions (ACIs) control user access to the directory. There are several types of messaging server users which require different levels of access to the directory. Some of these user types are as follows:

• Normal email user. This user type simply sends and receives email and requires such permissions as modifying password and starting vacation mode.

• Top-level administrator has permission to do anything to any entry in the directory.

• Message Store Administrator has permissions to view mailboxes and manage the message store for the system or domain.

• Domain Administrator can create, modify and delete mail user, mailing list, and family account entries in a domain.

• Domain Organization Administrator creates, modifies and deletes mail user and mailings list entries in a domain organization.

• Family Group Administrator has permission to add and remove family members in a family group entry.

Each of these user types have specific ACIs assigned to them at the root or domain level of the DC and Organization Trees (Figure 1-4). By assigning ACIs in the root and domain entries instead of for each user, access can be scoped to a domain or to the entire system. Thus, ACIs specified on the root node will apply to entries in the entire system, while ACIs specified in a domain apply only to entries in that domain. (For detailed ACI information see the iPlanet Directory Administration Guide.)

ACIs for the various administrators are conferred upon specific groups. To create an administrator you simply add a user to the group and add a group back pointer attribute (memberof) in the user entry. For example, at installation a group called cn=Domain Administrators, ou=groups, <DN of domain> is created with specific ACI privileges. To create a Domain Administrator, simply add a user to the group and add the memberof attribute to the user's entry.

To create a Family Group Administrator, a user is added to the mailing list
cn=Family Group Administrators, ou=groups, <DN of domain>
For complete instructions on creating administrators, see Chapter 6 "Provisioning Messaging Server Administrators."

In the configuration shown below. ACIs will be specified in the following entries:

o=isp
o=sesta.com,o=isp
o=siroe.com,o=isp
o=internet
dc=siroe, dc=com, o=internet
dc=sesta, dc=com, o=internet

The ACIs installed for domains and root entry nodes are shown in Figure 1-4.

Figure 1-4    ACI Example

Class of Service

---

The class of service (COS) feature allows you to create a named set of fixed features and attributes that can be applied to specified users. The class of service feature allows you to create a template of attributes which can be conferred upon user entries with a single attribute. For example, if you are an ISP, you could create two levels of mail service called Hall of Fame and All-Star. The Hall of Fame class of service could provide users with IMAP, secure IMAP, POP3, and HTTP (Web mail) mail services as well as 5 gigabytes of message store disk space. The All-Star class of service could provide POP3 mail services along with five megabytes of message store disk space.

---

Note

LDAP search requests containing a filter that references an attribute defined by class of service will not be serviced. For example, you cannot successfully search on the attribute mailquota if mailquota is only defined in a class of service template and not in user entries. The server will respond with an unwilling to perform error message when presented with such a request.

---

Setting Up Class of Service for the iPlanet Messaging Server

The basic procedures for adding the class of service feature is as follows:

1. Add the COS plug-in to slapd.ldbm.conf.

2. Create a COS mail scheme entry. The COS mail scheme defines the following:
   • Location of COS template definitions in the directory.

   • Directories containing the user entries to which the class of service can be applied.

   • Name of the attribute (inetCOS) used to specify the class of service template applied to a user entry.

   • A list of attributes to be used in a template.

3. Create the class of service template entries.

4. Assign a class of service to user entries.

These procedures are described in detail at the following web site:

http://docs.iplanet.com/docs/manuals/deladmin/45/html/06_cos.htm#25217

Specific iPlanet Messaging Server class of service issues and an example are described in the next section. As you implement the class of service feature in your system, use the following parameter values when you reach the step on Managing COS Schemes:

Table 1-2    iPlanet Messaging Server Class of Service Parameter Values

Parameter	Value
DN of container for class of service schemes and templates	ou=COS, <domain's DN>
DN for Mail Scheme entry	cn=mail scheme, ou=COS, <domain's DN>
DN of class of service container (cosTemplateDn)	ou=MailSchemeTemplates,ou=COS,<domain's DN>
Attribute for assigning a class of service to entries (cosSpecifier)	inetCOS

Class of Service Example

We will use the example described in the previous section by creating two classes of services called Hall of Fame and All-Star mail service for the hosted domain called sesta.com. The Hall of Fame class of service will provide users with IMAP, secure IMAP, POP3, and HTTP (Web mail) mail services as well as 5 gigabytes of message store disk space. The All-Star class of service could provide POP3 mail services along with 5 megabytes of message store disk space.

1. Install the COS plug-in on the Directory Server. For Directory Server 4.1 refer to:
   http: //home.netscape.com/eng/server/directory/DSRK/4.1/cos.htm

   For Directory Server 5.0 refer to:
   http://docs.iplanet.com/docs/manuals/directory/51/html/cli/plugconfig.htm#16608

2. Create the container for COS classes and definitions:

   dn: ou=COS,o=sesta.com, o=isp

   objectclass: top

   objectclass: organizationalUnit

   ou: COS

3. Create a mail scheme entry using the example LDIF entry below:

   dn: uid=mail scheme,ou=COS,o=sesta.com, o=isp

   objectclass: top

   objectclass: cosDefinition

   cosTemplateDn: ou=MailSchemeTemplates,ou=COS,o=sesta.com, o=isp

   cosTargetTree: o=sesta.com, o=isp

   cosSpecifier: inetCOS

   cosAttribute: mailQuota

   cosAttribute: mailAllowedServiceAccess

   • dn: uid=mail scheme,ou=COS,o=sesta.com, o=isp

     COS mail scheme entry DN.

   • objectclass: cosDefinition

     Object class that defines the class of service scheme entry.

   • cosTemplateDn: ou=MailSchemeTemplates,ou=COS,o=sesta.com, o=isp

     Multi-valued attribute that contains the subtree(s) under which the COS template entries for this scheme are stored.

   • cosTargetTree: ou=People,o=sesta.com, o=isp

     Multi-valued attribute that contains the subtree to which the COS scheme applies.

   • cosSpecifier: inetCOS

     Name of the attribute used to specify the COS template applied to a user entry.

   • cosAttribute: mailQuota
     cosAttribute: mailAllowedServiceAccess

     Attributes to be used in a template entry.

4. Create the container for classes.

   Below is the LDIF for two template entries for the Hall of Fame and All-Star templates.

   dn: ou=MailSchemeClasses,ou=COS,o=sesta.com, o=isp

   objectclass: top

   objectclass: organizationalunit

   ou: MailSchemeClasses

5. Create COS template entries.

   Below is the LDIF for two template entries for the Hall of Fame and All-Star templates.

   dn: cn=All-Star,ou=MailSchemeClasses,ou=COS,o=sesta.com, o=isp

   objectclass: top

   objectclass: inetUser

   objectclass: inetMailUser

   mailQuota: 5000000

   mailAllowedServiceAccess: +pop3:*

   dn: cn=Hall of Fame,ou=MailSchemeClasses,ou=COS,o=sesta.com, o=isp

   objectclass: top

   objectclass: inetUser

   objectclass: inetMailUser

   mailQuota: 5000000000

   mailAllowedServiceAccess: +imap, imaps, pop3, http:*

   • dn: cn=All-Star,ou=MailSchemeClasses,ou=COS,o=sesta.com, o=isp
     dn: cn=Hall of Fame,ou=MailSchemeClasses,ou=COS,o=sesta.com, o=isp

     DN of the COS templates

   • objectclass: top
     objectclass: inetUser
     objectclass: inetMailUser
     mailQuota: 5000000
     mailAllowedServiceAccess: +pop3:*

     Attributes and object classes in the All-Star template.

   • objectclass: top
     objectclass: inetUser
     objectclass: inetMailUser
     mailQuota: 5000000
     mailAllowedServiceAccess: +imap, imaps, pop3:*

     Attributes and object classes in the Hall of Fame template.

6. Add class of service templates to users.

   dn: uid=Havlicek,ou=People,o=sesta.com, o=isp

   objectClass: top

   objectClass: person

   objectClass: organizationalPerson

   objectClass: inetOrgPerson

   objectClass: inetUser

   objectClass: ipUser

   objectClass: userPresenceProfile

   objectClass: inetMailUser

   objectClass: inetLocalMailRecipient

   cn: John Havlicek

   sn: Havlicek

   initials: JH

   givenName: John

   mail: john.havlicek@sesta.com

   mailAlternateAddress: Havlicek@sesta.com

   mailHost: mail.siroe.com

   uid: Havlicek

   dataSource: iPlanet Messaging Server

   userPassword: secret

   inetUserStatus: active

   mailUserStatus: active

   mailMsgQuota: 100

   inetCos: Hall of Fame

   dn: uid=Hornicek,ou=People,o=sesta.com, o=isp

   objectClass: top

   objectClass: person

   objectClass: organizationalPerson

   objectClass: inetOrgPerson

   objectClass: inetUser

   objectClass: ipUser

   objectClass: userPresenceProfile

   objectClass: inetMailUser

   objectClass: inetLocalMailRecipient

   cn: Jeff Hornicek

   sn: Hornicek

   initials: JH

   givenName: Jeff

   mail: jeff.hornicek@sesta.com

   mailAlternateAddress: Hornicek@sesta.com

   mailDeliveryOption: mailbox

   mailHost: mail.siroe.com

   uid: Hornicek

   dataSource: iPlanet Messaging Server 5.0

   userPassword: secret

   inetUserStatus: active

   mailUserStatus: active

   mailMsgQuota: 100

   inetCos: All-Star