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.
An LDAP client connecting to any LDAP server sees the same view of the LDAP directory information tree. A name presented to one LDAP server references the same entry it would at another LDAP server. This is an important feature of a global directory service like LDAP.
Directory applications access information in directory services. BeyondMail® is a Banyan application that uses VINES® Application Programming 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 much more often than it is written. As a consequence, LDAP directory services do not usually implement the complicated transaction or roll-back schemes regular databases use for doing high-volume complex updates. Directory service updates are typically all-or-nothing changes, if they are allowed at all. LDAP for StreetTalk does allow updates and modifications to the directory.
LDAP directory services are tuned to give quick response 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 that information can be referenced and queried, updated, and protected from unauthorized access.
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 any 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):
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 Robert Smith, Al Jax, Doug Ross, and Mary Dawes.
DIT Directory Information Tree This is 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=WCTUS1, 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 The lowest level of the LDAP directory information tree. In the example above, the entries cn=Robert Smith, cn=Al Jax, cn=Doug Ross and cn= Mary Dawes 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.
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.
LDAP directory entries are defined by the LDAP schema.
LDAP schema consist of the collection of all object class definitions that can be used to create and access information in the LDAP directory information tree. Each objectClass definition declares:
The name of a particular kind of objectClass The list of required and allowed attributes for the objectClass 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 objectClass definitions. You can add additional objectClass 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 objectClass definitions.
The LDAP protocol uses the following terms to describe LDAP schema items:
Allowed attribute - Defines optional attributes. You can include or omit these attributes when you create the directory entry.
ObjectClass - Defines the LDAP directory entry. In Figure B-1, "c" is the objectClass definition for the directory entry US.
Required attribute - Defines an attribute that must be included in each instance of an object of type objectClass. More than one attribute can be required and you must include all required attributes when you create the directory entry.
LDAP for StreetTalk version 3.0 supports write operations on the LDAP database, allowing you to search, compare, 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.
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 subtree 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 allows you to assign unique names and attributes to users and resources (printers, servers, services, and so on) in the network to easily find and manage them. Attributes describe and categorize properties of the resource.
Individual users, groups of users, and resources are added to the 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.
Every StreetTalk service maintains a database on the server on which it runs. The database contains detailed information about
Groups physically 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 impacting users.
Tracking all resources in this way eliminates the need for complex addressing schemes and allows network users to 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.
