LDAP

Table of Contents

1. Introduction

The Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral, industry standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network.

A common usage of LDAP is to provide a "single sign on" where one password for a user is shared between many services.

LDAP is based on a simpler subset of the standards contained within the X.500 standard. Because of this relationship, LDAP is sometimes called X.500-lite.

For RFCs about LDAP, please refer to RFC 4510, this RFC provides a road map of the LDAP Technical Specification.

Reference:
http://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol
http://tools.ietf.org/html/rfc4511

1.1. History

Telecommunication companies' understanding of directory requirements were well developed after some 70 years of producing and managing telephone directories. These companies introduced the concept of directory services to information technology and computer networking, their input culminating in the comprehensive X.500 specification, a suite of protocols produced by the International Telecommunication Union (ITU) in the 1980s.

X.500 directory services were traditionally accessed via the X.500 Directory Access Protocol (DAP), which required the Open Systems Interconnection (OSI) protocol stack. LDAP was originally intended to be a lightweight alternative protocol for accessing X.500 directory services through the simpler (and now widespread) TCP/IP protocol stack.

1.2. When should I use LDAP?

Some common examples found throughout the industry are, but not limited to:

  • Machine Authentication
  • User Authentication
  • User/System Groups
  • Address book
  • Organization Representation
  • Asset Tracking
  • Telephony Information Store
  • User resource management
  • E-mail address lookups
  • Application Configuration store
  • PBX Configuration store
  • etc.....

Reference:
http://www.openldap.org/doc/admin24/intro.html

注:LDAP的数据查询效率比较高,高于其数据修改的效率,常应用于“修改需求较少,查询频繁”的应该场景。

2. Protocol overview

A client starts an LDAP session by connecting to an LDAP server, called a Directory System Agent (DSA), by default on TCP and UDP port 389, or on port 636 for LDAPS (LDAP over SSL).

The client then sends an operation request to the server, and the server sends responses in return. With some exceptions, the client does not need to wait for a response before sending the next request, and the server may send the responses in any order. All information is transmitted using Basic Encoding Rules (BER).

3. LDIF

The LDAP Data Interchange Format (LDIF) is a standard plain text data interchange format for representing LDAP directory content and update requests. LDIF conveys directory content as a set of records, one record for each object (or entry). It also represents update requests, such as Add, Modify, Delete, and Rename, as a set of records, one record for each update request.

This later version of LDIF is called version 1 and is formally specified in RFC 2849.

Reference: http://en.wikipedia.org/wiki/LDAP_Data_Interchange_Format

3.1. LDIF format

The basic form of a directory entry represented in LDIF is as follows:

dn: distinguished_name
objectClass: object_class
objectClass: object_class
...
attribute_type[;subtype]:attribute_value
...

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 the full file path and the RDN as its relative filename in its parent folder (e.g. if /foo/bar/myfile.txt were the DN, then myfile.txt would be the RDN).

Table 1: LDIF Field
Field Definition
dn: distinguished_name Specifies the distinguished name for the entry.
objectClass: object_class Specifies an object class to use with this entry.
attribute_type Specifies a descriptive attribute to use with the entry. The attribute should be defined in the schema.
subtype Specifies a subtype.
attribute_value Specifies the attribute value to be used with the attribute type.

3.1.1. Common attribute type

Some attribute type are used most ofen.

Table 2: attribute type abbreviations
Attribute Type Abbreviation
Country Name C
Organization Name O
Organizational Unit Name OU
Common Name CN
Domain Component DC
State or Province Name S
Street Address SA

For example www.google.com would be written as DC=www,DC=google,DC=com

3.2. Examples of LDIF

An simple LDIF file with two entries:

dn: cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Barbara Jensen
cn: Barbara J Jensen
cn: Babs Jensen
sn: Jensen
uid: bjensen
telephonenumber: +1 408 555 1212
description: A big sailing fan.

dn: cn=Bjorn Jensen, ou=Accounting, dc=airius, dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Bjorn Jensen
sn: Jensen
telephonenumber: +1 408 555 1212

4. OpenDS

OpenDS is an open source LDAP directory service written from the ground up using 100% pure java.

Reference:
Sun OpenDS Standard Edition 2.2: http://docs.oracle.com/cd/E19476-01/

4.1. Install and setup

