LDAP(Lightweight Directory Access Protocol) - Seminar

ABSTRACT

LDAP, Also known as X.500 Lite, the protocol enables corporate directory entries to be arranged in a hierarchical structure that reflects geographic and organizational boundaries. Using LDAP, companies can map their corporate directories to actual business processes, rather than arbitrary code.

LDAP was originally developed as a front end to X.500, the OS1 directory service. X.500 defines the Directory Access Protocol (DAP) for clients to use when contacting directory servers. DAP is a heavyweight protocol that runs over a full OSI stack and requires a significant amount of computing resources to run. LDAP runs directly over TCP and provides most of the functionality of DAP at a much lower cost. This use of LDAP makes it easy to access the X.500 directory.

LDAP was originally intended to be a lightweight alternative protocol for accessing X.500directory services. X.500 directory services were traditionally accessed via the X.500 Directory Access Protocol, or DAP, which required the cumbersome Open Systems Interconnection (OSI) protocol stack

INTRODUCTION

A Directory is like a database: you can put information in, and later retrieve it. But it is specialized. Some typical characteristics are: designed for reading more than writing, offers a static view of the data, simple updates without transactions. Directories are tuned to give quick-response to high-volume lookup or search operations.

The LDAP information model is based on entries. An entry is a collection of attributes that has a globally-unique Distinguished Name (DN). The DN is used to refer to the entry unambiguously. Each of the entry's attributes has a type and one or more values. The types are typically mnemonic strings, like "cn" for common name, or "mail" for email address. The syntax of values depend on the attribute type. For example, a cn attribute might contain the value Babs Jensen. A mail attribute might contain the value "babs@example.com".

In LDAP, directory entries are arranged in a hierarchical tree­like structure. Traditionally, this structure reflected the geographic and/or organizational boundaries. Entries representing countries appear at the top of the tree. Below them are entries representing states and national organizations. Below them might be entries representing organizational units, people, printers, documents, or just about anything else you can think of.

In addition, LDAP allows you to control which attributes are required and allowed in an entry through the use of a special attribute called objectClass. The values of the objectClass attribute determine the schema rules the entry must obey.

An entry is referenced by its distinguished name, which is constructed by taking the name of the entry itself (called the Relative Distinguished Name or RDN) and concatenating the names of its ancestor entries. For example, the entry for Barbara Jensen in the Internet naming example above has an RDN of uid=babs and a DN of uid=babs,ou=People,dc=example,dc=com.

LDAP defines operations for interrogating and updating the directory. Operations are provided for adding and deleting an entry from the directory, changing an existing entry, and changing the name of an entry. Most of the time, though, LDAP is used to search for information in the directory. The LDAP search operation allows some portion of the directory to be searched for entries that match some criteria specified by a search filter. Information can be requested from each entry that matches the criteria.

Some directory services provide no protection, allowing anyone to see the information. LDAP provides a mechanism for a client to authenticate, or prove its identity to a direct the information the server contains. LDAP also supports data security (integrity and confidentiality) services.

WHAT IS LDAP ?

LDAP, Lightweight Directory Access Protocol, is an Internet protocol that email and other programs use to look up information from a server

Every email program has a personal address book, but how do you look up an address for someone who's never sent you email? How can an organization keep one centralized up-to-date phone book that everybody has access to?

That question led software companies such as Microsoft, IBM, Lotus, and Netscape to support a standard called LDAP. "LDAP-aware" client programs can ask LDAP servers to look up entries in a wide variety of ways. LDAP servers index all the data in their entries, and "filters" may be used to select just the person or group you want, and return just the information you want. For example, here's an LDAP search translated into plain English: "Search for all people located in Chicago whose name contains "Fred" that have an email address. Please return their full name, email, title, and description."

LDAP is not limited to contact information, or even information about people. LDAP is used to look up encryption certificates, pointers to printers and other services on a network, and provide "single signon" where one password for a user is shared between many services. LDAP is appropriate for any kind of directory-like information, where fast lookups and less-frequent updates are the norm.

