Chapter 1 Overview

This chapter gives an overview of Sun Java^TMCommunications Suite schema. It contains the following sections:

• Data Model for Sun Java System LDAP Schema 2

• Data Model for Sun Java System LDAP Schema 1

• Messaging Server Schema Overview

• Calendar Server Schema Overview

Data Model for Sun Java System LDAP Schema 2

The basic data model of Sun Java System 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).

In addition, there are two ways to structure the LDAP data model: native mode (the preferred way) using only an Organization Tree, and compatibility mode (for backwards compatibility with earlier versions of Sun Java System or iPlanet^TM LDAP based products) using both a DC Tree and an Organization Tree. The LDAP data model for compatibility mode is essentially the same as data model for the Sun Java System LDAP Schema 1. Provisioning your LDAP differs depending on whether you chose the native or compatibility mode at installation time.

Use the Sun Java Communications Suite Delegated Administrator (a command-line utility and a console) to add, modify and delete users, groups and domains.

For a discussion of the differences in LDAP data models between the native and compatibility modes (and LDAP Schema 1), see “LDAP Directory Information Tree Requirements” in Chapter 3, “Understanding Product Requirements and Considerations,” in the Sun Java Communications Suite Enterprise Deployment Planning Guide.

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

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

Data Model for Sun Java System LDAP Schema 2 shows the core classes, shared classes and server specific classes for the three types of entries for native mode: domains, users and groups. Note that for Calendar Server, there is an additional type of entry for resources that need to be scheduled, such as conference rooms and equipment.

Note that while userPresenceProfile is not specifically a Messaging Server object class (it is used to store vacation start and end dates), Calendar Server does not use it at all.

This table also includes the classes used by Access Manager in these types of entries. Access Manager classes are shown in italicized font. Note that the object classes and attributes defined for Access Manager are subject to change. See the Sun Java Enterprise System Technical Overview for a discussion of provisioning concepts.

Table 1–1 Native Mode Entry types and Corresponding Object Classes

Types	Core Classes	Shared Classes	Server Specific Classes
Domain	organization domain sunManagedOrganization sunNameSpace	none	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
Resource	inetResource	none	icsCalendarResource

Data Model for Sun Java System LDAP Schema 2 shows the core classes, shared classes and server specific classes for the four types of entries for compatibility mode: DC Tree domains, Organization Tree domains, users and groups.

Note that for Calendar Server, there is an additional type of entry for resources that need to be scheduled, such as conference rooms and equipment. Also note that userPresenceProfile is used only by Messaging Server, even though it is not a messaging specific object class.

This table also includes the classes used by Access Manager in these types of entries.

Table 1–2 Compatibility Mode Entry types and Corresponding Object Classes

Types	Core Classes	Shared Classes	Server Specific Classes
DC Tree Domain	domain inetDomain	none	mailDomain icsCalendarDomain
Org Tree Domain	organization sunManagedOrganization sunNameSpace	none
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
Resource	inetResource		icsCalendarResource

Data Model for Sun Java System LDAP Schema 1

The basic data model of Sun Java System 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 model has an Organization Tree for holding user and group information and a Domain Component Tree (DC Tree) that holds the domain information.

This model is administered by the iPlanet Delegated Administrator for Messaging graphical user interface.

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

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

Data Model for Sun Java System LDAP Schema 1 shows the core classes, shared classes and server specific classes for the four types of entries: DC Tree domains, Organization Tree domains, users and groups. Note that for Calendar Server, there is an additional type of entry for resources that need to be scheduled, such as conference rooms and equipment. This table also includes the marker classes used by Delegated Administrator.

Table 1–3 Two-DIT Entry types and Corresponding Object Classes

Types	Core Classes	Shared Classes	Server Specific Classes
DC Tree Domain	domain inetDomain	none	mailDomain nsManagedDomain icsCalendarDomain
Org Tree Domain	organization	none	nsManagedDomain
User	person inetUser organizationalPerson inetOrgPerson	ipUser userPresenceProfile	inetMailUser inetLocalMailRecipient nsManagedPerson
Group	groupOfUniqueNames	none	inetMailGroup inetLocalRecipient inetMailGroupManagement nsManagedMailingList
Family Account	inetManagedGroup	none	nsManagedDept
Resource	inetResource	none	icsCalendarResource

Messaging Server Schema Overview

The basic 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 Messaging Server are defined in this manual.

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.

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

  Domains

  • Hosted Domain Entries

  • Domain Aliases

  • Domain Organizations

  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, inetMailUser, 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.

Domains

Domain object classes are used to specify email-addressable organizations. These domains are known as hosted domains.

This section discusses the following:

• Hosted Domain Entries

• Domain Aliases

