Chapter 1   Overview


This chapter give an overview of Sun™ ONE/iPlanet™ schema. It contains the following sections:

• Basic Data Model

• iPlanet Messaging Server Schema Overview

• Sun ONE Calendar Server Schema Overview

Basic Data Model

---

The basic data model of the 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). Table 1-1. depicts these relationships.

Table 1-1    Entry Types and Corresponding Object Classes

Types	Core Classes	Shared Classes	Messaging Server Classes	Calendar Server Classes
DC Tree Domain	domain, inetDomain	N/A	mailDomain, nsManagedDomain	N/A
Org Tree Domain	organization	N/A	nsManagedDomain	N/A
User	person, inetUser, organizational Person, inetOrg Person	ipUser, userPresence Profile	inetMailUser, inetLocalMailRecipient, nsManagedPerson	icsCalendarUser, icsCalendarDWPHost
Group	groupOfUnique Names	N/A	inetMailGroup, inetLocalRecipient, inetMailGroupManagement, nsManagedMailList	N/A
Family Account	inetManagedGroup	N/A	nsManagedDept	N/A
Resource	inetResource	N/A	N/A	icsCalendarResource, icsCalendarDWPHost

For more information on RFC 2798, RFC 2252, and internet standards, use the following URL:

http://www.imc.org/rfcs.html

iPlanet Messaging Server Schema Overview

---

The basic iPlanet Messaging Server schema model is to extend LDAP entries created by structural object classes. Extensions are made to a base LDAP entry using auxiliary object classes. The extensions made for iPlanet Messaging Server are defined in this Schema Reference.

For example, inetOrgPerson is the structural class used to make a base user entry. This user entry becomes an email user when overlaid by the auxiliary classes defined in this document. Similarly, groupOfUniqueNames is the structural class used to make a base group entry, which becomes an email distribution list when overlaid by the distribution list auxiliary object classes.

iPlanet Messaging Server auxiliary object classes can be grouped by function into the following categories and subcategories:

• Mail Recipient
  • Email Users

  • Email Groups (Distribution Lists)

  • Email Routing

• Personal Address Book
  • Personal Address Book

  • Personal Address Book Group

  • Personal Address Book Person

• Hosted Domain and Domain Organization
  • Hosted Domain

  • Domain Alias

  • Mail Domain

  • Domain Organization

• Delegation of Management
  • Managed Group

  • Store Administrator

Mail Recipient

There are two types of mail recipients: users and groups. Both user and group email use the inetLocalMailRecipient auxiliary object class for local mail routing attributes.

Email Users

LDAP entries created by inetOrgPerson can be enabled for messaging services by overlaying the entry with inetUser, ipUser, inetMailUser, inetLocalMailRecipient, and userPresenceProfile. Optionally, inetSubscriber may be used for holding subscriber type attributes for the user, but it is not required for creating messaging server users.

Email Groups

LDAP entries created by groupOfUniqueNames can be enabled for messaging services by overlaying the entry with inetMailGroup, inetMailGroupManagement, and inetLocalMailRecipient. These object classes define distribution lists and how they are to be used by the messaging server.

Email Routing

For email routing attributes, the messaging server uses the object class inetLocalMailRecipient.

Personal Address Book

LDAP entries created by inetOrgPerson can be enabled for personal address books by overlaying the entry with object classes pab, pabGroup, and pabPerson. The data model for personal address book entries is the address book (pab), which contains zero or more persons (pabPerson) and zero or more group (pabGroup) entries.

Personal Address Book

The personal address book (pab object class) contains zero or more pabPerson and zero or more pabGroup entries. All users and groups belong to the default personal address book called All.

Personal Address Book Group

The personal address book group object class, pabGroup, corresponds to a personal distribution list. A group belongs to zero or more personal address books. The link between groups and personal address books is established by memberOfPAB, a multi-valued attribute of pabGroup.

Personal Address Book Person

The personal address book user object class, pabPerson, is a user entry in a personal address book. A user (pabPerson) can belong to zero or more personal address book groups (pabGroup) and zero or more personal address books (pab).

The link between users and groups is established by memberOfPABGroup, a multi-valued attribute of pabPerson, which allows the user to belong to many groups. A user can also belong to many personal address books. This link is established by memberOfPAB, a multi-valued attribute of pabPerson.