As a protocol, LDAP does not define how programs work on either the client or server side. It defines the "language" used for client programs to talk to servers (and servers to servers, too). On the client side, a client may be an email program, a printer browser, or an address book. The server may speak only LDAP, or have other methods of sending and receiving data—LDAP may just be an add-on method.

If you have an email program (as opposed to web-based email), it probably supports LDAP. Most LDAP clients can only read from a server. Search abilities of clients (as seen in email programs) vary widely. A few can write or update information, but LDAP does not include security or encryption, so updates usually requre additional protection such as an encrypted SSL connection to the LDAP server.

LDAP also defines: Permissions, set by the administrator to allow only certain people to access the LDAP database, and optionally keep certain data private. Schema: a way to describe the format and attributes of data in the server. For example: a schema entered in an LDAP server might define a "groovyPerson" entry type, which has attributes of "instantMessageAddress", and "coffeeRoastPreference". The normal attributes of name, email address, etc., would be inherited from one of the standard schemas, which are rooted in X.500 (see below).

LDAP was designed at the University of Michigan to adapt a complex enterprise directory system (called X.500) to the modern Internet. X.500 is too complex to support on desktops and over the Internet, so LDAP was created to provide this service "for the rest of us."

LDAP servers exist at three levels: There are big public servers, large organizational servers at universities and corporations, and smaller LDAP servers for workgroups. Most public servers from around year 2000 have disappeared, although directory.verisign.com exists for looking up X.509 certificates. The idea of publicly listing your email address for the world to see, of course, has been crushed by spam. While LDAP didn't bring us the worldwide email address book, it continues to be a popular standard for communicating record-based, directory-like data between programs.

X.500

In X.500, the namespace is explicitly stated and is hierarchical. Such namespaces require

relatively complicated management schemes. The naming model defined in X.500 is i

concerned mainly with the structure of the entries in the namespace, not the way the information is presented to the user. Every entry in a X.500 Directory Information Tree, or DIT, is a collection of attributes, each attribute composed of a type element and one or more value elements.

The X.500 standard defines 17 object classes for directories as a baseline. Being extensible, X.500 directories may include other objects defined by implementors. The 17 basic object classes include:

Alias

Country

Locality

Organization

Organizational Unit

Person

Objects in these object classes are defined by their attributes. Some of the basic 40 attribute types include:

Common Name (CU)

Organization Name (O)

Organizational Unit Name (OU)

Locality Name (L)

Street Address (SA)

State or Province Name (S)

Country (C)

Putting this all together, an unambiguous entry for an addressee would be specified by its distinguished name, say {C=US, 0=Acme, OU=Sales, CN=Fred}

Sample X.500 hierarchy. Starting at the highest level, or Root, we can traverse the tree to successively lower levels, called Country, Organization, and Common Name, for instance.

Applications and users access the directory via a directory user agent, or DUA. A DUA transfers the directory request to a DSA, or Directory System Agent, via DAP. the Directory Access Protocol. The directory itself is composed of one or more DSAs. The DSAs can either communicate among themselves to share directory information or may perform what is called a referral, i.e., direct the DUA to use a specific DSA. Referrals may occur when DSAs are not set up to exchange directory information, perhaps due to lack of interworking agreements between the administrators, or for security reasons.

DIRECTORY STRUCTURE

The protocol accesses LDAP directories, which follow the X.500 model

A directory is a tree of directory entries.

An entry consists of a set of attributes.

An attribute has a name (an attribute type or attribute description) and one or more values. The attributes are defined in a schema.

Each entry has a unique identifier: its Distinguished Name (DN). This consists of its Relative Distinguished Name (RDN) constructed from some attribute(s) in the entry, followed by the parent entry's DN. Think of the DN as a full filename and the RDN as a relative filename in a folder.

Be aware that a DN may change over the lifetime of the entry, for instance, when entries are moved within a tree. To reliably and unambiguously identify entries, a UUID may be provided in the set of the entry's operational attributes.

