A Brief Overview of LDAP Technology and Terminology

   

A Brief Overview of LDAP Technology and Terminology

The technology and architecture behind LDAP are extremely broad topics that cannot be covered sufficiently within the context of this book. To truly understand LDAP, you may want to examine the resources listed in Appendix B, "ADSI 2.5 Programmer's Reference," and balance your theoretical studies with practical, hands-on experience by utilizing one of the many LDAP server products.

With the caveat that this section is not intended to be a comprehesive discussion of LDAP, we can examine some of the more elemental properties of its specification.

What Is LDAP?

Based on the X.500 directory standard, LDAP is a common language that all LDAP-enabled clients and servers can use to communicate. Although originally proposed as a front-end for X.500 directories to help reduce the complexity of implementing client applications, LDAP has instead dwarved the growth of X.500 directories. This explosion of LDAP use is due in part to its directory specification's relative simplicity.

Timothy Howe, the primary author of the original LDAP specification proposals, has defined four models to establish the standard for the directory access protocol. These models are as follows :

  • Information Model. Defines the data that can be placed in the directory.

  • Naming Model. Defines the organization of the namespace.

  • Functional Model. Defines the methods for accessing and updating data.

  • Security Model. Defines the methods that should be employed to protect the directory from unauthorized access.

The Informational Model: What Can Be Placed into an LDAP Directory?

In large, distributed enterprises , a central repository of employee information is essential to enable quick access to telephone numbers and user account information, and even to establish a common X.509 certificate store. Most enterprises house employee information in various systems, such as the human resources database, the NT SAM, and even local file servers and workstations. However, with an LDAP directory, you no longer need to design applications to query disparate systems, and you can store information about any object.

Meanwhile, if your enterprise houses data on multiple database vendor platforms (such as Oracle, Sybase, and Microsoft SQL Server), implementation of an LDAP infrastructure can also reduce or eliminate the need to maintain the client libraries required to access each database type. This, in turn , significantly reduces support issues and system installation complexity.

With the flexibility provided in an LDAP infrastructure, a developer creating an enterprise telephone directory, for example, can simply query the LDAP directory to derive the information required to create the telephone directory. The developer thus avoids performing a direct query to the appropriate data store(s), eliminating the need to establish data source names (DSNs) and to install libraries for each vendor's database implementation. In addition, in the telephone directory example, the developer can create an infrastructure to pull information directly from the phone system switch and employee database to ensure that a current telephone directory is always maintained without any administration.

Storing information in the directory, meanwhile, is made simple through the use of entries and attributes. An entry defines any entity of interest, whether it is an entire organization, a department, an employee, or even a single machine. Within any entry, attributes are defined to describe the entity. An enterprise user is typically defined by his full name (common name ( cn ) and surname ( sn ) attributes) and, optionally , by the relevant associated department, office location, telephone number, and/or manager information.

Within each entry, a required attribute that defines the entry type is stored in the ObjectClass attribute. Depending on an object's class, several mandatory and optional attributes are also defined. For example, if an entry's class is person , the cn attribute is one of the attributes required to identify that entry.

With a bit of development work, you can extend the LDAP attributes from those specified in default server installations. This allows you to customize the directory to your organization's specific requirements. Note, however, that most directory experts recommend against modifying the directory schema because these customizations can make it difficult to consolidate directories if business entities merge at a later date.

The Naming Model: How Is the Data Organized?

LDAP utilizes a hierarchical data model to organize its directory. Within this model, few restrictions exist as to how the data is placed. This freedom allows you to construct a directory that is nearly flat, is organized geographically or by business unit, or follows any other organizational method that suits the needs of the enterprise.

To store and access the data, you must have a way to reference its location in the directory. LDAP utilizes either a distinguished name (DN) or a relative distinguished name (RDN) to identify entries in the directory. Another hierarchical directory service that uses DNs and RDNs is the NT file system. Within this directory structure, if you want to run notepad.exe from the command line ( pretend for a moment that the %systemroot%/system32 directory is not in the path ), you can use two methods to reference the application name. One method is to use the application's DN to run the application, as follows:

 C:\WinNT\System32\notepad.exe 

Although this first method is very efficient for accessing data when the full path is known, you might occasionally need to verify the existence of the application before running the image. To do this, you can instead execute a series of commands to navigate to the proper folder, as follows:

 C:\>cd WinNT C:\WinNT>cd System32 C:\WinNT\System32>notepad.exe 

Using this method, notepad.exe can be considered an RDN. To access the file, you must be bound to the container holding the object you want to access. In this method, the location of notepad.exe is relative to its parent container.

In LDAP directories, a DN is typically used to quickly navigate to a specific directory location. An object is then created or removed using the directory's RDN.

Also fundamental to directory creation is the organization unit (OU) , whichallows the directory administrator to create logical groupings of directory entries.

The Functional Model: Accessing and Updating Data

The functional model defines how entries are added, modified, and removed from the directory. In addition, this model defines the techniques used to search and compare items in the directory (through interrogation operations) and determines the identity of users attempting to access the under-lying data (through authentication and control operations).

Within the functional model, you can also establish a filter . LDAP filters are used to limit a result set, much like the WHERE clause in a SELECT statement is used in ANSI-SQL. Filter definitions are created using the LDAP search syntax, which can be non-intuitive for those unfamiliar with its definition. Although you can use LDAP filter syntax to limit result sets, the ADsDSOObject provider for ADO allows you to use ANSI SQL syntax against LDAP namespaces. An example of using ADO to search an LDAP namespace will be discussed in the later section "Using ADO to Search an LDAP Directory."

The Security Model: Controlling Unauthorized Access to Entries and Attributes

Oddly enough, the LDAP security model does not define a standard to establish a common access control model. Instead, the standard leaves this to the directory implementor to determine and maintain. The RFC does, however, define the authentication procedure used for the connection- oriented LDAP protocol.

It should be noted that each LDAP server implements security a bit differently. Netscape's server product, for example, allows not only entries in the directory to be secured, but attributes as well. Due to the relatively open specification used in this model, vendor documentation should be used to determine how the specification was implemented in each product.


   
Top


Windows NT. 2000 ADSI Scripting for System Administration
Windows NT/2000 ADSI Scripting for System Administration
ISBN: 1578702194
EAN: 2147483647
Year: 2000
Pages: 194
Authors: Thomas Eck

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net