Previous Contents Index Next |
iPlanet Messaging Server 5.2 Provisioning Guide |
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"
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
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.The iPlanet Delegated Administrator for Messaging command line utilities
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 mechanismhow 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 StructureExample
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 ServerExample
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 ControlExample
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
Shared Classes
Messaging Server Classes
inetMailGroup, inetLocalRecipient, inetMailGroupManagement, nsManagedMailList
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.
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.)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.
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=internetThe 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.
Setting Up Class of Service for the iPlanet Messaging Server
The basic procedures for adding the class of service feature is as follows:
Add the COS plug-in to slapd.ldbm.conf.
These procedures are described in detail at the following web site:Create a COS mail scheme entry. The COS mail scheme defines the following:
Location of COS template definitions in the directory.
Create the class of service template entries.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.
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
Attribute for assigning a class of service to entries (cosSpecifier)
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.
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
Create the container for COS classes and definitions:
- For Directory Server 5.0 refer to:
http://docs.iplanet.com/docs/manuals/directory/51/html/cli/plugconfig.htm#16608
dn: ou=COS,o=sesta.com, o=isp objectclass: top objectclass: organizationalUnit ou: COS Create a mail scheme entry using the example LDIF entry below:
dn: uid=mail scheme,ou=COS,o=sesta.com, o=isp
Create the container for classes.objectclass: cosDefinition
cosTemplateDn: ou=MailSchemeTemplates,ou=COS,o=sesta.com, o=isp
cosTargetTree: ou=People,o=sesta.com, o=isp
- Multi-valued attribute that contains the subtree(s) under which the COS template entries for this scheme are stored.
cosSpecifier: inetCOS
cosAttribute: mailQuota
cosAttribute: mailAllowedServiceAccess
Create COS template entries.
- 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
- 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=All-Star,ou=MailSchemeClasses,ou=COS,o=sesta.com, o=isp
Add class of service templates to users.
dn: cn=Hall of Fame,ou=MailSchemeClasses,ou=COS,o=sesta.com, o=ispobjectclass: top
objectclass: inetUser
objectclass: inetMailUser
mailQuota: 5000000
mailAllowedServiceAccess: +pop3:*objectclass: top
objectclass: inetUser
objectclass: inetMailUser
mailQuota: 5000000
mailAllowedServiceAccess: +imap, imaps, pop3:*
Previous Contents Index Next
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.
Last Updated February 13, 2002