Directory Services and Interoperability

NOSs collect information into a specialized database called a directory. Directories are optimized to be fast to access, to be flexibly organized, to be rich in content, and to have access to the information carefully controlled. Nearly all the modern network directories in use today store information into an object database schema. Entries in the database are named entities with numerous properties associated with them, as well as the ability to create new properties for each.

The directory service is the application that runs on the server that accesses the stored information. You can think of a directory service as an object database and the directory as its data store. The service is optimized for fast searches and reads. Because a directory contains most of the personalized information about systems and users, an important part of any directory service is that it is the authentication authority for access to network resources based on identities, personalities, and their relationships to the resources they are trying to access.

Although directory services share many of the properties of a relational database, there are some significant differences. Most databases balance reads and writes, have lots of tuple relationships, and attempt to reduce the amount of data redundancy to a minimuma process called normalization. Directories don't allow for tuple or many-to-many relationships, and they don't provide a means to revert or roll back changes or transactions. The fundamental difference, though, is that the attributes of an object in a directory would be broken apart into independent values if they were stored in a relational database.

At any one time, there is a considerable amount of authentication going on at the directory server as well as authentication traffic passing over the network. In order to lessen the impact of directory network traffic on a LAN and especially on a WAN, most directories are designed to be distributed across both multiple servers and sites. Changes to the directory are replicated using one of many replication topologies, but most often, a topology with a single- or multiple-master directory server(s) is employed.

X.500

There's a problem with directory services: In any large enterprise, server OSs and enterprise applications are all running their own directory services. It is common for large, heterogeneous networks to run many directory services. Companies often have as many as 20 or 30 directory services running at a time. Interoperation between all these services would be impossible were it not for some industry-standard naming conventions and some specialized tools that different OSs and third-party vendors offer.

