****
*
*
*
*







*
*
                                      
*
*
Windows Server



    

About Lightweight Directory Access Protocol    

*
*

*
*

About Lightweight Directory Access Protocol


Categories:


Tags:


Apr
20

About Lightweight Directory Access Protocol

 

The Lightweight Directory Access Protocol (LDAP) API provides a mechanism for connecting to, searching, and modifying Internet directories.

The LDAP guide documents the functions and data structures that constitute the LDAP 3 API draft Internet Standard as proposed in RFC 2251, as well as several Microsoft extensions to the LDAP API. The reference is intended for experienced C programmers and can be used to enable new or existing applications to connect to, search, and update LDAP servers.

 

Introduction to Lightweight Directory Access Protocol (LDAP)

support.microsoft.com/kb/196455

SUMMARY

 

To understand Lightweight Directory Access Protocol (LDAP) better, let's discuss X.500 and Directory Access Protocol (DAP).

In X.500, the Directory System Agent (DSA) is the database in which directory information is stored. This database is hierarchical in form, designed to provide fast and efficient search and retrieval.

The Directory User Agent (DUA) provides functionality that can be implemented in all sorts of user interfaces through dedicated DUA clients, Web server gateways, or e-mail applications.

The Directory Access Protocol (DAP) is a protocol used in X.500 Directory Services for controlling communications between the DUA and DSA agents. The agents represent the user or program and the directory, respectively.

The X.500 Directory Services are application-layer processes. Directory services can be used to provide global, unified naming service for all elements in a network, translate between network names and addresses, provide descriptions of objects in a directory, and provide unique names for all objects in the Directory. These X.500 objects are hierarchical with different levels for each category of information, such as country, state, and city, organization.

