Tag Archive : ldap

/ ldap

Installing OpenLDAP 2.4 on Debian Squeeze

December 9, 2015 | Article | No Comments

OpenLDAP is one of software that implement Lightweight Directory Access Protocol (LDAP).

In this article we will do installation of OpenLDAP on Debian. Technically say, we will install OpenLDAP 2.4 which is provided by Debian repository. The benefits of LDAP, and OpenLDAP specifically, is we can achieve Single Sign On to other services such as FTP, SSH, etc. The LDAP will act as back-end which authenticates user.

OpenLDAP consists of some packages, but basically we can be categorized them as three categories: main application (daemon), supporting application, and packages for extending LDAP functionalities (as well as libraries for other applications).

In this article we will use Debian 6.0.7 (Squeeze) for amd64 with following packages:

  1. slapd
  2. ldap-utils
  3. db4.8-util

The method we use here should be applicable to x86 (32 bit) Debian as well.

Things to Know

In previous version of OpenLDAP, all server configuration used to be stored on a single file, /etc/ldap/slapd.conf. The configuration is in plain text and quite readable format.

Starting from version 2.4, the configuration now stored inside the LDAP tree, rather than on slapd.conf.

If you need to migrate from the old format to new format, you can check this article.

The main advantage of this approach is ability to update configuration while the server is still running. This is good for enterprise grade applications but also has drawback. The drawback is that we have to use the poorly readable LDIF syntax, just to be able to create a new database, define the database admin, configure ACLs, etc.

In this article, we will only do fresh installation of OpenLDAP 2.4 on Debian Squeeze look things that change on this version. In this version, understanding about LDIF Is required and encouraged. We will see why in the later section.

Obtain the Materials

All the packages can be downloaded and installed from repositories. Use following command to install them:

apt-get install slapd ldap-utils db4.8-util

These are the minimum packages we need: slapd (as a daemon), ldap-utils (as utilities), and db4.8-util (as back-end database).

LDAP is a protocol and it is not focusing on actual storage processing. The back-end for that can be berkeley DB, MySQL, PostGreSQL, etc. In this case we use db4.8 or Berkeley DB.

On Installation

When installing OpenLDAP we will be prompted by several questions. You can adjust the answer with your conditions. We can skip that and configure them later by invoking:

dpkg-reconfigure slapd

In general, on installation progress will ask you about these information:

  1. Administrator password for this LDAP package. This is not password for the system, but the password used for manage or administrate LDAP.
  2. Server host, can DNS domain name (fully qualified domain name) or IP Address
  3. Organization name.
  4. Database backed to use.
  5. LDAP version (v2 or v3)
  6. Distinguish name (dn) of the machine.
  7. DN used as administrator.

When creating a base distinguish name (base DN), the easiest way is using FQDN (URL) as a base DN. For example: from xathrya.id we can create a base DN as following: dc=xathrya,dc=id

Another we should prepare is the distinguish name used for administration. For example: cn=master,dc=xathrya,dc=id

At this point, we have successfully install OpenLDAP on our Debian machine.

Listing LDAP configuration

As stated, OpenLDAP 2.4 use different configuration location and format. To see the running configuration, use one of this command:

slapcat -b cn=config

# or

ldapsearch -LLQY EXTERNAL -H ldapi:/// -b cn=config

Adjust LDAP Configuration

To modify a configuration using a .ldif file, use following command:

ldapmodify -Y EXTERNAL -H ldapi:// -f <ldif file>.ldif

A configuration can be written on LDIF file. This snippet can be read as an example:

# Increase log level
dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: stats

# Add indexes
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: uid eq
-

add: oldDbIndex
olcDbIndex: cn eq
-

add: olcDbIndex
olcDbIndex: ou eq
-

add: olcDbIndex
olcDbIndex: dc eq

That example will modify log level and add new indexes on attributes.

Database Definition

In this new format, database definition is performed through LDIF file.

Create a directory on filesystem to store all files related to this database. This directory should be separated from main / root of ldap directory

mkdir /var/lib/ldap-database
chown openldap.openldap /var/lib/ldap-database

Next, load create an LDIF file, let call it as new-db.ldif. Adjust it with your setting:

dn: olcDatabase={2}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {2}hdb
olcSuffix: dc=xathrya,dc=id
olcDbDirectory: /var/lib/ldap-database
olcRootDN: cn=Manager,dc=xathrya,dc=id
olcRootPW: secret
olcDbIndex: cn,sn,uid pres,eq,approx,sub
olcDbIndex: objectClass eq
olcAccess: to attrs=userPassword
  by self write
  by anonymous auth
  by dn.base="cn=Admin,dc=xathrya,dc=id" write
  by * none
