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).