Appendix B - Directory Concepts
Directory services provide access to databases of network resources. The database contains a collection of objects that are displayed and accessed by end users. Typical objects in the database include users, services, and documents. Each object has one or more associated attributes. For example, a user object might have attributes such as phone number and email address.
Some directory services are local, providing service to a restricted context. Other services are global, providing service to a much broader context.
LDAP, Lightweight Directory Access Protocol, is a directory service protocol that runs over TCP/IP. The LDAP protocol is a global directory model based on a simplified approach to the X.500 standard. Applications such as Microsoft Internet Explorer and Netscape Communicator can use LDAP calls to access data in any LDAP-compliant directory service.
The LDAP service is based on a client-server architecture. One or more LDAP servers contain the data that make up the LDAP directory information tree. An LDAP client connects to an LDAP server and queries the LDAP server for information. The server responds with the information or with a referral (a pointer) to where the client can get the information.
Any LDAP client connecting to any LDAP server sees the same view of the LDAP directory information tree. A name presented by one LDAP server references the same entry it would at another LDAP server. Presenting a consistent view is an important feature of a global directory service like LDAP.
Understanding Directory Applications
Directory applications access information in directory services. BeyondMail® is a Banyan application that uses VINES® Application Program Interfaces (APIs) to access a StreetTalk directory service to locate and display user names and email addresses. Netscape Communicator is a directory application that uses LDAP APIs to access information in LDAP-compliant directory services.
Entries in an LDAP-compliant directory service contain attribute-based, often descriptive, information. Information in directory services is generally read from the database much more often than it is written to the database. Consequently, LDAP directory services do not usually implement the complicated transaction or roll-back schemes regular databases use for doing high-volume complex updates. LDAP Directory service updates are typically all-or-nothing changes, if they are allowed at all. LDAP for StreetTalk does allow LDAP administrator's to update or modify the directory database.
LDAP directory services are tuned to respond quickly to high-volume lookup or search operations. They may have the ability to replicate information widely to increase availability and reliability, while reducing response time. In replicated directories, temporary inconsistencies between the replicas may be acceptable until synchronization occurs.
There are many different ways to provide an LDAP directory service. Different methods allow different kinds of information to be stored in the directory, and place different requirements on how stored information can be referenced and queried, updated, and protected from unauthorized access.
LDAP Directory Information Tree
LDAP directory entries are arranged in a tree-like structure called a Directory Information Tree (DIT). Entries in the DIT usually reflect political, geographical, or organizational boundaries.
The root entry is the highest level of the directory structure. Directory entries that you define reside below the root, and are organized according to LDAP conventions.
By convention, directories representing countries, such as c=US or c=FR reside below the root. Below them are directory entries representing high level organizations or locations. Lower level directory entries represent localities, as well as other items meaningful to the organization, such as geographical locations, business units, people, servers, documents, and network services.
Figure B-1 shows a sample LDAP directory information tree (DIT):
Directory Structure Terminology
LDAP protocol uses the following terms to describe items in the directory information tree:
Attribute. A value associated with a directory entry. In the example above, mail and fax are attributes associated with the directory entry o=WCT. Title is an attribute associated with Bob Smith, Al Jax, and Doug Ross.
DIT Directory Information Tree, the LDAP hierarchy and all of its entries.
Directory Entry An object in an LDAP Directory Information Tree. In Figure B-1, c=US, o=WCT, and cn=Doug Ross are all directory entries.
DN Distinguished Name. The DN provides an unambiguous reference to an entry.
To construct the DN, take the name of the entry and concatenate the names of its ancestor entries. In the example above, entry cn=Doug Ross is identified by DN cn=Doug Ross, ou=Finance, o=WCTUS2, l=Boston, o=WCT, c=US. Each component of the distinguished name is called a relative distinguished name (RDN).
Distinguished names include an associated attribute name. The attribute name is a mnemonic string that identifies the kind of object as well as its probable location in the Directory Information Tree. For example, the attribute c indicates country. Country is the highest level in the directory information tree.DN format is described in RFC 1779, A String Representation of Distinguished Names.
Leaf node The lowest level of the LDAP directory information tree. In the example above, the entries cn=Bob Smith, cn=Al Jax, and cn=Doug Ross are leaf nodes of the LDAP directory information tree.
RDN Relative Distinguished Name. RDN is unique in the context of its parent entry. For example, cn=Doug Ross is unique within the Finance organizational unit (ou). One or more attributes from the entry make up the RDN.
Distinguished Name Attributes
The following attributes are associated with the distinguished names in the directory information tree. These attributes typically identify the kind of directory entry, as well as provide information about the entry's position within the LDAP hierarchy.
c Directory entries representing a country. This is the highest level.
o Directory entries representing an organization. This level is subordinate to c, and usually represents national organizations or businesses. A typical use might be o=WCT, c=US.
l Directory entries representing locality. In Figure B-1, this level is subordinate to c and o, and usually represents geographical locations, subsidiaries, or divisions.
A typical use might be l=Boston, o=WCT, c=US.ou Directory entries representing an organizational unit. This level is subordinate to c. o, and l, and usually represents organizations and business units. A typical use might be ou=Sales, o=WCTUS1, l=Boston, o=WCT, c=US.
cn Directory entries representing common name. This is the lowest level and is subordinate to ou. cn typically represents objects or items, such as people, documents, or machines.
Defining Directory Entries
The LDAP schema for the directory defines LDAP directory entries and their contents. Schema define what object classes are allowed where in the LDAP directory, which attributes an entry must contain, which attributes are optional for an entry, and the syntax of each attribute.
LDAP Schema Terminology
LDAP protocol uses the following terms to describe LDAP schema items:
Allowed attribute Specifies optional attributes for an object class. You can include or omit these attributes when you create the directory entry.
Object class Specifies the type of an LDAP directory entry. In Figure B-1, the directory entry c=US is an entry of type country.
Required attribute Specifies an attribute that must be included in every instance of an object of type object class. An object class can require more than one attribute. You must include all required attributes when you create the directory entry.
LDAP Schema
LDAP schemas consist of all of the object class definitions that can be used to create and access information in the LDAP directory information tree. Each object class definition declares:
The name of a particular kind of object class, such as inetOrgPerson or organizationalUnit The list of required and allowed attributes for the object class
LDAP object classes define commonly used
database items such as person, alias, and organization. Associated
attributes contain related information, such as telephone number,
title, or email address. The LDAP for StreetTalk service includes
all object classes defined by LDAP
version 3, as well as many commonly used object class definitions.
You can add additional object class definitions to meet the specialized
needs of your organization. Refer to "Using
LDAP Configuration Manager to Manage LDAP Schema" in
Chapter 3 for information about adding object class definitions.
LDAP Operations
LDAP for StreetTalk supports write operations on the LDAP database, allowing you to modify, and add or remove entries in the directory information tree.
LDAP defines operations for interrogating, managing, and updating a directory tree. Operations are provided to manage directory entries, including:
Adding a directory entry Deleting a directory entry Modifying a directory entry Changing the name of a directory entry Searching the directory information tree Comparing an attribute value to a value in a directory entry
Searching a Directory Information Tree
LDAP applications and programs are used to search for information in the LDAP directory information tree. LDAP-compliant mail programs, such as Netscape Mail and Microsoft Outlook Express, use the LDAP directory information tree to access user mail and address information.
Applications and programs can search all or part of the LDAP directory information tree. Figure B-1 shows a typical directory information tree. Users can use LDAP to:
Search the entire LDAP DIT for cn=Doug Ross, and retrieve information for all users with the common name Doug Ross. Narrow the search to a specific part of the LDAP tree, for example, Finance only. Search a specified number of levels in the directory tree, for example, one level below WCTUS1 in Figure B-1. Search for a specific attribute, and display the corresponding directory entries. For example, a user might search for the attribute Title=Accountant and retrieve all directory entries with that attribute.
Refer to Chapter 4 for information about how to use the command line tool ldsearch to search a directory tree.
StreetTalk directory service is a Banyan service that lets you assign unique names and attributes to users and resources (printers, servers, services, and so on) in the Banyan network so you can find and manage them easily. StreetTalk attributes describe and categorize properties of the resource.
Individual users, groups of users, and resources are added to the Banyan server and given names in the StreetTalk service located on that server. Unless the administrator later moves them, each resource remains on the server and is "owned" by the StreetTalk service on that server. The server on which a user's StreetTalk service resides is that user's home server.
StreetTalk Databases
Every StreetTalk service maintains a database on the server on which it runs. The database contains detailed information about
Groups located on the server Items in each group All name and attribute information associated with items in the groups The location of other groups on different servers in the network
Access to resources is always consistent because detailed, item-level information is updated and shared among servers.
In a single server network, the StreetTalk directory is this database. In a multi-server network, the directory is distributed among servers and there is no single point of failure. Services regularly share information, indicating their own database changes to all StreetTalk services in the network. Thus, StreetTalk services maintain a complete and up-to-date picture of resources available on the network. The network does not have a centralized naming server, which, if not available, could limit the network's ability to function. In a Banyan network, names are accessible to the entire network even if a server fails. You can relocate or replace resources without directly affecting users.
Tracking all resources in this way eliminates the need for complex addressing schemes and lets network users find resources using natural and logical names consistent with their workplace. Users do not need to know where a resource is located; they only need to know a resource name. If a user knows the name, StreetTalk can find the resource if it is currently available.
