SunTM Internet Mail ServerTM 4.0 supports both the Netscape Directory Services (NSDS) 4.1 as well as Sun Directory Services (SunDS) 3.1. NSDS, however, is the preferred directory server that you could use with SIMS 4.0 in the SPARC/Solaris operating environment.

The directory service that SIMS support is based on the Lightweight Directory Access Protocol (LDAP).

Topics in this chapter include:

What is the Directory Service?

The Directory Information Tree (DIT)

The LDAP directory

Password management

Sun directory services replication

What is the Directory Service?

The Directory service is a central repository for meta-information, where user profiles, distribution lists, and other system resources information reside.

Although SIMS 4.0 uses LDAP Version 3 (v3)., LDAP v2 and v3 may be used interchangeably during upgrade from SIMS 3.x to SIMS 4.0.

LDAP referrals are a supported feature of LDAP v3. They refer to an LDAP entry that contains a symbolic link (referral) to another LDAP entry. An LDAP referral consists of a machine and a distinguished name. LDAP referrals are often used to reference existing LDAP data so that this data does not have to be replicated. It is also used to maintain compatibility for programs that depend on a particular entry that may have been moved.

To utilize the LDAP referrals, SIMS must first bind using LDAP v3 and then configure the LDAP API to follow referrals transparently if they are encountered during an LDAP operation.

Another LDAP feature supported in SIMS is LDAP server failover, which is basically a backup mechanism for LDAP servers; that is, if one LDAP server fails, the system can switch over to another LDAP server.

SIMS 4.0 supports the following directory services architecture:

Distributed architecture--This makes the directory particularly robust. Even if one server goes down, the other servers can provide access to the directory information.

Logical unique database structure--This allows users and applications to access the same directory information from anywhere on the network. This feature allows decreasing the system administration load. The information only needs to be added, edited, or deleted once, at one point in the network. Millions of entries can be stored.

How Do SIMS Components Use the Directory Services?

SIMS uses the Directory Services to store information commonly used by SIMS Internet Message Transfer (IMTA) and message store and Message Access (MSMA) components.

The IMTA uses the directory to store and retrieve user and distribution routing information as well as user and distribution list profiles.

The MSMA uses the directory to verify the credentials of users and to store user message store configuration information.

The Directory Information Tree (DIT)

In SIMS 3.5, the Directory Information Tree (DIT) supported two types of trees: the Organization tree (OSI tree) and the Domain Component (DC) tree. If SIMS 3.5 were installed at the SP bridge.net, the root of these trees was mapped as o=bridge,c=us for the OSI tree, and as dc=bridge,dc=net, and o=internet for the DC tree.

FIGURE  8-1 OSI and DC Tree Representations in SIMS 3.5

FIGURE  8-2 The DC Tree Representation in SIMS 4.0

Directory Entries

Directory information is stored as directory entries. A directory entry is a set of attributes and their values. For example, SIMS specifies an attribute called commonname, its value would be the user's full name.

Directory entries are defined by an object class which specifies the kind of object the entry describes and the set of attributes it contains. For example, SIMS specifies an inetMailUser object class which has attributes such as commonname, mailHost, and mailQuota. SIMS also specifies an inetMailGroup object class which has attributes such as commonname, authorizedSubmitter, and rfc822mail, and UniqueMemeber.

The set of object classes supported by a directory service is called the directory schema. The schema specifies all the objects and attributes supported by the directory service, as well as which attributes are mandatory and optional for a given object class.

Directory entries are organized hierarchically in a tree-like structure called the Directory Information Tree or DIT. Each entry has a parent entry and can have child entries. The top of the hierarchy is known as the root entry.

An entry is identified by its distinguished name (DN). A distinguished name is a sequence of locale-related attributes and values. The first attribute and its value provide the entry's relative distinguished name (RDN). The rest of the sequence is the distinguished name of the parent entry. A distinguished name is unique throughout the whole directory service.

FIGURE 8-3 shows an example of how directory information is structured, with the DNs and RDNs of the shaded entries.

FIGURE  8-3 SIMS Directory Information Tree (DIT) Example

User Entries

A user entry or user profile contains information on a user. TABLE 8-1 describes each user entry field and whether you must configure a particular field when creating a user entry. A required field is one that actually configures some aspect of the SIMS, while a field that is not required is one that provides incidental information or configures an optional feature.

TABLE  8-1   User Entry Fields  

