Directory Information

Directory information is stored in 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. Another attribute is mailHost. Its value would be the host 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 emailPerson object class which has attributes such as commonname, mail (email address), mailHost, and mailQuota. SIMS also specifies an emailGroup object class which has attributes such as commonname, authorizedSubmitter, and rfc822MailMember.

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. See Appendix D, "SIMS Directory Schema and Directory Information Tree," for more information.

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 1-5 shows an example of how directory information is structured, with the DNs and RDNs of the shaded entries.

FIGURE  1-5 Directory Information Tree

In SIMS, specific directory information is often stored in naming contexts. A naming context is simply a subtree or "branch" of the DIT that is identified by its DN. An example of a naming context would be one which stores all entries for marketing employees of the XYZ Corporation at the Boston office. The name of that naming context might be ou=mktg,ou=Boston,o=XYZ,c=US (ou is organizational unit, o is organization, c is country). Naming contexts are listed under data store in the SIMS Admin Console.

In a general-purpose directory service, you have to decide what information you want to store and how that information will be organized. The SunDS directory service has already been designed for you, though you can modify this design, as described in "Modifying the Schema" on page 200.

Organizational Units

An organizational unit is a layer in the directory information tree (DIT). The number of organizational units in a DIT is dictated by the size of your organization and the structure of the Domain Name Service (DNS). For more conceptual information on the DIT and organizational units, refer to the SIMS Installation Guide.

During installation of the SIMS software, the portion of the DIT that you plan to implement on a particular mail server, including the organizational units, if any, is automatically generated. Subsequently, you can add or delete an organizational unit. For more information, refer to "Creating Organizational Units" on page 66 and "To Delete an Organizational Unit" on page 73.

User Entries

A user entry or user profile contains information on a user. TABLE 1-4 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  1-4   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
Home directory		Not required	Location of user's home directory, for example, /home/harryg.
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.
Delivery Channel Type		Required	Can be either Internet, Lotus cc:Mail, Microsoft Mail, or IBM PROFS.
Preferred Recipient, Lotus cc:Mail, Microsoft Mail, or IBM PROFS Mail Address		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. Example: turquoise@mcmqa-s-7.eng.adagio.com
Preferred Originator, Lotus cc:Mail, Microsoft Mail, or IBM PROFS Mail Address		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. Example: kelly.wampus@eng.adagio.com
Internet Mail, Lotus cc:Mail, Microsoft Mail, or IBM PROFS Mail Address		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.
Auto Reply Text 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
Calendar Host		Req. for HotJava/Web Access calendars	Calendar Server host name
Default Calendar		Req. for HotJava/Web Access calendars	Name of default Calendar.

For complete information on the syntax required when configuring these fields, refer to either "To Create a User Entry" on page 59 or "To Modify a User Entry" on page 73.

You can add additional user entry attributes or modify existing ones. For more information, refer to "Modifying the Schema" on page 200.

Group Entries

A group entry contains information for a distribution list. TABLE 1-5 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 is one that provides incidental information or configures an optional feature.

TABLE  1-5   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.	A full name is 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.	Password associated with group and with a shared mailbox; 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
Member		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.

For complete information on the syntax required when configuring these fields, refer to either "To Create a Group Entry" on page 62 or "To Modify a Group Entry" on page 82.

You can add additional group entry attributes or modify existing ones. For more information, refer to "Modifying the Schema" on page 200.

Aliasing

You can define an alias entry. An alias entry is identified by a distinguished name (DN). It contains the name of the directory entry it represents (the aliased object name). The alias entry and the entry it represents must be in the same data store.

For bind and search operations, you can specify that the directory should translate an alias DN to the DN of the actual entry. This is known as dereferencing the alias. For other operations, you need to treat the alias entry as an ordinary entry and not dereference it, for example, to modify the RDN of the alias entry itself, not of the aliased object.

Alias Entries and Searching

The result of a search or read operation involving an alias entry differs depending on whether you dereference the alias. There are four possible settings for the alias dereference flag:

Never dereference alias

Dereference alias when finding base object

Dereference alias when searching

Always dereference alias

For example, suppose your directory contains the following pair of entries:

1) cn=Stan Smith, role=Personnel Administrator, ou=Personnel, ou=Corporate, o=XYZ, c=US

with attributes:

objectclass=orgPerson
cn=Stan Smith
telephoneNumber=123 456 7890
mail=dtmail

2) cn=personnel, o=XYZ, c=US

with attributes:

objectclass=alias
aliasedObjectName="cn=Stan Smith, role=Personnel Administrator, ou=Personnel, ou=Corporate, o=XYZ, c=US"

With alias dereferencing when searching, if you search for the telephone number of cn=personnel, o=XYZ, c=US, you will see Stan Smith's telephone number. With no alias dereferencing, you would not see any telephone number.

Defining aliases for roles is particularly useful when the person occupying a role changes frequently (the duty network manager for out-of-hours calls, for example), so that users always query the same entry. You can change the value of the aliasedObjectName with a script that runs on a schedule and calls ldapmodify to make the changes.

See the SIMS Reference Manual for details of how to specify how alias dereferencing is used in ldapsearch.

Alias Entries and Authentication

Every interaction with the directory starts with a bind request, to authenticate the user and establish the level of access permitted. The DN supplied in a bind request can be the DN of an alias entry. With alias dereferencing, the user binds with the DN contained in the aliasedObjectName of the alias entry, and is granted the access rights defined for the entry with that DN.

Alias dereferencing in bind is a configuration choice. If aliases are not being dereferenced and the user binds with the DN of an alias entry, access is denied because the password attribute is not present.

Infrastructure Information

Infrastructure information determines how the components of a directory service behave and how directory entry information is interpreted. It includes the directory schema, knowledge information, and component configuration information.

Schema

The directory schema is the set of rules that describes the data that can be stored in the directory. It defines the types of entries permitted, their attribute structure, and the syntax of the attributes. This product contains a pre-defined schema, which you can modify, with certain restrictions. See "Modifying the Schema" on page 200 and Appendix D, "SIMS Directory Schema and Directory Information Tree for further schema details.

Knowledge Information and Referrals

A directory server uses knowledge information to pass requests for information to other servers. The knowledge information held by a directory server is a reference to a directory server holding other naming contexts. When a server receives a request for information, it checks whether it can respond to the request using the information in the local data store. If it cannot, it checks the referral defined for the data store, and returns the details of an alternate directory server to the directory client. The client can then send the request to the other directory server. Some clients contact the alternate server automatically, so the referral mechanism is transparent to users. Other clients return the referral information to the user.

See "Example: The XYZ Corporation" on page 40 for an example of how referrals are used.