olcAccess: to *
  by self write
  by dn.base="cn=Admin,dc=xathrya,dc=id" write
  by * read

Then load it with following command:

ldapadd -Y EXTERNAL -H ldapi:/// -f new-db.ldif

In a LDAP tree, we do not have ordered elements. This is why we have this optional {n} syntax which allows database ordering.

LDAP Scheme

December 9, 2015 | Article | No Comments

To declare a directory or an object, LDAP used scheme system.

Scheme or schema is simply a packaging unit. It is a collection of valid object class and attributes. The attributes are declared and registered through LDAP system and can be widely known by it. Every object class and attributes must be defined inside of scheme. An attribute defined in one schema can be used by an objectclass defined in another schema.

It is wise to say scheme is like a blueprint of object. When we want to instantiate / create an object, we should refer to the blueprint. Object defined outside of blueprint won’t be recognized / not accepted.

Even after declaring objects and attributes inside of scheme, the scheme won’t be used unless it is included in the configuration file.

Schema decides what information are stored in LDAP. Therefore, we can’t carelessly stored all data in LDAP. All object class and attributes should be defined inside of schema, including connection between object classes and attributes.

Each schema can only accommodate object class and attributes for specific purpose. For example: a schema samba is a scheme to accommodate information needed by samba.

On default setting, LDAP (OpenLDAP) has included four schemes ready to use. Those schemes are:

core.schema
Core function of OpenLDAP
cosine.schema
Schema for Cosine and x.500
nis.schema
Specific schema for access NIS
interorgperson.schema
Schema for internet organization person entry.

All schemas are usually written as plain text which have .schema extension.

To write a schema, an understanding of object class and attributes should be acquired which will be discussed in other article.

Here is the relation of schema, object class, and attributes:

ldap-object-hierarchy

LDAP Attributes

December 9, 2015 | Uncategorized | No Comments

Attribute is the atomic structure of schema and a member of object class. Attribute typically contain data.

Every attribute is included in one or more object classes. Therefore, some object class might have same attribute. Once defined in a schema, it can also be used by any object class.

Attribute has a name as identifier. The name is used for identifying the attribute, distinguish one attribute from other attribute. Attribute should be unique. Attribute is also a container for value(s). It is an entry of which value is stored. The value could be a single-value or multi-value.

To define an attribute, we have following syntax:

attributetype whsp "(" whsp
numericoid whsp
[ "NAME" qdescrs ]
[ "DESC" qdescrs ]
[ "OBSOLETE" whsp ]
[ "SUP" woid ]
[ "EQUALITY" woid ]
[ "ORDERING" woid ]
[ "SUBSTR" woid ]
[ "SYNTAX" whsp noidlen whsp ]
[ "SINGLE-VALUE" whsp ]
[ "COLLECTIVE" whsp ]
[ "NO-USER-NOTIFICATION" whsp ]
[ "USAGE" whsp AttributeUsage ]
whsp ")"

In each attribute, a numericoid should be given. This is the OID Used by LDAP system and should be uniform.

Let’s dive deeper into the meaning of each syntax:

NAME
Defined the attribute’s name. This name should be unique globally (in system). The name is a pair of two string, and written inside of parenthesis. The first string is alias which usually abbreaviation of the second string. The second string is the ful string. If the string is composed of two or more word, it should be trimmed so there is no whitespace.
DESC
Description for this attribute.
OBSOLETE
Optional. When this attribute is defined as obsolete, LDAP is informed that the attribute is obsoleted and should not be used.
SUP
Optional. Define parent of this attribute.
EQUALITY caseIgnorematch
Define the properties of this attribute where a searching operation is used over this attribute.A searching can be done in two mode: case sensitive and case insensitive. If a case insensitive mode is desired, we have to declared the attribute using matchingRule caseIgnoreMatch. matchingRule is a special purpose attribute for searching.
More information about LDAP searching could be read from corresponding article.
ORDERING ‘matchingRule’
Used for matching rules of attributes combination.
SUBSTR ‘caseIgnoreSubstringMatch’
Define properties of this attribute when used in searching operation based on substring. The searching operation can be done in case insensitive or using matchingRule caseIgnoreSubstringMatch.
SYNTAX
Define oid of this attribute.
SINGLE-VALUE
Define whether this attribute can be used once in object class. For example: an attribute PersonName should only used once within a class. When not defined as SINGLE-VALUE, LDAP will automatically infer that the attribute can be used multiple times.