Field		Required/Not Required For SIMS Configuration	Description
Personal Information/Name
Distinguished name (dn)		Required	A unique path name associated with a user entry that reflects the hierarchy of the directory information tree.
Full name		Required	Stores the possible variations of the first name, last name, and middle initial fields combined. The middle initial is optional. Examples of full names for one particular user are Harrison Green, Harry Green, and Harry A. Green.
First Name		Not required	For example, in the case of Harry Green, the first name is Harry.
Last Name		Required	A last name is a surname, for example, in the case of Harry Green, the last name is Green.
Middle Initial		Not Required	The middle initial is the first letter of the middle name, for example, in the case of Harry A. Green, the initial is A.
Title		Not required	A business or personal title, for example, Accountant or Avid Science Fiction Fan, respectively.
Personal Information/Telephone
Telephone Number		Not required	Can also include extension number.
Fax Number		Not required	Self explanatory.
Pager Number		Not required	Self explanatory.
Mobile Phone Number		Not required	Self explanatory.
Personal Information/Address
Postal address		Not required	Self explanatory.
Location		Not required	Self explanatory.
Office Number		Not required	Self explanatory.
Personal Information/Miscellaneous
Home Page		Not required	The Uniform Resource Locator (URL) for a home page.
Description		Not required	Self explanatory.
Additional Information		Not required	Self explanatory.
System Information
Login name		Required	Unique identification (ID) for user, for example, harryg.
Password		Required	Password associated with login name field; can be stored clear (unscrambled) or crypted (scrambled)
Mail Information
Mail Host		Required	Name of the user's mail server.
RFC822MailAlias: <recipient>		Req. if specified Delivery Channel Type is Connectivity channels	Email address that a recipient inside the email system or the local area network (LAN) proprietary system will see when a message from this user is received.
RFC822MailAlias: <originator>		Required if specified Delivery Channel Type is one of Connectivity channels	Email address that a recipient outside the email system or the LAN proprietary system will see when a message from this user is received.
Internet Mail		Required if specified Delivery Channel Type is one of Connectivity channels	All valid Internet, Lotus cc:Mail, Microsoft Mail, or IBM PROFS Mail aliases for a user. The IMTA will accept a message addressed to any one of the specified addresses.
Internet Mail Delivery Options		Required if you specified Internet as Delivery Channel Type	Location of user's Inbox. Can be either /var/mail or the Sun Message Store. If /var/mail, then must specify mailbox directory. Can optionally enable auto reply, program, forward, and append to file features.
Auto Reply Expiration Date		Req. if you enable auto reply feature in Internet Mail Delivery Options	Date that auto reply feature expires.
Auto Reply Mode		Req. if you enable auto reply feature in Internet Mail Delivery Options	Vacation is only mode currently supported.
Auto Reply Subject		Req. if you enable auto reply feature in Internet Mail Delivery Options	Subject line of auto reply message.
Auto Reply Text		Req. if you enable auto reply feature in Internet Mail Delivery Options	Body of auto reply message.
AutoReplyText For Use Within Organization		Req. if you enable auto reply feature in Internet Mail Delivery Options	Body of auto reply message for use within the user's organization.
Program Delivery Info		Req. if program feature is enabled in Internet Mail Delivery Options	Specifies one or more commands with arguments to deliver to a UNIX program.
Forwarding Address		Req. if forward feature is enabled in Internet Mail Delivery Options	Internet address to which email should be forwarded.
Delivery File		Req. if append to file feature is enabled in Internet Mail Delivery Options	Pathname of file to which email should be attached to the end of.
Calendar Information
CalendarHostName		Req. for Web Access calendars	Calendar server host name
Default Calendar		Req. for Web Access calendars	Name of default Calendar.

Group Entries

A group entry contains information for a distribution list. TABLE 8-2 describes each group entry field and whether you must configure a particular field when creating a group entry. A required field is one that actually configures some aspect of the SIMS, while a field that is not required provides incidental information or configures an optional feature.

TABLE  8-2   Group Entry Fields  

