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.