Objects in a directory are named according to a set of rules that provide a mapping of the resource name to the physical address of the resource. The universe of all possible named objects (even those objects that don't yet exist) is known as the service's namespace. Each object has a unique and unambiguous name in the namespace, something that is called its distinguished name (DN).

An example of a DN is cn=George Washington,ou=people,dc=encyclopedia,dc=com, which describes an entry for the first U.S. president in a listing describing people listed in the directory www.encyclopedia.com (a hypothetical example). In this example, an ou is an object, and George Washington is an attribute, encyclopedia is the directory, and .com (the Internet commercial nameserver) is the repository of the namespace. The hierarchical schema thus describes people in a listing that is often used in whitepaper schema, similar to a phone book.

X.500 is a complete directory service specification. It outlines how logical schema are related and how directory access can be achieved. Directory access is how stored objects can be queried, accessed, and replicated to other directory systems. The X.500 definition includes three transport protocols:

• Directory Access Protocol (DAP) DAP specifies how an application can access stored information in an X.500-compliant directory.

• Directory Service Protocol (DSP) DSP specifies how to propagate requests for information from one directory server to another directory server in a hierarchy of directory servers.

• Directory Information Shadowing Protocol (DISP) DISP describes the rules under which objects and information can be replicated. Replication requires that a master copy exist and that copies of that data be distributed on multiple servers so that the directory service response time can be acceptable and so the system has improved fault tolerance.

LDAP

Because DAP is a very resource-intensive protocol, lighter-weight protocols have been developed. The best known is Lightweight Directory Access Protocol (LDAP), which is now in version 2. With LDAP you can access data in any X.500-compliant database, but you do so over TCP/IP, without having to incur the overhead that is in DAP.

As Table 18.3 indicates, many implementations of LDAP are available, both from NOS vendors such as Microsoft and Novell, and from database vendors such as Oracle. LDAP implementations have also been created by the opensource community.

Table 18.3. Directory Services

Service	Vendor	Description
Active Directory	Microsoft	The directory service of Windows 2000 and 2003 servers. For a description of AD, see www.microsoft.com/windows2000/server/evaluation/features/dirlist.asp.
Apache Directory Server	Apache Software Foundation (open source)	An X.500 and LDAP directory with an administrative server back end. It uses the MINA framework and implements industry-standard protocols such as Kerberos.
Open Directory	Apple Computer	Open Directory is based on the OpenLDAP open source implementation and ships with Apple Mac OS X Server. Among its features are Windows support, Kerberos, NT Domain services, Samba 3, and LDAP account integration. With these features, a Mac OS X server can function as a Windows domain server.
DirX server	SiemansAG	See www.siemens.com/directory.
eDirectory	Novell	An LDAP directory and management system that is best known for successful large enterprise deployment (although it is installable in enterprises of all sizes). For more information, see http://www.novell.com/products/edirectory/ and http://en.wikipedia.org/wiki/Novell_Directory_Services.
Fedora Directory Service (FDS)	Red Hat	Originally developed at Netscape, FDS ships with Red Hat Linux server.
Kerberos	Novell	This is Novell's LDAP implementation, described in more detail earlier in this chapter. See www.novell.com/products/edirectory/ for more information.
Domain Name Service (DNS)	Internic/ICANN	DNS is the Internet name service. ICANN also maintains the reverse directory lookup WHOIS.
GroupWise	Novell	GroupWise is Novell's email name and address book service.
Notes	Lotus/IBM	The Name and Address Book is an application-specific directory service.
Exchange Address Book	Microsoft	This is a first implementation of AD.
Network Information Service (NIS)	Sun Microsystems	NIS appeared first as Sun's UNIX Yellow Pages. Eventually, Sun rolled NIS into the iPlanet directory service acquired from Netscape. iPlanet eventually became Sun ONE and is now part of Sun's current offering, Sun Java Enterprise.
Novell Directory Service (NDS)	Novell	NDS is marketed as a heterogeneous directory service that can support UNIX, Windows, Linux, NetWare, and even AS/400. Novell has had some success marketing NDS to large Internet websites, including CNN.com. The NDS logo appears on sites that use this service.
Open Directory Project (ODP)	Open source/community maintained	ODP or Directory Mozilla (DMoz) is an open directory project that indexes content linked to on the web through Time Warner.
OpenLDAP	open source	OpenLDAP is used as the model for a number of vendors' directory services. See www.openldap.org.
Internet Directory	Oracle	Internet Directory is used in Oracle's database and business applications.
Samba	open source	Samba can be a domain controller, with LDAP and Kerberos support.
StreetTalk Directory	Banyan	This is one of the first full-featured enterprise network directory services to appear.

Lightweight is really something of a misnomer because LDAP contains a detailed specification for naming and mapping. LDAP is based on the X.500 ISO/ITU directory service, which itself is based on the original DAP, but LDAP has a life of its own. Developments in LDAP have contributed to later versions of X.500 and influenced several other Internet standards.

LDAP was developed for browser applications and then extended to network management services and applications. Services based on LDAP are so widely used in modern networks that they are almost ubiquitous. DNS servers are based on LDAP. You are already familiar with LDAP because we all use it frequently in many forms. For example, in LDAP version 3 the mailing address [e-mail] is in a UTF-8 format. Eventually LDAP will become the directory-to-directory communication protocol standard. However, LDAP can't replace an X.500-type directory service, which is where network directory servers come in.

What makes LDAP particularly useful is that it defines interoperability and transport over TCP/IP, it defines relatively simple directory searches and updates, and it is supported by most modern NOS services. Any directory service that uses LDAP and understands how to access objects labeled with X.500 identifiers is termed an LDAP directory. How the directory service implements LDAP features is left entirely up to the developers; thus there is no such thing as a standard LDAP directory. LDAP first appeared out of work done at the University of Michigan, where OpenLDAP was created. Eventually LDAP was codified into a protocol and popularized by Netscape.

Table 18.3 lists some of the better-known and important directory services.

Table 18.3 is only a partial list of directory services; many more could be listed. What is common to all these services is that they are able to exchange information with other directory services, using either X.500 or a subset or, much more commonly, LDAP. Whether they can exchange information natively or whether they require additional help is the topic of the next section.

A careful examination of the directory services in Table 18.3 indicates that there are four basic categories of directory services:

• X.500, LDAP, and other standards-based, general-purpose directory services

• NOS directories, such as AD, iPlanet, and StreetTalk

• Application-specific directories, such as the messaging directories of Notes, Exchange, and GroupWise, as well as databases such as Oracle, and many others

• Special-purpose directories, such as the Internet's DNS

The Microsoft Management Console (MMC) offers a view into many of the aspects of Windows AD. Figure 18.1 shows the policy console. Often there are better tools available for manipulating directory services than those that come natively with NOSs.

Figure 18.1. The MMC, showing some of the policy assignments that have been made. Note that the left panel lets you choose from a number of AD areas, using MMC snap-ins. The framework is extensible so that other vendors can add their solutions to the MMC.

Directory Services Interoperability

We are most concerned here with NOS directories and, more specifically, with the ability of a NOS directory service to be able to talk with the three other types of directory services. What LDAP can't dothat is, support many of the features of X.500the NOS directory services can do. NOSs began to support directory services when Banyan Vines StreetTalk appeared, and this was one of the reasons Vines had such success early on in large enterprises.

Hopefully you've noticed that your favorite NOS or enterprise application is on the list in Table 18.3. It's hard not to be impressed by how central directory services are in making modern network services operate efficiently and effectively. The trick is to get all these services to work together seamlessly. Strong interoperability should be a key factor when you decide to adopt an application or an OS.

Interoperability is a must in two central areas: security and information or personalization sharing. These two areas are intimately related. A user or an administrator shouldn't be able to access information unless he or she is authorized to do so, and authorization should be tied to the personalization or profile of that user.

The ultimate system would allow a single central data repository with a single secured logon for all users. If you intend to run an enterprise with best-of-breed components, you aren't going to be using a single data repository, and single-signon is difficult to achieve. How well you can achieve single logon depends on how well integrated security services can be made to be, and that is a function of the security standards that are in place (Kerberos, X.509 certificates, and others) as well as the access control protocols in use.

Novell NetWare's approach to directory management has been to create a tool originally called Novell DirXML, which is bundled as a starter pack with NetWare 6.5. DirXML has drivers that can let a NetWare server exchange data from Microsoft AD with Novell's eDirectory. Another feature of DirXML is that it can synchronize passwords with a Windows domain. Recently Novell has renamed DirXML Novell Nsure Identity Manager (see www.novell.com/products/nsureidentitymanager/) to emphasize this capability of the product. Nsure Identity Manager is one of the tools you can manage with Novell's browser-based iManager system tool, which is also bundled with NetWare.

FDS is based on directory server technology that Red Hat acquired from AOL in 2004. It is managed as part of the Fedora project and is advertised as being compatible with Fedora Core 3, Solaris 2.8 and 2.9, Windows 2000 Server, and HP-UX 11i. FDS comes as an LDAP definition service, with management tools offered to users in binary form. FDS is supported by the Fedora community, while RedHat offers a commercially supported version known as RedHat Directory Service (RDS).