Field		Req/Not Req. For SIMS Con-figuration	Description
General info./General
Distinguished name (dn)		Req.	A unique pathname associated with a group entry that reflects the hierarchy of the directory information tree (DIT).
Full name		Req.	The possible variations of the group address. An example of a full name for one particular group is marketing.
Mail domain		Req.	The mail domain in which a group's mail server resides, for example, sales.alpha.com.
Send Error Conditions To		Req.	The individual who receives a notice when an error condition related to the distribution list arises, for example, if a message addressed to the distribution list cannot be delivered.
Send Request Messages To		Req.	The individual who receives a notice when another individual requests being added as a distribution list member.
Mail Host		Req.	The hostname of the group's mail server.
Password		Req.	The password associated with a group and with a shared mailbox. It can be stored clear (unscrambled) or crypted (scrambled). You are prompted for this password when attempting to modify group entry attributes using the command line interface or the user administration interface.
General info./Telephone
Expandable		Not req.	Make list of members for a particular group or distribution list accessible to all users.
Telephone Number		Not req.	Telephone number for the group. Can also include extension number.
Fax Number		Not req.	Fax number for the group.
Pager Number		Not req.	Pager number for the group.
Mobile Phone Number		Not req.	Mobile phone number for the group.
General info./Address
Postal address		Not req.	Postal address for the group.
Location		Not req.	Location for the group.
Building		Not req.	Building of the group.
Office Number		Not req.	Office number for the group.
Home Page		Not req.	The Uniform Resource Locator (URL) for a home page.
Description		Not req.	Description for the group.
Additional Information		Not req.	Additional information for the group.
Owner
Owner		Req.	An owner is an individual who is responsible for a distribution list. An owner can add or delete distribution list members.
Moderator
Moderator		Not req.	If moderator feature is enabled, a message addressed to a distribution list is initially sent to the moderator only. The moderator can take one of the following actions: forward the message to the distribution list, edit the message and then forward it, or not forward the message.
Member Information
UniqueMember		Not req.	A member is a user or group who receives a copy of an email addressed to a distribution list.
Additional Delivery Options
Shared Mailbox		Not req.	Specifies that messages are delivered to a shared mailbox in the Sun Message Store.
Program		Not req.	Specifies one or more commands with arguments to deliver to a UNIX program.
Append to File		Not req.	Path name of file to which email should be appended (attached to the end of).
Access Control
Authorized Domain		Not req.	Domain name from which users or groups are authorized to send messages to a particular distribution list.
Unauthorized Domain		Not req.	Domain name from which users or groups are not authorized to send messages to a particular distribution list.
Authorized Submitter		Not req.	Name of user or group who are authorized to send messages to a particular distribution list. If the user or group is internal to the email system, specify the distinguished name; if external to the email system, specify an email address in RFC 822 format.
Unauthorized Submitter		Not req.	Name of user or group who are not authorized to send messages to a particular distribution list. If the user or group is internal to the email system, specify the distinguished name; if external to the email system, specify an email address in RFC 822 format.

Password Management

A directory entry for a SIMS user contains a User Password attribute. The value of this attribute, which is used to authenticate the user to the directory, can be stored in encrypted or unencrypted format.

When you supply a password for authentication, or as an attribute value in a directory operation, you specify the value in unencrypted format. You may not enter the password in its encrypted format.

The Netscape Directory Services supports the sha encryption method to encrypt passwords, where as the Sun Directory Services 3.1 uses both the crypt(1) utility and the sunds encryption method to encrypt passwords.

Sun Directory Services Replication

You can share between several directory servers the load of processing requests generated by directory service clients for the same information. This is done by defining a replica, or slave server to provide an alternative access point to the directory service for clients. A master naming context can have more than one replica naming context. FIGURE 8-4 shows a master server with two replica servers. Replication is the process by which changes in the master data store are propagated to all the replica naming contexts. You can replicate an entire naming context, a subtree, or a particular entry. You can replicate the entire content of an entry or you can specify a subset of attributes to be replicated.

FIGURE  8-4 Master and Replica Servers

Using replication has the following advantages:

It reduces the load on the master server by diverting some traffic to other servers.

You can store copies of data where it is mostly frequently used, thus reducing network traffic.

You can store many copies of the data, but the data is maintained from a central location.

You need only replicate the data that is required by clients of the replica server, if you know the requirements of those clients specifically enough. You may be able to tailor a replica exactly to the needs of a specific client. By reducing the number of entries replicated, you reduce the network traffic caused by replication updates.

You could maintain a public replica server containing information that is not confidential, allowing greater access to this information than you usually allow for other servers. For example, you could create a server containing the email addresses for the sales and support staff who deal with current products but not the research staff working on future products, and make it available to the sales staff of a partner company.

---