These objects may be files (as in a file system directory listing), network entities (as in a network naming services such as Novell's NDS), or other types of entities.

A lightweight protocol is any of a class of protocols designed for use on high-speed internetworks. High-Speed Transport Protocol (HSTP), Xpress Transfer Protocol (XTP), and Lightweight Directory Access Protocol (LDAP) are examples.

Lightweight protocols combine routing and transport services in a more streamlined fashion than do traditional network and transport layer protocols. This makes it possible to transmit more efficiently over high- speed networks, such as ATM or FDDI, and media, such as fiber-optic cable.

Lightweight protocols use various measures and refinements to streamline and speed up transmissions, such as using connection-oriented transmissions, such as (TCP/IP) and a fixed header and trailer size to save the overhead of transmitting a destination address with each packet.

Lightweight Directory Access Protocol (LDAP) is a subset of the X.500 protocol. LDAP clients are, therefore, smaller, faster, and easier to implement than are X.500 clients. LDAP is vendor-independent and works with, but does not require, X.500.

Contrary to X.500, LDAP supports TCP/IP, which is necessary for any type of Internet access. LDAP is an open protocol, and applications are independent of the of server platform hosting the directory.

The Active Directory is not an X.500 directory. Instead, it uses LDAP as the access protocol and supports the X.500 information model without requiring systems to host the entire X.500 overhead. The result is the high level of interoperability required for administering real-world, heterogeneous networks.

The Active Directory supports access via the LDAP protocol from any LDAP- enabled client. LDAP names are less intuitive than Internet names, but the complexity of LDAP naming is usually hidden within an application. LDAP names use the X.500 naming convention called "Attributed Naming."

An LDAP URL names the server holding Active Directory services and the Attributed Name of the object. For example:

LDAP://SomeServer.Myco.Com/CN=jamessmith,CN=Sys,CN=Product,CN =Division,DC=myco,DC=domain-controller

                                                

LDAP C API (RFC 1823) is an informational RFC that is the de facto standard in C programming for LDAP applications.

By combining the best of the DNS and X.500 naming standards, LDAP, other key protocols and a rich set of APIs, the Active Directory allows a single point of administration for all resources, including: files, peripheral devices, host connections, databases, Web access, users, arbitrary other objects, services, and network resources.

 

support.microsoft.com/kb/196455

 

Differences between LDAP 2 and LDAP 3

LDAP 3 defines a number of improvements that allow a more efficient implementation of the Internet directory user agent access model. These changes include:

·         Use of UTF-8 for all text string attributes to support extended character sets.

·         Operational attributes that the directory maintains for its own use; for example, to log the date and time when another attribute has been modified.

·         Referrals allow a server to direct a client to another server that may have the data that the client requested.

·         Schema publishing with the directory, allowing a client to discover the object classes and attributes that a server supports.

·         Extended searching operations to allow paging and sorting of results, and client-defined searching and sorting controls.

·         Stronger security through an SASL-based authentication mechanism.

·         Extended operations, providing additional features without changing the protocol version.

LDAP 3 is compatible with LDAP 2. An LDAP 2 client can connect to an LDAP 3 server (this is a requirement of an LDAP 3 server). However, an LDAP 3 server can choose not to talk to an LDAP 2 client if LDAP 3 features are critical to its application.

 

What is LDAP?

The Lightweight Directory Access Protocol (LDAP) is a directory service protocol that runs directly over the TCP/IP stack. The information model (both for data and namespaces) of LDAP is similar to that of the X.500 OSI directory service, but with fewer features and lower resource requirements than X.500. Unlike most other Internet protocols, LDAP has an associated API that simplifies writing Internet directory service applications. The LDAP API is applicable to directory management and browser applications that do not have directory service support as their primary function. LDAP cannot create directories or specify how a directory service operates.

The LDAP Directory Service Model

The LDAP directory service is based on a client-server model. One or more LDAP servers contain the data making up the LDAP directory tree. An LDAP client connects to an LDAP server and requests information or performs an operation. The server performs the operation or provides the information, or refers the client to another LDAP server that may be able to provide the information. Regardless of the LDAP server to which a client connects, the client sees the same view of the directory; a name presented to one LDAP server references the same entry the name would at another LDAP server. This is an important feature of a global directory service such as LDAP.

It is important to remember that LDAP is designed to allow speedy and efficient access to an existing directory. Its streamlined (lightweight) design prevents it from being able to create a directory or specify how the directory service itself operates.

This section covers the following topics:

·         What is a Directory Service?

·         Directory Entries

·         Accessing Directory Information

What is a Directory Service?

A directory is similar to a database, but typically contains more descriptive, attribute-based data; that is, data read more often than it is written. Also, a directory contains data that is concise and strictly relevant to an entry. By contrast, a database contains large amounts of data for each entry that may, or may not, be directly relevant to the entry. For this reason, a directory does not usually implement the transaction or roll-back schemes that regular databases require. If they are permitted at all, directory updates are typically simple all-or-nothing changes. Directories are tuned to respond quickly to high-volume lookup or search operations.

A lookup is an operation that targets a specific, unique entry, such as a domain name. A search is an operation that targets data common to multiple entries, such as the data collected, by an Internet search engine, about a topic.

Directories may replicate data widely to increase availability and reliability, and thus reduce response time. When directory data is replicated, temporary inconsistencies between the replicas may be acceptable — as long as all the replicas are updated eventually — depending on the particular role of the directory. These applications can be defined only by the specific directory design and are irrelevant to the deployment of LDAP.

There are many methods used to provide a directory service. Different methods allow various types of data to be stored in a directory, require the data to be referenced, queried, updated, protected, and so on. Some directory services are local, providing service to a restricted context, for example, the finger service on a single computer. Other services are global, providing service to a much broader context, for example, the entire Internet. Global services are usually distributed, meaning that the data they contain is shared across many computers which cooperate to provide the directory service. Typically, a global service defines a uniform namespace, which gives the same view of the data regardless of where the computer is in relation to the data.

 

Directory Entries

An LDAP directory is a collection of entries, which consist of one or more attributes each. Each attribute has one or more values and a type that determines the kind of information the values can hold and how those values behave during directory operations. The attribute types and object classes defined for LDAP clients are described in RFC 4510.

The entries are arranged hierarchically in a tree that is structured geographically and organizationally. Global entries, such as countries/regions, reside at the top of the tree, followed by state or national organizations, then organizational units, people, devices, or anything else that might be represented in a directory.

A directory entry is represented by its entry name, or relative distinguished name (RDN), and by its distinguished name (DN). The DN uniquely identifies each entry on a global level, and is derived by concatenating the RDN of an entry with the RDN of each of its ancestor entries.

 

Accessing Directory Information

The LDAP API provides functions that allow LDAP client applications to search for and retrieve information from an LDAP directory server, as well as functions for modifying directory entries, where such modifications are permitted. There are also functions that provide access control for servers, by allowing clients to authenticate themselves. The topics in the following sections describe these functions in greater detail.

LDAP and ADSI

Microsoft provides the Active Directory Service Interfaces (ADSI) for developing client-side directory service applications. ADSI consists of a directory service model and a set of COM interfaces. These interfaces enable development of network directory service access applications for computers running on Windows 2000 Professional, Windows NT Workstation, Windows 98 or Windows 95. ADSI uses an LDAP provider to communicate with Active Directory. ADSI can also access Novell NetWare Directory Services. ADSI can communicate with various directory services by using their native providers.

For more information about ADSI, see Active Directory Service Interfaces.

 

Active Directory Service Interfaces

Purpose

Active Directory Service Interfaces (ADSI) is a set of COM interfaces used to access the features of directory services from different network providers. ADSI is used in a distributed computing environment to present a single set of directory service interfaces for managing network resources. Administrators and developers can use ADSI services to enumerate and manage the resources in a directory service, no matter which network environment contains the resource.

ADSI enables common administrative tasks, such as adding new users, managing printers, and locating resources in a distributed computing environment.

Where applicable

Network Administrators can use ADSI to automate common tasks, such as adding users and groups, managing printers, and setting permissions on network resources.

Independent Software Vendors and end-user developers can use ADSI to "directory enable" their products and applications. Services can publish themselves in a directory, clients can use the directory to find the services, and both can use the directory to find and manipulate other objects of interest. Because Active Directory Service Interfaces are independent of the underlying directory service(s), directory-enabled products and applications can operate successfully in multiple network and directory environments.

Developer audience

You can write ADSI client applications in many languages. For most administrative tasks, ADSI defines interfaces and objects accessible from Automation-compliant languages like Microsoft Visual Basic, Microsoft Visual Basic Scripting Edition (VBScript), and Java to the more performance and efficiency-conscious languages such as C and C++. A good foundation in COM programming is useful to the ADSI programmer.

Run-time requirements

Active Directory runs on Windows Server 2008, Microsoft Windows Server 2003, and Windows 2000 Server domain controllers. However, client applications using ADSI may be written and run on Windows Vista, Windows XP, Windows 2000, Windows NT 4.0, Windows 98, and Windows 95. In addition, developers will want the Platform Software Development Kit (SDK), also available on the MSDN website. To investigate the contents of Active Directory, use the Active Directory Users and Computers MMC snap-in. This snap-in replaces the Adsvw tool that was available for previous versions of Windows.

In this section

Topic

Description

About ADSI

General information about ADSI.

Using ADSI

Programmer's Guide to using ADSI.

ADSI Quick-start Tutorials

Using ADSI with Automation to manage directories.

ADSI Reference

Documentation of ADSI interfaces and methods.

 

Related topics

The Component Object Model

COM Clients and Servers

Active Directory Domain Services

 

 

 

 

 



No TrackBacks

TrackBack URL: http://www.skar.us/site/mt-tb.cgi/3180

Leave a comment








*
*

ebhakt
Author Bio          ★★★★★

Author Name:         ebhakt
Author Location:    India
Author Rank:          Writer
Author Status:        
The Green leave stands!!


*
*
*
*
****



*****



    Desktop
  • eBooks
  • Games
  • Softwares
  • Tools
  • Tweaks
  • Wallpapers
  • Warez
    PDA
  • Games
  • Tools
  • Wallpapers
    System Administration
  • dll Center
  • Scripts
  • Tools
  • .extensions database
  • Write-up
    more...
  • Download Database
  • Jobs
  • Lists
  • Polls
  • Glossary

01000011 01110010 01100001 01100011 01101011 01111010 01101000 01100001 01100011 01101011