OpenDS 2.2 Installation Guide: https://java.net/projects/opends/pages/2_2_InstallationGuide

Firstly, you need download and extract it.

$ wget http://java.net/downloads/opends/promoted-builds/2.2.1/OpenDS-2.2.1.zip
$ unzip OpenDS-2.2.1.zip
$ cd OpenDS-2.2.1

Type setup with the --cli option to launch the install in interactive mode.

$ ./setup --cli

OpenDS Directory Server 2.2.1
Please wait while the setup program initializes...

What would you like to use as the initial root user DN for the Directory
Server? [cn=Directory Manager]:
Please provide the password to use for the initial root user: 12345
Please re-enter the password for confirmation: 12345

On which port would you like the Directory Server to accept connections from
LDAP clients? [1389]:

On which port would you like the Administration Connector to accept
connections? [4444]: 4455

What do you wish to use as the base DN for the directory data?
[dc=example,dc=com]:
Options for populating the database:

    1)  Only create the base entry
    2)  Leave the database empty
    3)  Import data from an LDIF file
    4)  Load automatically-generated sample data

Enter choice [1]: 2

Do you want to enable SSL? (yes / no) [no]:

Do you want to enable Start TLS? (yes / no) [no]:

Do you want to start the server when the configuration is completed? (yes /
no) [yes]:


Setup Summary
=============
LDAP Listener Port:            1389
Administration Connector Port: 4455
LDAP Secure Access:            disabled
Root User DN:                  cn=Directory Manager
Directory Data:                Create New Base DN dc=example,dc=com.
                               Base DN Data: Leave Database Empty

Start Server when the configuration is completed


What would you like to do?

    1)  Setup the server with the parameters above
    2)  Provide the setup parameters again
    3)  Cancel the setup

Enter choice [1]: 1

Configuring Directory Server ..... Done.
Starting Directory Server ...... Done.

See /tmp/opends-setup-2106862444868985347.log for a detailed log of this operation.

After above, OpenDS server is started. You can run ./bin/status to check its status, run ./bin/stop-ds to stop it, run ./bin/start-ds to start it again.

4.2. Import LDIF data

LDIF file can be imported via OpenDS Control Panel (./bin/control-panel).

ldap_OpenDS_Control_Panel.png

Figure 1: OpenDS Control Panel

LDIF file can be also imported by command line utility ./bin/import-ldif.

Reference: https://java.net/projects/opends/pages/2_2_ImportingDataUsingImportLdif

4.3. OpenDS built-in standard schemas

OpenDS includes some standard schemas.

$ ls ./config/schema/
00-core.ldif       03-rfc2713.ldif  03-rfc3112.ldif     05-rfc4876.ldif
01-pwpolicy.ldif   03-rfc2714.ldif  03-rfc3712.ldif     05-solaris.ldif
02-config.ldif     03-rfc2739.ldif  03-uddiv3.ldif      06-compat.ldif
03-changelog.ldif  03-rfc2926.ldif  04-rfc2307bis.ldif

rfc2713: Schema for Representing Java(tm) Objects in an LDAP Directory
rfc2714: Schema for Representing CORBA Object References in an LDAP Directory
rfc2739: Calendar Attributes for vCard and LDAP
rfc2926: Conversion of LDAP Schemas to and from SLP Templates
rfc3112: LDAP Authentication Password Schema
rfc3712: Lightweight Directory Access Protocol (LDAP): Schema for Printer Services
rfc2307: An Approach for Using LDAP as a Network Information Service
rfc4876: A Configuration Profile Schema for LDAP-Based Agents

4.4. OpenDJ

OpenDJ began after the acquisition of Sun Microsystems by Oracle. At that time, Oracle announced that Sun OpenDS Standard Edition was not seen as a strategic product, although the investment on the OpenDS source code would continue.

OpenDJ began as a fork of the OpenDS code base and is now the main trunk developed and maintained by ForgeRock.

4.4.1. OpenDJ built-in standard schemas

OpenDJ includes more built-in schemas than OpenDS.

Reference:
http://opendj.forgerock.org/opendj-server/doc/bootstrap/admin-guide/#standard-schema

Author: cig01

Created: <2015-05-27 Wed>

Last updated: <2016-07-09 Sat>

Creator: Emacs 27.1 (Org mode 9.4)