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).
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.
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
).
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