Tag Archive : dap

/ dap

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

Social media & sharing icons powered by UltimatelySocial