Hosted Domain and Domain Organization

LDAP entries created by domain can be enabled for messaging services by overlaying the entry with inetDomain, inetDomainAlias, inetDomainOrg, and mailDomain. Optionally, to hold attributes suitable for overriding the default behavior of mailDomain and for stored certmaps, inetDomainAuthInfo can be used.

Hosted Domain

The base entry created by domain is extended by overlaying inetDomain, mailDomain, and optionally inetDomainAuthInfo to create a hosted domain node suitable for mail services for the hosted organization. There must be an instance of inetDomain for each hosted domain.

Domain Alias

LDAP entries may be created in the domain component tree that point at other hosted domain objects. There must be an instance of inetDomainAlias for each alias entry. The hosted domain is linked to the aliased domain by the attribute aliasedObjectName.

Mail Domain

LDAP entries created by domain and inetDomain can be enabled for the hosted domain using the object class mailDomain.There must be an instance of mailDomain for each hosted domain.

If more than one hosted domain refers to the same organization subtree, an instance of inetDomainAuthInfo must exist to contain search filter, domain certmap and canonical domain name information for each hosted domain.

Domain Organization

To support a managed domain organization, the auxiliary object class inetDomainOrg is used in conjunction with the structural class organization. A domain organization is usually created as a way of introducing hierarchy beneath a customer subtree and assigning administrators for that domain organization.

Delegation of Management

Managed group object classes are used to specify arbitrary groupings of users or groups (and possibly other resources defined in the LDAP directory) so that management of these resources can be delegated to another user. Examples of such groupings are DNS domain boundaries, departments, and family members.

Managed Group

Managed groups commonly have different rules for adding or deleting members. To enable policy differences in the administration of groups, an instance of the object class inetManagedGroup, with its associated policy attributes, must exist for each managed group.

Store Administrator

To define a group of administrators for domains, the object class inetMailAdministrator is used to grant members of the group administrative privileges over users in the same domain where the group is defined.

Sun ONE Calendar Server Schema Overview

---

This section lists the Sun ONE Calendar Server object classes and their attributes, and discusses the Directory Information Tree (DIT) layout.

Calendar Object Classes and Their Attributes

Table 1-2 shows the calendar-specific object classes and their attributes. In addition, Sun ONE Calendar Server also uses one non-calendar object class, inetResource.

Table 1-2    Calendar-Specific Object Classes 

Object Classes	Required Attributes	Allowed Attributes
icsAdministrator (not currently used)	N/A	icsAdminRole, icsExtended, icsExtendedGroupPrefs
icsCalendarDomain (not currently used)	N/A
icsCalendarDWPHost (not currently implemented)	N/A	cn,description, icsDomainNames, icsDWPHost, icsExtended, icsRegularExpressions, icsStatus
icsCalendarGroup	icsStatus	N/A
icsCalendarResource (not all attributes are currently used)	N/A	cn, icsAlias, icsCalendar, icsCapacity, icsContact, icsDoubleBook, icsDWPHost, icsExtended, icsExtendedResourcePrefs, icsGeo, icsPartition, icsPreferredHost, icsQuota, icsStatus, icsTimezone, uid
icsCalendarUser	N/A	cn, givenName, icsAllowedServiceAcess, icsCalendar, icsCalendarOwned, icsDefaultSet, icsDoubleBook, icsDWPHost, icsExtended, icsExtendedUserPrefs, icsFirstDay, icsFreeBusy, icsGeo, icsPartition, icsPreferredHost, icsQuota, icsSet, icsStatus, icsSubscribed, icsTimezone, mail, nswcalDisallowAccess, preferredLanguage, sn, uid, userPassword Note: icsPartition is not currently implemented.

Directory Information Tree (DIT) Layout

Whether DWP servers are per domain resources, cross-domain resources, or a combination, the following DIT describes what Calendar Server schema looks like. DWP server entries can reside anywhere in LDAP because each entry contains a domain name. Figure 1-1 shows a sample Directory Information Tree (DIT) Layout for Sun ONE Calendar Server.

Figure 1-1    Directory Information Tree Layout

*The DN of ou=DWPHostTable will be stored in ics.conf. ou=DWPHostTable is optional.