objectClass: top dn is the name of the entry; it's not an attribute nor part of the entry. "cn=John Doe" is the entry's RDN, and "dc=example,dc=com" is the DN of the parent entry. The other lines show the attributes in the entry. Attribute names are typically mnemonic strings, like "cn" for common name, "dc" for domain component, and "mail" for e-mail address.

A server holds a subtree starting from a specific entry, e.g. "dc=example,dc=com" and its children. Servers may also hold references to other servers, so an attempt to access "ou=Some department.dc=example,dc=com" could return a referral or continuation reference to a server which holds that part of the directory tree. The client can then contact the other server. Some servers also support chaining, which means the server contacts the other server and returns the results to the client.

LDAP rarely defines any ordering: The server may return the values in an attribute, the attributes in an entry, and the entries found by a search operation in any order.

In LDAP, directory entries are arranged in a hierarchical tree-like structure. Traditionally, this structure reflected the geographic and/or organizational boundaries. Entries representing countries appear at the top of the tree. Below them are entries representing states and national organizations. Below them might be entries representing organizational units, people, printers, documents, or just about anything else you can think of.

HOW DOES LDAP WORK?

LDAP directory service is based on a client-server model. One or more LDAP servers contain the data making up the directory information tree (DIT). The client connects to servers and asks it a question. The server responds with an answer and/or with a pointer to where the client can get additional information (typically, another LDAP server). No matter which LDAP server a client connects to, it sees the same view of the directory; 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.

6.SECURITY AND ACCESS CONTROL

LDAP provides for a complex level of access control instances, or ACIs. Because the access can be controlled on the server side, it's much more secure than security methods that work by securing data through client software.

With LDAP ACIs, you can do things like:

Grant users the ability to change their home phone number and home address, while restricting them to read-only access for other data types (such as job title or manager's login).

Grant anyone in the group "HR-admins" the ability to modify any user's information for the following fields: manager, job title, employee ID number, department name, and department number. There would be no write permission to other fields.

Deny read access to anyone attempting to query LDAP for a user's password, while still allowing a user to change his or her own password.

Grant managers read-only permission for the home phone numbers of their direct reports, while denying this privilege to anyone else.

Grant anyone in the group "host-admins" to create, delete, and edit all aspects of host information stored in LDAP.

Via a Web page, allow people in "foobar-sales" to selectively grant or deny themselves read access to subsets of the customer contact database. This would, in turn, allow these individuals to download the customer contact information to their local laptops or to a PDA. (This will be most useful if your sales force automation tool is LDAP-aware.)

Via a Web page, allow any group owner to add or remove any entries from groups they own. For example, this would allow sales managers to grant or remove access for salespeople to modify Web pages. This would allow owners of mail aliases to add and remove users without having to contact IT. Mailing lists designated as "public" could allow users to add or remove themselves (but only themselves) to or from those mail aliases. Restrictions can also be based on IP address or hostname.

OPERAT1ONS

The client gives each request a positive Message ID, and the server response has the same Message ID. The response includes a numeric result code indicating success, some error condition or some other special cases. Before the response, the server may send other messages with other result data - for example each entry found by the Search operation is returned in such a message.

Search and Compare

The Search operation is used to both search for and read entries. Its parameters are:

baseObject - the DN (Distinguished Name) of the entry at which to start the search,

scope - baseObject (search just the named entry, typically used to read one entry), singleLevel (entries immediately below the base DN), or wholeSubtree (the entire subtree starting at the base DN).

filter - how to examine each entry in the scope. E.g. («&(objectClass=person)(|(givenName=:John)(mail=john*))) - search for persons who either have given name John or an e-mail address starting with John.

derefAliases - whether and how to follow alias entries (entries which refer to other entries),

attributes - which attributes to return in result entries.

sizeLimit. timeLimit - max number of entries, and max search time.

typesOnly - return attribute types only, not attribute values.

The server returns the matching entries and maybe continuation references (in any order), followed by the final result with the result code.

The Compare operation takes a DN, an attribute name and an attribute value, and checks if the named entry contains that attribute with that value.

Update operations

Add, Delete, and Modify DN - all require the DN of the entry that is to be changed.

Modify takes a list of attributes to modify and the modifications to each: Delete the attribute or some values, add new values, or replace the current values with the new ones.

Add operations also can have additional attributes and values for those attributes.

Modify DN (move/rename entry) takes the new RDN (Relative Distinguished Name), optionally the new parent's DN, and a flag which says whether to delete the value(s) in the entry which match the old RDN. The server may support renaming of entire directory subtrees.

An update operation is atomic: Other operations will see either the new entry or the old one. On the other hand, LDAP does not define transactions of multiple operations: If you read an entry and then modify it, another client may have updated the entry in the mean time. Servers may implement extensions which support this, however.

ADVANTAGES OF LDAP DIRECTORIES

Perhaps the biggest plus for LDAP is that your company can access the LDAP directory from almost any computing platform, from any one of the increasing number of readily available, LDAP-aware applications. It's also easy to customize your company's internal applications to add LDAP support.

The LDAP protocol is both cross-platform and standards-based, so applications needn't worry about the type of server hosting the directory. In fact, LDAP is finding much wider industry acceptance because of its status as an Internet standard. Vendors are more willing to write LDAP integration into their products because they don't have to worry about what's at the other end. Your LDAP server could be any one of a number of open-source or commercial LDAP directory servers (or perhaps even a DBMS server with an LDAP interface), since interacting with any true LDAP server involves the same protocol, client connection package, and query commands. By contrast, vendors looking to integrate directly with a DBMS usually must tailor their product to work with each database server vendor individually.

Unlike many relational databases, you do not have to pay for either client connection software or for licensing.

Most LDAP servers are simple to install, easily maintained, and easily optimized.

LDAP servers can replicate either some or all of their data via push or pull methods, allowing you to push data to remote offices, to increase security, and so on. The replication technology is built-in and easy to configure. By contrast, many of the big DBMS vendors charge extra for this feature, and it's far more difficult to manage.

LDAP allows you to securely delegate read and modification authority based on your specific needs using ACIs (collectively, an ACL, or Access Control List). For example, your facilities group might be given access to change an employee's location, cube, or office number, but not be allowed to modify entries for any other fields. ACIs can control access depending on who is asking for the data, what data is being asked for, where the data is stored, and other aspects of the record being modified. This is all done through the

LDAP directory directly, so you needn't worry about making security checks at the user application level.

LDAP is particularly useful for storing information that you wish to read from many locations, but update infrequently. For example, your company could store all of the following very efficiently in an LDAP directory:

The company employee phone book and organizational chart

External customer contact information

Infrastructure services information, including NIS maps, email aliases, and so on

Configuration information for distributed software packages

Public certificates and security keys

VERSIONS AND IMPLEMENTATIONS

There are two currently active versions of the LDAP protocol - version 2 (v2) and version 3 (v3). Both are standardised by the IETF. V2 is of interest because of its wide availability and the existence of a public domain implementation. V3 is of interest because of the enhancements it provides over v2.

V2 is defined in RFC 1777 and standard C language client API is defined in RFC 1823. A public domain implementation of both the LDAP API and an LDAP server (SLAPd) is available from the University of Michigan.

V3 is defined in RFC2251. It provides enhancements v2, including:

Improved support for referrals.

Improved security - v3 provides support of various levels of security and authentication mechanisms.

Extensibility - v3 provides a mechanism for the protocol to be extended with out effecting the core of its operation.

Unicode Support

The use of v3 is becoming increasingly common, for example it is implemented in the Netscape LDAP server (which is built on the Michigan work) as well as Microsoft's Active Directory Server.

CONCLUSION

We all use directories of one sort or another every time we use the Internet or our own intranets. LDAP is an extensible, vendor-independent, network protocol standard it supports hardware, software, and network heterogeneity .An LDAP-based directory supports any type of data .You may configure an LDAP-based directory to play essentially any role you wish .The LDAP protocol directly supports various forms of strong security (authentication, privacy, and integrity) technology .We can (and will) use general-purpose directory technology, such as LDAP, to glue together disparate facets of cyberspace, e.g. email, security, white- & yellow-pages directories, collaborative tools, MBone, etc.