Chapter 12
Provisioning and Schema Concepts for Messaging Server 6.0

This chapter describes your provisioning choices for Messaging Server 6.0, as well as topics that help you understand the concepts and technologies of Sun ONE LDAP Schema, v.2.

This chapter contains the following sections:

LDAP Directory Information Tree (DIT) and Messaging Server
Schema Choices for Messaging Server 6.0
Identifying the Proper Provisioning Tools
Schema v.2 Choices: Native or Compatibility Mode
Data Models for Native and Compatibility Modes
Declaring Namespaces
Search Templates
Groups (Mailing Lists)
Class of Service (CoS)

---

LDAP Directory Information Tree (DIT) and Messaging Server

The DIT is a way to organize LDAP entries in a tree structure with nodes representing domains, subdomains, users, and groups. Earlier versions of Messaging Server used a two-tree structure with a DC Tree containing domain nodes decorated with all the pertinent domain attributes, and an Organization Tree containing domain nodes decorated with all the user and group attributes. The top half of Figure 12-1 illustrates this type of DIT structure. Using this structure, it was possible for multiple DC Tree nodes to refer to the same Organization Tree domain node because of aliases defined in the DC Tree.

Messaging Server 6.0 introduces a one-tree structure, where there is no DC Tree. In addition, all domain information is held in domain nodes in the Organization Tree. The two-tree model is still supported, but has changed as is explained in "Schema v.2 Choices: Native or Compatibility Mode".

The bottom half of Figure 12-1 illustrates a one-tree LDAP structure. Aliasing is handled entirely differently in the new one-DIT structure. Note especially in the one-tree representation where the domain information is located.

Figure 12-1  Native Mode Compared with Compatibility Mode LDAP Structure

[D]

---

Schema Choices for Messaging Server 6.0

The three choices of schema for Messaging Server 6.0 are:

Sun ONE LDAP Schema, v.2 in Native Mode
Sun ONE LDAP Schema, v.2 in Compatibility Mode
Sun ONE LDAP Schema, v.1

Note	The Java Enterprise System installer does not provide a user selectable option for Sun ONE LDAP Schema v.1 or v.2 support. To use Messaging Server 6.0 with Sun ONE LDAP Schema, v.2 support, you must install Identity Server and Directory Server. Currently, the only way to get v.2 support into Directory Server is to install Identity Server.

Sun ONE LDAP Schema, v.2 in Native Mode

The default mode for new customer installations where there is no existing iPlanet™ Messaging Server installed is Sun ONE LDAP Schema, v.2. This assumes that Identity Server 6.1 is installed prior to installation of Messaging Server 6.0.

You can also choose this mode if you have an existing iPlanet Messaging Server installation, but it will require you to migrate your LDAP database to the one-tree design.

A command-line interface is provided for provisioning and administration. You can also do LDAP provisioning.

Sun ONE LDAP Schema, v.2 in Compatibility Mode

You can choose Sun ONE LDAP Schema v.2 in compatibility mode as an alternate, if you have an existing iPlanet Messaging Server installation. This mode does not require you to migrate to a one-tree design. You retain the two-tree design you already have. This also assumes that Identity Server 6.1 is installed prior to installation of the Messaging Server 6.0.

A command-line interface is provided for provisioning and administration. You can also do LDAP provisioning.

Sun ONE LDAP Schema, v.1

Sun ONE LDAP Schema v.1 is the default mode for new customer installations that do not have Identity Server installed. Sun ONE LDAP Schema v.1 requires you to install a two-tree LDAP design.

Customers with an existing iPlanet Messaging Server installation can choose to remain with Sun ONE LDAP Schema, v.1, and continue using the graphical user interface for provisioning and administration, or LDAP provisioning.

Note	This guide only describes LDAP provisioning for Sun ONE LDAP Schema, v.2.

---

Identifying the Proper Provisioning Tools

Once you have decided which schema model to adopt, the following section explains which provisioning tools and the appropriate documentation to use.

The section contains the following information:

Provisioning Matrix
Determining Your Schema Model
Which Provisioning Tool to Use
Where to Find More Information About Provisioning

Provisioning Matrix

Table 12-1 provides a matrix that summarizes your schema choices, what provisioning tools are available, and the appropriate documentation to use for each. The sections that follow the table explain these choices.