• Domain Organizations

Hosted Domain Entries

LDAP entries created by domain and inetDomain can be enabled for hosted domains using the object class mailDomain. There must be an instance of both mailDomain, and inetDomain for each hosted domain. Optionally, to hold attributes suitable for overriding the default behavior of mailDomain and for stored certmaps, inetDomainAuthInfo can be used.

For LDAP Schema 2, each hosted domain entry must also carry the Access Manager marker class, sunManagedOrganization and its attribute, sunPreferredDomain. This is true in both native and compatibility modes. In addition, if the hosted domain is also to be a namespace, the domain entry must contain the sunNameSpace object class and sunNameSpaceUniqueAttrs attribute.

For LDAP Schema 1, each hosted domain entry must carry the Delegated Administrator marker class nsManagedDomain.

Domain Aliases

A hosted domain can have aliases. In LDAP Schema 1, and LDAP Schema 2 compatibility mode, these aliases are separate nodes on the DC Tree, and depending on what type of aliasing is being one, can carry separate routing information. However, for LDAP Schema 2 native mode, there is no DC Tree. All aliasing is handled by adding the associatedDomain attribute (which lists all the alias names) to the domain node. This means a loss of functionality for native mode. That is for native mode, there can not be separate domain information (and thus different mail routing) for alias domains.

For LDAP Schema 2, compatibility mode, the DC Tree domain alias nodes are still present, and can be provisioned using the Sun Java Communications Suite Delegated Administrator.

For Delegated Administrator, see the Sun Java System Delegated Administrator 6.4 Administration Guide.

Domain Organizations

To support a managed domain organization in LDAP Schema 1, the auxiliary object classes 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. The resulting structures are not domains. They are usually denoted with the attribute organizationalUnit (ou).

LDAP Schema 2 does not support “domain organizations” as used by earlier versions of Messaging Server. Especially do not use iplanet-am-managed-organizational-unit, which despite its name, is treated exactly the same as a regular domain named by sunManagedOrganization. Since this organization is not a domain, and there is no marker class for this in Access Manager, if you want to use the “domain organization” concept in your LDAP Schema 2 directory, you must provision and manage these structures by directly writing LDAP entries (using ldapmodify).

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, and departments.

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 inetOrgPerson, 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 administrative privileges over users in the same domain where the group is defined.

Calendar Server Schema Overview

This section lists the Calendar Server object classes and their attributes.

Calendar Server Schema Overview shows the calendar-specific object classes and their attributes. In addition, Calendar Server also uses one non-calendar object class, inetResource.

Table 1–4 Calendar-Specific Object Classes

Object Classes	Required Attributes	Allowed Attributes
icsAdministrator (not currently used)	none	icsAdminRole, icsExtended, icsExtendedGroupPrefs
icsCalendarDomain (not all attributes are currently used)	none	[icsAllowedServiceAccess, icsAllowRights, icsAnonymousAllowWrite, icsAnonymousCalendar, icsAnonymousDefaultSet, icsAnonymousLogin, icsAnonymousSet, icsDefaultAccess, icsDomainAllowed, icsDomainNames, icsDomainNotAllowed, icsDWPBackEndHosts, icsExtended, icsExtendedDomainPrefs, icsMandatorySubscribed, icsMandatoryView, icsPreferredHost, icsQuota, icsRecurrenceBound, icsRecurrenceDate, icsSessionTimeout, icsSourceHtml, icsStatus, icsTimezone
icsCalendarDWPHost (not currently implemented)	none	cn,description, icsDomainNames, icsDWPHost, icsExtended, icsRegularExpressions, icsStatus
icsCalendarGroup	groupid icsStatus	icsCalendar, icsDefaultacl, icsDWPHost, icsSecondaryowners, icsStatus, icsTimezone, mail
icsCalendarResource (not all attributes are currently used)	none	cn, icsAlias, icsCalendar, icsCapacity, icsContact, icsDefaultacl, icsDWPHost, icsExtended, icsExtendedResourcePrefs, icsGeo, icsPartition, icsPreferredHost, icsQuota, icsSecondaryowners, icsStatus, icsTimezone, mailAlternateAddress, mail, owner, uid
icsCalendarUser (not all attributes are currently used)	none	cn, givenName, icsAllowedServiceAccess, icsCalendar, icsCalendarOwned, icsDefaultSet, icsDWPHost , icsExtended, icsExtendedUserPrefs, icsFirstDay, icsFreeBusy, icsGeo, icsPartition, icsPreferredHost, icsQuota, icsSet, icsStatus, icsSubscribed, icsTimezone, mail, mailAlternateAddress, nswcalDisallowAccess, preferredLanguage, sn, uid, userPassword