| Sun Java System Communications Services 6 2004Q2 Schema Reference |
Chapter 1
OverviewThis chapter gives an overview of Sun Java™ System Communications Services schema. It contains the following sections:
Data Model for Sun Java™ System LDAP Schema 2The 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™ 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™ System Communications Services User Management Utility (a command line utility) 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 System Communications Services Enterprise Deployment Planning Guide.
For more information on RFC 2798, RFC 2252, and internet standards, use the following URL:
Table 1-1 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 Identity Server in these types of entries. Identity Server classes are shown in italicized font. Note that the object classes and attributes defined for Identity Server are subject to change. See the Sun Java™ Enterprise System Technical Overview for a discussion of provisioning concepts.
Table 1-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 Identity Server in these types of entries.
Data Model for Sun Java™ System LDAP Schema 1The 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:
Table 1-3 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.
Messaging Server Schema OverviewThe 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:
- Email Groups (Distribution Lists)
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
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 Identity Server 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™ System User Management Utility.
For the User Management Utility (commadmin), see the Sun Java™ System Communications Services User Management Utility 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 Identity Server, 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 OverviewThis section lists the Calendar Server object classes and their attributes.
Table 1-4 shows the calendar-specific object classes and their attributes. In addition, Calendar Server also uses one non-calendar object class, inetResource.