Now let’s define a simple attribute as an example:

attributetype ( 2.3.4.5 NAME ( 'cn' 'commonName' ) SUP name )

Here is the relation of attributes with schema and object class

ldap-object-hierarchy

LDAP Object Class

December 9, 2015 | Article | No Comments

The concept of object here is similar to concept of object in Object Oriented Programming.

In Lightweight Directory Access Protocol (LDAP), object class is a set of attributes.It is defined inside a schema and may be organized in a hierarchy. This concept is similar to object in real world, where object in real world might consists of other elements. For example: a car is assembly of tire, wheel, chassis, engine, etc. An object class is not different from that. An object in LDAP is a collection of attributes.

When we said a class (in object class) we refer to the design / blueprint. We can create as many car as we want from a blueprint with same specification, same power, same dimension, everything same. And also object class is. An object class is a blueprint to create an object we can use in LDAP. When an object is created, it is an instance of an object class.

Object class is hierarchical. It can inherit attributes from its parent. In real world, we can say that an object motorcycle is derived from a bicycle. It is a bike with an engine. In LDAP, we can see that object class InetOrgPerson is a descendant of object class organizationalPerson and inherit avery attributes organizationalPerson has.

To define an object class, we follow this syntax:

objectclass whsp "(" whsp numericoid whsp
[ "NAME" qdescrs ]
[ "DESC" qdescrs ]
[ "OBSOLETE" whsp ]
[ "SUP" oids ]
[ ( "ABSTRACT" / "STRUCTURAL" / AUXILIARY" ) whsp ]
[ "MUST" oids ]
[ "MAY" oids ]
whsp ")"

An object class is declared by a keyword objectclass and followed by a whitespace (whsp) and a numericoid or Organizational Identification number. This number should be unique globally if we want to build an enterprise system. The numericoid is used for identifying object class, attributes, syntax, matching rules, etc. The numericoid is assigned by IANA. If you want to build an enterprise level and a production machine, please acquired one. If you just want to experiment, you can do that in private network with any numericoid.

Let’s dive deeper into the object class declaration:

NAME
Defined the object class’ name. This name should be unique globally.
DESC
Description for this object class.
OBSOLETE
Optional. When this object class is defined as obsolete, LDAP is informed that the object class is obsoleted and should not be used.
SUP
Optional. Define parent / super class of this object class. The object class given in this argument will act as parent and the newly create object class will inherit all properties from the parent object class.
ABSTRACT / STRUCTURAL / AUXILIARY
Define types of object class.
An abstract class defining an abstract class / non existing class / class that should not be exists. Well this is ambiguous, but it means the abstract class can not be instantiated in DIT.
A structural class defining a common node in hierarchy. The class can be instantiated as a node in LDAP tree (DIT).
An auxiliary class is an object with attributes but unlike structural class, it cannot create its own instance in DIT. This object should be used as auxiliary of complement of structural class.
MUST
Define attributes that should be exists if we want to use this object. The given object should be written as a list separated by dollar sign $.
MAY
Define optional attributes that can exists in this class.

Let see one example:

objectclass ( 2.3.4.5 NAME 'country' SUP top STRUCTURAL
MUST c
MAY ( searchGuide $ description ) )

We can write them cascade like in the example, or as one long line.

In above example, we define an object class with OID 2.3.4.5. This object class’ name is country having top as a parent. This class is structural. An attribute countryName or c should declared before using this object. Attribute searchGuide is an optional.

Here is the relation of object class with schema and attributes:

ldap-object-hierarchy

What is LDAP?

December 5, 2015 | Article | No Comments

Lightweight Directory Access Protocol (LDAP) is an application protocol for accessing and maintaining distributed directory information services overn an Internet Protocol Network. The Directory services may provide any organized set of records, often with hirearchical structure, such as corporate email directory. Similarly, a telephone directory is a list of subscribers with an address and a phone number. Another example can be found on college where each student has unique student-ID and sort of informations.

LDAP is specified in a series of Internet Engineering Task Force (IETF) Standard Track RFC, using description language ASN.1. The latest specification is version 3 and published as RFC 4511.

Origins and Early Development

Telecommunication companies’ undestanding of directory requirements was well developed after some 70 years of producing and managing telephone directories. These companies then introduced the concept of the directory services to IT-based and culminating in the comprehensive X.500 specification, a suit of protocols produced by the International Telecommunication Union (ITU) in the 1980s.

X.500 directory services were traditionally accessed via X.500 Directory Access Protocol (DAP), which required the OSI protocol stack. LDAP was originally intended to be a lightweight alternative protocol for accessing X.500 directory services through the simpler TCP/IP protocol stack. This model of directory access was borrowed from the DIXIE and Directory Assistance Service protocols.

The protocol was originally created by Tim Howes of the University of Michigan, Steve Kille of Isode Limited, Collin Robbins of Nexor, and Wengyik Yeong of Performance Systems International.

In the early times, LDAP was known as Lightweight Directory Browsing Protocol, or LDBP. It was then renamed with the expansion of the scope of the protocol beyond directory browsing and searching, to include directory update funtions. The name Lightweight was given as it was not as network intensive as its DAP predecessor and thus was more easily implemented over the internet due to its relatively modest bandwidth usage.

LDAP has influenced subsequenct Internet protocols, including later version of X.500, XML Enabled Directory (XED), Directory Service Markup Language (DSML), Service Provisioning Markup Language (SPML), and the Service Location Protocol (SLP).

The Protocols

A client starts an LDAP session by connecting to an LDAP server, called a Directory System Agent (DSA), by default on TCP port 389. 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).

The client may request the following operations:

  • StartTLS — use the LDAPv3 Transport Layer Security (TLS) extension for a secure connection
  • Bind — authenticate and specify LDAP protocol version
  • Search — search for and/or retrieve directory entries
  • Compare — test if a named entry contains a given attribute value
  • Add a new entry
  • Delete an entry
  • Modify an entry
  • Modify Distinguished Name (DN) — move or rename an entry
  • Abandon — abort a previous request
  • Extended Operation — generic operation used to define other operations
  • Unbind — close the connection (not the inverse of Bind)

In addition the server may send “Unsolicited Notifications” that are not responses to any request, e.g. before the connection is timed out.

A common alternative method of securing LDAP communication is using an SSL tunnel. This is denoted in LDAP URLs by using the URL scheme “ldaps”. The default port for LDAP over SSL is 636. The use of LDAP over SSL was common in LDAP Version 2 (LDAPv2) but it was never standardized in any formal specification. This usage has been deprecated along with LDAPv2, which was officially retired in 2003

Directory Structure

The protocol provides an interface with directories which follow the 1993 edition of the X.500 model:

  • 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 (see below).
  • 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).

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 might be provided in the set of the entry’s operational attributes.