In this table, the first column asks if you had a previous version of Messaging Server installed (iPlanet Messaging Server 5.0, 5.1, or 5.2), and the second column asks if you have already installed Identity Server, or will install it before provisioning.

Table 12-1  Provisioning Matrix 

iPlanet Messaging Server (5.0, 5.1, 5.2) Installed?	Identity Server Installed?	Type of Schema Installed by Messaging Server 6.0	Provisioning Tools	See These Documents
No	No	Sun ONE LDAP Schema, v.1 (default)	Delegated Administrator	iPlanet Delegated Administrator for Messaging and Collaboration 1.2 Installation and Administration Guide (http://docs.sun.com/doc/816-6011-10)
			LDAP provisioning	iPlanet Messaging Server 5.2 Provisioning Guide (http://docs.sun.com/doc/816-6018-10)
No	Yes	Sun ONE LDAP Schema, v.2 in native mode (default)	User Management Utility (commadmin)	Sun ONE Messaging and Collaboration 1.0 User Management Utility Installation and Reference Guide (http://docs.sun.com/doc/817-4216-10)
			LDAP provisioning	Refer to this guide, Chapter 11, "Provisioning Organizations and Users"
Yes	No	Sun ONE LDAP Schema, v.1	Delegated Administrator	iPlanet Delegated Administrator for Messaging and Collaboration 1.2 Installation and Administration Guide (http://docs.sun.com/doc/816-6011-10)
			LDAP provisioning	iPlanet Messaging Server 5.2 Provisioning Guide (http://docs.sun.com/doc/816-6018-10)
Yes	Yes	Sun ONE LDAP Schema, v.2 in either native or compatibility mode (your choice)	User Management Utility (commadmin)	Sun ONE Messaging and Collaboration User Management Utility 1.0 Installation and Reference Guide (http://docs.sun.com/doc/817-4216-10)
			LDAP provisioning	Refer to this guide, Chapter 11, "Provisioning Organizations and Users"

Determining Your Schema Model

If you do not have a previous version of Messaging Server installed and you installed Identity Server first, your new installation of Messaging Server 6.0 will automatically install using Sun ONE LDAP Schema, v.2, native mode. If you have not installed Identity Server, then Messaging Server will default to Sun ONE LDAP Schema, v.1.

If you have a previous version of Messaging Server installed and you want to use the new Sun ONE LDAP Schema, v.2, you will need to decide which of the following to do:

Keep the two-tree LDAP structure (compatibility mode) and the old RFC 2247 lookup algorithm
Convert to the new native mode (one-tree) LDAP structure (which is recommended).

Depending on your choice, one of two default search templates will be used by the system for LDAP lookups:

The search template that supports native mode lookup
One that supports compatibility mode; that is, the same RFC 2247 compliant lookup algorithm used with Sun ONE LDAP Schema, v.l

Note	You cannot mix both schema types in a single LDAP directory.

For more information about the two Sun ONE LDAP Schema, v.2 modes, see "Schema v.2 Choices: Native or Compatibility Mode".

Which Provisioning Tool to Use

For Sun ONE LDAP Schema, v.2, you can use either the Sun ONE User Management Utility, (commadmin), or perform LDAP provisioning by writing LDIF records directly to LDAP.

For Sun ONE LDAP Schema, v.1, you can use either iPlanet™ Delegated Administrator, or do LDAP provisioning.

Where to Find More Information About Provisioning

Use this guide to do LDAP provisioning for Sun ONE LDAP Schema, v.2 (both native and compatibility modes). See Chapter 11, "Provisioning Organizations and Users" for more information. To do LDAP provisioning for the Sun ONE LDAP Schema, v.1, see the iPlanet Messaging Server 5.2 Provisioning Guide (http://docs.sun.com/doc/816-6011-10).

If you will use the User Management Utility provisioning tool (for Sun ONE LDAP Schema, v.2), see the Sun ONE Messaging and Collaboration User Management Utility 1.0 Installation and Reference Guide (http://docs.sun.com/doc/817-4216-10). If you will use the Delegated Administrator provisioning tool (for Sun ONE LDAP Schema, v.l), see the iPlanet Messaging Server 5.2 Provisioning Guide (http://docs.sun.com/doc/816-6011-10).

---

Schema v.2 Choices: Native or Compatibility Mode

You can structure LDAP with Sun ONE Schema, v.2 in two ways: native mode (the preferred way), which uses only the Organization Tree, or compatibility mode (for backwards compatibility with earlier versions of Sun ONE or iPlanet LDAP-based products), which uses both a Domain Component Tree (DC Tree) and an Organization Tree. Provisioning your LDAP differs depending on which of these models you choose.

Before deciding which Sun ONE Schema, v.2, modes you will use, consider the following topics:

Why Did the LDAP Structure Change?
Native Mode: Benefits and a Regression
Converting to Native Mode
Compatibility Mode: Two-Tree Structure Still Supported

Why Did the LDAP Structure Change?

Java Enterprise System introduces a fundamental change to how LDAP is structured by implementing a one-tree structure. The two main advantages to using the one-tree structure (native mode) are:

Integration with Identity Server and Portal Server.
The one-tree LDAP structure is significantly simpler than the two-tree structure.

The one-tree LDAP structure is significantly less complex than the two-tree structure. As illustrated in the following figure, in the two-tree structure, some nodes pointed directly to a node in the Organization Tree (using the attribute inetDomainBaseDN). Other nodes were aliased nodes, which instead of pointing directly to an Organization Tree node, pointed to another DC Tree node, using the attribute aliasedObjectName.

Figure 12-2  Two-tree Aliasing with aliasedDomainName and inetDomainBaseDN

In the previous figure, sesta.com in the DC Tree points to siroe.com in the DC Tree using aliasedObjectName, and siroe.com points to the like named node in the Organization Tree, using inetDomainBaseDN.

Furthermore, as shown in the following figure, there could be one or more nodes in the DC Tree using inetDomainBaseDN to point directly to the same node in the Organization Tree. In this case, a “tie-breaker” attribute, inetCanonicalDomainName, was necessary on one of the DC Tree nodes to designate which was the “real” domain name. That is, the domain where the mail actually resided and would be routed to.

Figure 12-3  Two-tree Aliases with inetCanonicalDomainName

By contrast, the new LDAP structure is considerably less complex: a one-tree structure contains only an Organization Tree, as shown in Figure 12-4.

In the one-tree structure, domain nodes in the Organization Tree contain all the domain attributes formerly found on the DC Tree. Each domain node is identified by the sunManagedOrganization object class and sunPreferredDomain attribute, which contains the DNS domain name. A domain node can also have one or more associatedDomain attributes, which list the alias names this domain is known by. And contrary to the two-tree structure, there are no duplicate nodes for the alias names.

Figure 12-4  One-tree Aliases with associatedDomain

Native Mode: Benefits and a Regression

For new deployments of Messaging Server, LDAP information is now organized using a single directory information tree (DIT) structure. Specifically, the Messaging Server single DIT is called an Organization Tree. It contains user, group, and domain entries, as well as search templates.

Benefits of a One-Tree DIT

A one-tree DIT structure is beneficial in how you partition 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 to operate securely.

In addition, for new deployments of Messaging Server 6.0, a one-tree structure maps better to existing single DIT LDAP applications.

Native Mode Regression

With a two-tree structure, it was possible to have two DC Tree domain nodes pointing to the same Organization Tree domain node. Each of the two DC Tree domains could have different routing attribute values. This allowed for different processing and routing of mail for the same Organization Tree domain, depending on which domain alias was specified. Since this type of aliasing is no longer possible in a one-tree structure, that feature is lost.

Aliasing is now done with the associatedDomain attribute, and is analogous to the way alias domains decorated with the aliasedObjectName attribute work in compatibility mode. That is, the alias domain did not carry domain routing attributes, but relied on the attributes decorating the aliased domain (whose dn was carried in the aliasedObjectName attribute), such that routing of messages for the alias domain was identical to the aliased domain.

Converting to Native Mode

If you have an existing Sun ONE Schema, v.1, two-tree LDAP structure, and want to convert it to native mode, the following is a general list of changes that must be made to the Organization Tree.

Add the sunISManagedOrganization, and sunManagedOrganization object classes and their appropriate attributes to all domain nodes.
Add the sunNameSpace object class to all appropriate domain nodes. (See "Declaring Namespaces".)
Copy all pertinent domain attributes from the DC Tree to the corresponding Organization Tree domain nodes.
“Condense” all aliases from the DC Tree into the associatedDomain attribute.
Add ACIs to Organization Tree nodes.
Identity Server adds global search templates to the root node (basedn). You might also want to provide private override templates to individual nodes.

For object class and attribute details, see the Sun ONE Messaging and Collaboration 6.0 Schema Reference Manual (http://docs.sun.com/doc/816-6710-10).

Note	The DC Tree becomes obsolete, but need not be removed from the LDAP database.

Compatibility Mode: Two-Tree Structure Still Supported

Messaging Server 6.0 still supports the two-tree structure for previous versions of Messaging Server if you need to retain that structure. You might need to retain a two-tree LDAP structure if you have other applications that depend on it.

If you retain the two-tree structure, Messaging Server uses an RFC 2247 compliant search template to look up user entries.

Migration from Sun ONE Schema, v1, to Sun ONE Schema, v.2 compatibility mode requires the following:

The inetDomainStatus attribute is copied from the DC Tree nodes to the corresponding Organization Tree nodes. (When both nodes contain inetDomainStatus, the status found in the Organization Tree node will take precedence over the one found in the DC Tree node.)
The two-tree default search template must have the rfc2247Flag attribute set so that all applications searching the LDAP will continue to use the DC Tree to access the correct nodes in the Organization Tree, as in past versions of Messaging Server.
All Organization Tree nodes must have the appropriate Identity Server marker object classes and attributes.
The appropriate ACIs for Identity Server must be added to each node.
Global search templates for domains, users, and groups are provided on the root node by Identity Server. However, you might need to customize searches for certain nodes. To customize, you must add override templates on the nodes in question.

---

Data Models for Native and Compatibility Modes

The basic data model of Sun ONE 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 tables that follow. For native mode LDAPs with only an organization tree, see the following table. For compatibility LDAPs with a DC Tree and an organization tree, see Table 12-3.

Table 12-2  Native Mode Entry types and Corresponding Object Classes  

Types	Core Classes	Shared Classes	Server Specific Classes
Domain	organization domain sunManagedOrganization sunNameSpace		mailDomain icsCalendarDomain
User	person inetUser organizationalPerson inetOrgPerson	ipUser userPresenceProfile iplanet-am-managed- person	inetMailUser inetLocalMailRecipient
Group	groupOfUniqueNames iplanet-am-managed-group	iplanet-am-managed- filtered-group iplanet-am-managed- assignable-group iplanet-am-managed- static-group	inetMailGroup inetLocalRecipient inetMailGroupManagement

Table 12-3  Compatibility Mode Entry types and Corresponding Object Classes  

Types	Core Classes	Shared Classes	Server Specific Classes
DC Tree Domain	domain inetDomain		mailDomain icsCalendarDomain
Org Tree Domain	organization
User	person inetUser organizationalPerson inetOrgPerson	ipUser userPresenceProfile	inetMailUser inetLocalMailRecipient
Group	groupOfUniqueNames		inetMailGroup inetLocalRecipient inetMailGroupManagement

Using the User entry 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 by specifying the recipient’s email addresses, and by providing routing information pertinent to the recipient.

Note	Note that Identity Server marker classes usually start with iplanet-am-, or sun. Some of the Identity Server object classes and attributes are not used by Messaging Server itself, but it is still necessary to include them in your domain, groups, and user entries so that Identity Server can function.

---

Declaring Namespaces

Namespaces define organization entities wherein one or more attributes must be unique across all entries.

To provision an organization (usually a domain) to be a namespace, add the sunNameSpace object class to the organization’s entry. This marks it as a unique namespace, but does not enable the “uniqueness” feature. That is, the sunNameSpace object class by itself does not alter the behavior of the system.

To enable the uniqueness feature, you must add the attribute sunNameSpaceUniqueAttrs to the organization’s entry. The attribute contains the name of an attribute that is used to distinguish unique entries in this organization. Multiple attributes can be used for uniqueness.

Adding the uniqueness feature to a domain means that no subtree under the domain can be declared a namespace using the same attributes.

Uniqueness is enforced by the command-line utility provisioning tool, commadmin, which will not allow you to add a duplicate entry that violates the uniqueness feature. However, when you are provisioning directly with LDAP, you must enforce uniqueness yourself. The LDAP command, ldapmodify, does not enforce uniqueness. It will allow you to enter duplicate records.

Attribute uniqueness is an Identity Server feature used by Messaging Server. In order for your LDAP database to be managed by Identity Server, you must provision it such that the uniqueness constraints imposed by sunNameSpace and sunNameSpaceUniqueAttrs are honored.

Note	In earlier versions of Messaging Server, all domains were implicitly assumed to be separate namespaces and did not have to be explicitly declared. This has changed for Messaging Server 6.0, as explained in this section.

The following figure shows an example of domains as namespaces.

Figure 12-5  Domains as Namespaces

In the previous figure, there are three domains, each decorated with the sunNameSpace object class and a sunNameSpaceUniqueAttrs attribute set to uid. Each domain is a namespace in which no two entries may have the same uid. This also enables multiple domains to have entries with the same unique identifier, without violating the uniqueness constraints of the separate domains. For example, the three domains each have an entry with a uid of jdoe.This is permissible because each organization is a separate namespace. To find a particular jdoe in this example, the search template needs to know the name of the organization (domain).

Additional different attributes can be assigned to each domain. For example, one domain’s users might each have a unique telephoneNumber. So for that domain, the entry would be additionally decorated with sunNameSpaceUniqueAttrs=telephoneNumber, and no two users could have the same telephone number.

Overlapping Namespaces and the Root Node

While it is possible to do overlapping namespaces with Sun ONE LDAP Schema v.2, do not make the root node a namespace.

If you plan to have more than one domain in your installation, do not put the sunNameSpaceUniqueAttrs attribute on the root-suffix node (basedn in our example) because any and all domains under the root would then be prohibited from using the attributes named in the root entry for uniqueness enforcement.

For example, if you have sunNameSpaceUniqueAttrs=uid on the root node, none of your other domains can use the uid to enforce uniqueness in their domain.

Identity Server automatically provisions the root node with sunNameSpace, but does not add the attribute. Because the uniqueness feature is not enabled without the presence of sunNameSpaceUniqueAttrs, the root node does not function as a namespace unless you specifically add the attribute.

Note	For Messaging Server purposes, do not add sunNameSpaceUniqueAttrs to the root node.

---

Search Templates

This section explains what search templates do and how they are formatted.

Note	The format for search templates is subject to change. You should manage search templates through Identity Server.

Overview of Search Templates

Templates are specialized entries in the Organization Tree. They are used by Messaging Server to locate LDAP entries for domains, users, and groups, as follows:

In native mode, Messaging Server uses the BasicOrganizationSearch template and performs the specified search, using the search filter found in the template.
In compatibility mode, using the BasicDomainSearch template, Messaging Server looks at the setting of the rfc2247Flag. If the flag is set to true, then it ignores the search filter and uses the DC Tree to find the appropriate Organization Tree node, as in earlier versions of Messaging Server.

There are two kinds of search templates:

Global Search Templates- Search templates that are used for the entire Organization Tree are called global search templates, which are stored in the DIT at:

ou=templates,ou=default,ou=GlobalConfig,ou=1.0,ou=DAI,  ou=services,basedn

where basedn is the root of the organization tree for this installation.

Private Search Templates- Each organization can have templates private to operations within that organization. These private templates are stored in the DIT below the individual organizations in:

ou=default,ou=OrganizationConfig,ou=1.0,ou=DAI,ou=services,orgdn

where orgdn is the location of the organization.

The organization’s top entry must have one or both of the following attributes present to indicate that templates are changed for that organization: sunAdditionalTemplates, sunOverrideTemplates.

For more information on object classes and attributes, see the Sun ONE Messaging and Collaboration 6.0 Schema Reference Manual (http://docs.sun.com/doc/816-6710-10).

Search Template Format

Search templates have the following elements:

name

The name of the template.

searchfilter

A search filter to locate entries of this kind.

attrs

A list of types of attributes to retrieve from located entries.

rfc2247Flag

A boolean (true, false) that tells applications to use the RFC 2247 algorithm for constructing DN of the LDAP entry to look for instead of using the specified search filter. (This is for backwards compatibility with installations with existing compatibility mode LDAP structures, such as installations of iPlanet Messaging Server 5.2.) This element forces the system to search the DC Tree to find a matching inetDomainBaseDN attribute, which points to the correct organization node in the Organization Tree. For more information on DC Trees, see the iPlanet Messaging Server 5.2 Provisioning Guide (http://docs.sun.com/doc/816-6011-10).

BaseDN

If rfc2247Flag is set to true, then the value of this attribute, if present, must be appended to the algorithmically constructed DN in order to get the DN of the target entry.

---

Groups (Mailing Lists)

Groups, known as mailing lists in Messaging Server, allow users of services to reach a group of other users without having to name them individually. For Messaging Server, this means sending email to multiple mailboxes without having to specify each email address separately. Messaging Server supports both static and dynamic mailing lists (groups). Each type of list has an LDAP entry supported by the object class inetMailGroup.

In static mailing lists, members of the list are specified directly in the group LDAP entry. For dynamic mailing lists, members are specified using an LDAP search filter (RFC-2254).

Within dynamic groups a further division can be made: a dynamic group is either assignable or filtered. Furthermore each of the types of groups can be either open (subscribable), or closed (nonsubscribable). An exception is the the filtered dynamic group which cannot be open.

It can be useful to visualize the various combinations as shown in the table that follows:

Open/Closed	Static	Assignable Dynamic	Filtered Dynamic
Open (Subscribable)	Yes	Yes	No
Closed (Nonsubscribable)	Yes	Yes	Yes

Types of Groups

There are three types of groups:

Static. A static group has an LDAP entry that lists all members, using the uniqueMember attribute for internal members and the mgrpRFC822MailMember attribute for external members.
Assignable dynamic. An assignable dynamic group’s LDAP entry contains a search filter set in the mgrpDeliverTo attribute. The filtered attribute must be a well-known attribute. The default well-known attribute for Messaging Server is memberOf, an attribute now supported by Identity Server, using the inetAdmin object class.

For example, for the dynamic group called HRStaff, the mgrpDeliverTo attribute would have the following value:

(&(objectclass=inetAdmin) (memberOf=cn=HRStaff, ou=Groups, o=sesta.com, o=basedn ))

In addition, each member’s user entry would contain the following lines:

objectClass: inetAdmin

memberOf: HRStaff

Filtered dynamic. Like assignable dynamic groups, filtered dynamic group’s LDAP entry contains a search filter set with the mgrpDeliverTo attribute. However, in this case, group members can be determined by filtering on any attributes (one or more). For example, a filter could look like:

(&((objectclass=inetMailUser)(city=tokyo)&(objetclass=inetOrgPerson)(uid=jdoe)))

In addition, static groups can also have dynamic members by adding the mgrpDeliverTo attribute to the static group’s LDAP entry.

Note	Make sure that the attributes used in the LDAP search filter are indexed. Otherwise, the process of evaluating dynamic membership lists will be time consuming and will stress the directory server.

Each type of group has its own Identity Server object class. The following table lists each group type, and the Identity Server object class used in provisioning each:

Type of Group	Identity Server Object Class
Static	iplanet-am-manged-static-group
Assignable Dynamic	iplanet-am-managed-assignable-group
Filtered Dynamic	iplanet-am-managed-filtered-group

Note	The iplanet-am-managed-group object class is the superior class for all three of these classes, but its use in a group’s LDAP entry is optional.

Open and Closed Groups

Open groups are groups that are free for any user to subscribe to. If the attribute iplanet-am-group-subscribable is present in the group’s LDAP entry with a value of true, the group is open (subscribable).This is an optional attribute. Groups are presumed closed (not subscribable) if the attribute is missing. The attribute can also have the value of false, meaning the group is closed (not subscribable).

---

Class of Service (CoS)

The CoS advanced entry management mechanism enables you to create virtual attributes not stored in the entries. Instead, they are generated by the CoS mechanism as the entry is sent to the client application. As with groups and roles, CoS relies on helper entries in your directory.

The three available mechanism’s are:

Pointer CoS
Indirect CoS
Classic CoS

The Classic CoS is the recommended mechanism for provisioning Messaging Server CoS and is described in this section.

You can read more about these advanced entry management mechanisms in the Sun ONE Directory Server 5.2 Administration Guide and the Sun ONE Directory Server 5.2 Reference Manual. You can find these documents at Sun’s documentation web site:

http://docs.sun.com/prod/s1dirsrv

CoS for Messaging Server

The CoS feature allows you to create a named set of fixed features and attributes that can be applied to specified users. The CoS feature enables you to create a template of attributes that can be conferred upon user entries with a single attribute. For example, if you are an internet service provider, you could create two levels of mail service called MS1 and MS2, as follows:

The MS1 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 MS2 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. This limitation and others are listed in the Sun ONE Directory Server 5.2 Administration Guide (http://docs.sun.com/doc/816-6698-10), as referenced earlier.

Setting Up CoS in Messaging Server

The high-level overview for adding the class of service feature involves the following operations:

Enabling the Class of Service plug-in

The Class of Service plug-in is automatically installed with Directory Server. To activate the plug-in, thus enabling CoS, the SLAPD configuration file must be modified.

For information on how to configure the Class of Service plug-in, see the Sun ONE Directory Server 5.2 Administration Guide (http://docs.sun.com/doc/816-6698-10).

Restarting Directory Server
Creating the CoS container for CoS templates and definitions
Creating a CoS mail scheme under the CoS container

Each mail scheme entry contains the following:

CoS mail scheme entry DN (with ou:CoS).
Object class that defines the class of service scheme entry (objectClass:cosClassicDefinition).
Multi-valued attribute that contains the subtrees (names of directories) under which the CoS template entries for this scheme are stored (cosTemplateDN).
Multi-valued attribute that contains the subtree to which the CoS scheme applies (cosTargetTree).
Name of the attribute used to specify the CoS template applied to a user entry (cosSpecifier:inetCOS).
Attributes to be used in a template entry (multi-valued cosAttribute).
Creating a container for the CoS templates
Creating the CoS templates
Assigning a class of service to user entries

    To Create a CoS—Example

This example assumes the CoS plug-in is already installed and configured, and Directory Server is running. The example illustrates how to create mail service for two classes of service, MS1 and MS2, in the hosted domain sesta.com. The two classes of service have the following purposes:

The MS1 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 MS2 class of service could provide POP3 mail services along with 5 megabytes of message store disk space.
Create the container for CoS schemes and templates.

This entry defines the container as an organizationalUnit (ou).

The following code example shows the LDIF entry for creating the CoS container:

dn: ou=CoS,o=sesta.com, o=basedn changetype: modify add:organizationalUnit ou: CoS

Create a CoS mail scheme using the example LDIF entry that follows:

dn: uid=mailscheme,ou=CoS,o=sesta.com, o=basedn objectClass: top objectClass: ldapsubentry objectClass: cossuperdefinition objectClass: cosdefinition objectClass: cosClassicDefinition cosTemplateDn: ou=MailSchemeClasses,ou=CoS,o=sesta.com, o=basedn cosSpecifier: inetCoS cosAttribute: mailQuota cosAttribute: mailAllowedServiceAccess

Create the container for the mail scheme templates.

Use the following LDIF example statement to create the container:

dn: ou=MailSchemeClasses,ou=CoS,o=sesta.com, o=basedn changetype: modify add: organizationalunit ou: MailSchemeClasses

Create CoS templates.

Use the following LDIF example to create the two template entries for the MS1 and MS2 templates.

dn: cn=MS2,ou=MailSchemeClasses,ou=CoS,o=sesta.com, o=basedn objectClass: top objectClass: costemplate objectClass: extensibleobject objectClass: ldapsubentry mailQuota: 5000000 mailAllowedServiceAccess: +pop3:*

dn: cn=MS1,ou=MailSchemeClasses,ou=CoS,o=sesta.com, o=basedn objectClass: top objectClass: costemplate objectClass: extensibleobject objectClass: ldapsubentry mailQuota: 5000000000 mailAllowedServiceAccess: +imap, imaps, pop3, http:*

Add a class of service to a user entry.

Previous      Contents      Index      Next

---

Copyright 2003 Sun Microsystems, Inc. All rights reserved.