Note - You could provide the same partial view of directory information with appropriate access controls. However, using a partial replica on a dedicated machine ensures that you are not providing access to your entire network. For extra security, you could connect the replica server to your network only while the replication update is in progress.

---

The costs of using replication are:

Additional network traffic caused by replication of data. However, though there may be an overall increase in traffic, more of the traffic will be local, so you can avoid known network bottlenecks for inquiry traffic. Also, you can time the replication updates for when the network is least busy.

Information retrieved from replicas may be out of date if replication has not happened since an update, so certain applications may always need to query the master data store.

You cannot modify a replica. All updates must be performed on the master copy of an entry.

How SunDS Replication Works

Information from a master naming context is propagated to a replica by the slurpd daemon. The slurpd daemon can run permanently, so that updates to directory information are propagated immediately, or you can define a synchronization schedule. You can override the schedule at any time and trigger an immediate synchronization. This is useful if you change a large number of entries and do not want to wait for the next scheduled synchronization.

The slurpd daemon uses the LDAP protocol to update a replica naming context. A master naming context for which a replica is defined maintains a replication log. Each time the master naming context is updated, the transaction is recorded in the replication log. When the slurpd daemon next runs, it reads the replication log and sends the change to the slapd server that holds the replica naming context. The slapd server handles update requests from slurpd in the same way that it handles all requests, using the information supplied in the bind request to set the access level granted to slurpd requests. To guarantee that all replication updates are completed, slurpd must bind with the DN defined when the replica naming context was configured. If a different DN is used, write access for all entries may not be granted.

A replica data store always has a referral pointing to the master data store. If a replica server receives a request to modify an entry, it returns a referral to the client, indicating the master server to be contacted. In some cases, the client software handles the referral automatically and the user need not resubmit the query. Once the modification has been made in the master naming context, the change is sent to the replica naming context the next time the slurpd daemon runs.

FIGURE  8-5 DIT Naming Context Replica

Example: Replication in the Stream Corporation

The following example characterizes the replica for several naming contexts in the Stream corporation DIT:

All servers will contain a replica of l=Boston, dc=bridge, dc=net, o=internet for fast access to entries concerning the headquarters of the corporation. Only ussales, eursales, and rowsales get their replicas directly from the boston server. The other servers get a replica of the replica from the server that is closest in the network.

A second server, eursale2, will hold a complete replica of ou=Euro-Sales, dc=bridge, dc=net, o=internet to share the load on the existing eursales server.

Each of the servers at the distribution centers will hold complete or partial replicas of the other distribution center naming contexts. For example, the atlanta server will hold a complete replica of ou=London-Dist, dc=bridge, dc=net, o=internet and a partial replica of l=Tokyo, dc=bridge, dc=net, o=internet containing the information about the distribution center but not about the sales office.

TABLE 8-3 shows the replication strategy for each server in the Stream Corporation directory service.

Sun Directory Services 3.1 Features

SunDS 3.1 offers the following features:

Corporate Directories--A distributed corporate directory, accessible from anywhere in the company, and listing networked resources and users with their related details and attributes is almost essential to the smooth running of an enterprise network. SunDS 3.1 provides the ideal solution for creating such a distributed directory.

Global Messaging--To get the most out of a corporate mail system, it is crucial that users be able to find a correspondent's mail address and profile easily and quickly, from anywhere on the network. SunDS 3.1 enables them to do just that.

Naming--All information on the configuration of the local network, which is used by desktop applications, can be stored in SunDS 3.1.

Remote User Authentication--Network access servers use SunDS 3.1 to authenticate remote users and grant them access to the network.

Compatibility --SunDS 3.1 is a multiprotocol directory server. It supports LDAP v.3, RADIUS, HTTP and NIS. It is also compatible with Windows NT LDAP based applications. SunDS 3.1 implements the RFC 1777 recommendations as an information modeling.

Sun Directory Services 3.1 Components

SunDS 3.1 comprises the following components:

A multiprotocol server and data store which stores the Directory Information Tree (DIT).

A replication server which manages data replication between LDAP servers.

A Java-based configuration and management tool which enables Directory Services to be configured and managed from any Java-compliant Web browser.

A Web/LDAP gateway enabling users to navigate through the directory, and to query and edit data from and Web browser.

Database utilities, including a feature which enables import and export of text files from and to other databases.

An SNMP MADMAN (Management and Directory Management) agent, and a RADIUS SNMP agent.

A Java-based directory content editor.