|
|
Directory Services |
|
The last few years have seen an enormous proliferation of networked computing devices as businesses are increasingly relying on distributed systems to support their line-of-business applications. This proliferation has resulted in an unprecedented growth in both clients and servers that are attached to a network. Of course, the network itself has also changed and can now encompass everything from a local area network (LAN), a corporate intranet, or the public Internet.
As the number of people and networked resources have increased, several problems have emerged:
For these reasons, directory services is becoming an important facet of the enterprise computing environment. Directory services enables you to collect information that describes users, applications, file and print resources, access control, and other resources into a common directory that is accessible from all users and applications on the network.
Directory services improves functionality because the directory is not specific to any one particular application. All directory-enabled applications in the enterprise can use it. This eliminates islands of information that are caused by applications that implement their own specialized repositories to manage resource information.
Directory services also greatly improves administration because the information is centrally managed. Any adds or changes that you make to the information in the directory are immediately available to all users and directory-enabled applications. For example, instead of changing an access control list for a resource on each system that accesses it, you only have to change the information once and each application can use this information to control access to the resource.
In 1987, the International Telecommunications Union (ITU)¹ X.500 recommendation on directory services was adopted. This recommendation included a specification for a Directory Access Protocol (DAP) that defined a protocol used to control communication between a user and the directory. This DAP was based on the Open Systems Interconnect (OSI) protocol stack.
The X.500 recommendation set the stage for several successful commercial implementations of directory services. (One early implementation of particular note was the Novell Directory Services (NDS) first introduced in NetWare Version 4.0.) However, one of the obstacles to broader acceptance of the X.500 standard was the reliance of the DAP on the OSI protocol stack. The OSI stack has yet to gain widespread acceptance by the industry, in part because of its complexity.
To address this issue, the University of Michigan, with support from the Internet Engineering Task Force (IETF), developed a simpler DAP called the Lightweight Directory Access Protocol (LDAP). LDAP was developed to provide access to a directory server without the overhead of the OSI protocol stack. LDAP is based on TCP/IP and is therefore applicable for use on LANs, WANs, as well as over the Internet.
LDAP is an open, vendor-neutral standard that enables you to work with any LDAP-compliant server. LDAP specifies only the interface protocol to the directory and does not specify how the actual directory is implemented. For example, the Microsoft Active Directory in Windows 2000 is implemented quite differently than the Netscape Directory Server, but, because they both support an LDAP interface, you can use the same applications to work with them.
LDAP is fast becoming the de facto directory protocol for corporate intranets as well as the Internet. It is supported in most network operating systems and collaborative applications. LDAP support has also been implemented in most network-oriented middleware products.
Specific platform support for LDAP access is broad. Client bindings are available for various platforms in C/C++ from the OpenLDAP and Mozilla organizations as well as commercial vendors. PERL support is available from Mozilla, and Java support is provided through Sun Microsystems' JNDI facility. Support for Windows is provided through the Active Directory Services Interface (ADSI) and third-party ActiveX controls.
LDAP continues to evolve. The original LDAP specification was defined in RFC 1777 in 1995. The current version of LDAP is version 3, defined by RFC 2251. Version 3 extends the Version 2 specification with additional features such as the ability to define custom operation codes, formalized referrals, and improved internationalization by using the UTF-8 character set for all data.
Draft specifications have been developed to extend LDAP by adding a standard access control model, dynamic directories, server-side sorting of search results, LDAP server discovery, and other extensions. For more information on these extensions, visit the IETF LDAP Extension Working Group Web site.
A directory is a specialized database that is designed to retrieve information quickly and securely. It is optimized for read access because the type of information in the directory is searched often, but changes infrequently. For example, a user name that you add for a new employee is not likely to change for the entire period of employment.
Information about the services, resources, users, and other objects that are accessible from the applications is organized as a collection of individual entries that contain information about each resource. To make accessing these entries as efficient as possible, they are organized in a hierarchy called the Directory Information Tree (DIT).
The following diagram shows an example of a DIT:
|
The root of the tree is typically a country (C) followed by an organization (O). For example, in the figure above, the root of the tree is o=Alpine Airways,c=US. One or more organizational units (OU) typically appear below the root. These are container objects in that they can contain other directory entries. Directory entries that store information about a specific resource are referred to as leaf objects and they are added to the tree under an existing container object.
The path to each entry in the tree is called its distinguished name (DN), and each DN in the tree is unique. For example, using the DIT in the figure above, the DN for the Airplane Maintenance Department of Alpine Airlines would be ou=Planes,ou=Maintenance,o=Alpine Airways,c=US.
A directory entry contains a set of name/value pairs, which are called attributes. An objectclass attribute is required for each entry in the directory. The object class determines which attributes are allowed for the entry as well as any that are required. The set of defined attributes and object classes that defines the content of acceptable entries within the directory server is called the Directory Schema.
An attribute for a given entry may have multiple values. For example, because an OU can have multiple values assigned to it, a person might belong to more than one organization unit. When the DIT is searched, the order in which the attributes are returned cannot be guaranteed. Therefore, no implicit priority or hierarchy of attribute values can exist within an entry.
Here is an example of a directory entry for a person in our example airline enterprise:
cn=John Smith,o=Alpine Airlines,c=USEntries in an LDAP directory can be read directly if the exact DN is known. Usually, however, the directory is searched for entries that match a particular set of specifications. In order to perform a search, the directory server has to know the starting place in the tree (called the base), how deep in the tree the user wants to look (called the scope), and the search criteria (called the filter).
The base can be any DN that is served by the directory server that is being queried. If the DN is outside the domain of the server, it may return a referral. The referral has the data that is necessary to connect to another server that may have more entries that match the filter. The client might decide either to chase (peruse possible filter matches on the other server) the referral or to ignore it.
A search can also contain a scope. The scope determines how far down in the tree from the base the search is made. A scope of BASE will only return the base object if it exists and matches the filter. (The filter is required even with a scope of BASE). A scope of ONE will only search the base and entries immediately below the base entry. A scope of SUB will search the entire sub tree starting at the base entry. Limiting the scope of a search makes it more efficient. If you know that an entry is one level below the base, limiting the search to that scope makes it run faster. If you want to search all entries that are below the base, though, search the sub tree.
A scope of BASE is used when you retrieve special entries. For example, most servers support a special entry with a DN of cn=monitor that returns information about the state of the server. When you search for that entry, a scope of BASE is required.
The search filter determines which entries below the base will be returned. A simple filter is composed of an attribute name, an operator, and a value. The following table describes the valid search operators.
LDAP Search Filter Operators
| Operator | Definition | Description | Example |
|---|---|---|---|
| = | Equality | Attribute must exactly match value. | cn=Jean Smith |
| =<string>*<string> | Substring(s) | Substring attribute must contain substring(s) provided. The asterisk (*) matches zero or more characters. | (cn=*Smith, title=*Manager*) |
| >= | Greater than or equal to | Attribute must be greater than or equal to value. | age>=30 |
| <= | Less than or equal to | Attribute must be less than or equal to value. | roomnumber<=3999 |
| =* | Presence matches | Entry has attribute of specified name. | (objectclass=*) |
| ~= | Approximate | Usually implemented as a "sounds like" algorithm. Attribute must be "approximately equal" to value. | cn~=Jean Smits |
| & | Boolean AND | All filters must be true. | (&(sn=Smith)(ou=Reservations)) |
| | | Boolean OR | Any of the filters might be true. | (|(manager=cn=Jean Smith,ou=Reservations,o=Alpine Airways,c=US)(ou=Marketing)) |
| ! | Boolean NOT | None of the filters might be true. | (&(!(ou=Maintenance)(!(ou=Finance)))) |
While the intent of the directory is to share much of the information in it across many applications, it must also be protected in order to prevent unauthorized access to sensitive data.
Security within the directory is achieved using both authentication and access control. Authentication identifies a user's credentials to the directory server. Access control determines which entries a user is allowed to access based on that identity. Both of these topics are discussed next.
A user establishes a connection to a directory server by performing a bind operation. Part of the information that is used in performing this operation is the user's identity and password. There are three basic bind mechanisms — anonymous, simple, or secure.
The simplest bind mechanism is an anonymous bind. Access is granted based on the user having no identity within the directory. While it is normal to provide read access to certain entries and attributes for anonymous users, most application data will be protected against retrieval by unknown users.
A simple bind operation is performed when the user provides a DN for an entry within the directory and a password that goes with that entry. The entry must have a USERPASSWORD attribute, which is checked against the password provided. If the bind is successful, the user's identity will become that DN for the duration of the connection and access to entries will be based on that identity.
While the simple bind is adequate for most environments, it requires that you send the password in clear text over the network. Some directory servers implement secure authentication methods, such as Kerberos or certificate-based authentication like SSL. Any authentication method that is used must resolve to a directory entry in order to permit a comparison with the access control list (ACL). After authentication, the ACL specifies access controls that are based on the DN for the user.
There are literally as many access control schemes as there are directory servers. The OpenLDAP server keeps the access control lists in the configuration file and uses regular expressions for the comparison of ACL targets (what is being secured) and subjects (who is being allowed access) while Netscape and IBM keep the access control information in the directory tree as an attribute of the entries. However, the basic ideas are similar across server implementations. The ACLs can control access to the entire directory tree, or portions of it, down to the attribute level. Special access can be granted so that users can access their own DNs. A user may be allowed access to attributes on his own entry that no one else has access to, such as the USERPASSWORD attribute. There is usually a default access mode, and the ACLs are used to override that default. For instance, Netscape servers have a default access of none, so if there are no ACLs that are defined on a directory tree, no users can access it except the directory manager. ACLs can be added to allow access to parts of the tree or specific entries based on user DN or group membership.
¹ In 1987 when the X.500 recommendation was adopted, the ITU was called the Comité Consultatif International Téléphonique et Télégraphique (CCITT).
|
|
Directory Services |
|