An entry can look like this when represented in LDAP Data Interchange Format (LDIF) (while LDAP itself is a binary protocol):

dn: cn=John Doe,dc=example,dc=com
cn: John Doe
givenName: John
sn: Doe
telephoneNumber: +1 888 555 6789
telephoneNumber: +1 888 555 1232
mail: [email protected]
manager: cn=Barbara Doe,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top

dn” is the distinguished name of the entry; it is neither an attribute nor a part of the entry. “cn=John Doe” is the entry’s RDN (Relative Distinguished Name), and “dc=example,dc=com” is the DN of the parent entry, where “dc” denotes ‘Domain Component’. The other lines show the attributes in the entry. Attribute names are typically mnemonic strings, like “cn” for common name, “dc” for domain component, “mail” for e-mail address, and “sn” for surname.

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=department,dc=example,dc=com” could return a referral or continuation reference to a server that 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 of an attribute, the attributes in an entry, and the entries found by a search operation in any order. This follows from the formal definitions – an entry is defined as a set of attributes, and an attribute is a set of values, and sets need not be ordered.

Terminologies

Most people said, LDAP is one of many protocol having many confusing terminologies. One should understand LDAP terminologies to operate LDAP well. The terminologies might many, but it should be obvious when we have know it.

Light Directory Access Protocol, as the name said, is consists of directories. Directories are collection of object having each attributes composed in hierarchical form. They are represented as nodes of the tree, just like directory in UNIX.

Data or informations are stored inside of hierarchical directories, forming a tree. This tree is referred as Data Information Tree (DIT). In topmost level / the root, there is an object called as suffix and others object of the tree are stored inside of suffix.

Every entry in the tree have only one parent object / entry. Every entry might not have child entry or it can also has one or more entries as children. Each entry which has the same parent is called siblings.

Every entry is an instance of one or more object class. Object class is can have one or more attributes. Attribute has name and value. The concept is similar to object in real world.

Social media & sharing icons powered by UltimatelySocial