Posted inLDAP

Openldap Tutorial – Practical Realtime Implementation and Integration

No Comments
Openldap Tutorial
This entry is part 1 of 8 in the series Openldap Tutorial
wp-content/uploads/2017/09/open-ldap-logo-180x180-1.png
Openldap Tutorial

Openldap Tutorial

This Openldap Tutorial will touch the basics of  LDAP  and provide in depth coverage on practical implementation and integration of openLDAP with realtime examples. The examples will include integrating applications and Servers with a directory service ( openLDAP ) and customisations to meet requirements.

 

Note: LDAP is a vast topic. To better understand this article, some prior reading about LDAP is recommended. Though the article is written in a way that is easy to understand , we highly encourage you to make use of this site which deep dives into nuances of LDAP.  The aim of this article is to provide you with a complete end to end implementation and integration process of LDAP  taking away all the complexities that you might come across when doing it on your own.

 

What is LDAP ?

LDAP stands for Lightweight Directory Access Protocol. It is an application protocol used over an IP network to manage and access the distributed directory information service. For the sake of understanding, we can consider the term Distributed Directory Information service similar to telephone directory that we used in old days to get details about a user. 

LDAP is not limited to contact information, or even information about people. LDAP is used to look up encryption certificates, pointers to printers and other services on a network, and provide “single sign-on” where one password for a user is shared between many services. LDAP is appropriate for any kind of directory-like information, where fast lookups and less-frequent updates are the norm.

 

What is openLDAP ?

OpenLDAP is an opensource implementation of LDAP.  There are various other products similar to openldap such as Apache Directory Server, 389 Directory Server etc. One of the most widely used and famous enterprise service that supports LDAP is Active Directory .

Tip: When people say they use LDAP in their organization, they typically mean that they use a product that implements LDAP. LDAP is just a protocol.

 

Basic Terms and their definition

Before going into the planning and implementation part, we need to understand some basic terms and their meaning. You’ll hear these terms predominantly in the LDAP environment and knowing about these is mandatory before jumping to next steps.

The below diagram depicts a LDAP Tree Structure. We will cover the basic terms based on this diagram for easier understanding.

Openldap Tutorial - LDAP TREE STRUCTURE

Directory Server

A Directory Server is a type of network database that stores information represented as trees of entries. This is different from a relational database, which uses tables comprised of rows and columns, so directory servers may be considered a type of NoSQL database. 

OpenLDAP is a Directory Server that supports LDAP.

 

Entries

Entry is nothing but a collection of information about an entity. From the diagram, the users (Chris Sam, John Doe) under ou=people are entries. Each entry consists of three primary components: A distinguished name, A collection of attributes, and A collection of object classes.

We’ll see what these components are in detail below

 

DN and RDN

An entry is made up of a collection of attributes that have a unique identifier called a Distinguished Name (DN). A DN has a unique name that identifies the entry at the respective hierarchy. In the diagram above, john.doe and chris.sam are different unique identifiers (uid) that identify different entries at that same level.

A DN is also a fully qualified path of names that trace the entry back to the root of the tree. For example, the distinguished name of the John Doe entry is,

 uid=john.doe,ou=people,dc=devopsideas,dc=com

A Relative Distinguished Name (RDN) is a component of the distinguished name.

For example, uid=john.doe, ou=people is a RDN relative to the root RDN dc=devopsideas,dc=com

In simple terms,

  • DN’s define the fully qualified path to an entry
  • RDN’s define the partial path to the entry relative to another entry in the tree.

 

Schema

A directory entry contains information about a particular entity, or object — for example, a person or a group — and is associated with a distinguished name. An LDAP schema is a set of rules that define what can be stored as entries in an LDAP directory. Each LDAP directory has a default schema, which organizations can customize, or “extend,” by adding elements to it. The elements of a schema are attributes, syntaxes, and object classes. LDAP directory servers provide the ability to enforce the schema to ensure that directory changes made using LDAP operations conform to it.

All objectsClasses and attributes are defined inside schemas.

 

ObjectClass

All LDAP entries in the directory are typed. That is, each entry belongs to object classes that identify the type of data represented by the entry.

ObjectClass are defined inside schemas. objectclasses are the means for including attributes ( For eg, cn, sn, givenName etc are part of inetOrgPerson and person objectClass ).

objectclasses define whether an attribute is mandatory (MUST be present) or optional (MAY be present) within the objectClass.

objectclasses may be STRUCTURAL, in which case they can be used to create entries (data objects), AUXILIARY in which case they may be added into any convenient entry, or ABSTRACT. The most common ABSTRACT objectclass is top, which forms the highest level of every objectclass hierarchy, and terminates any hierarchy.

From the diagram, inetOrgPerson and person are the structural objectClass that defines the type of entry. The attributes cn,sn,uid etc were available because of the inclusion of these objectClass.

 

Attributes

Attributes hold the data for an entry. From the diagram the values uid, sn, givenName etc are attributes. The attributes are available based on the objectClass included for that entry.

An attribute is either mandatory or optional for a particular type of entry. When an attribute is mandatory you must provide a value for the attribute when you add or modify the entries using LDAP operations. An attribute can also be defined to allow multiple values (default) or just one value.

 

Search Filter

Search filters are used to define criteria for identifying entries that contain certain kinds of information. For example, if we need to provide access only to the members of  IT group, then we would be using search filters to implement restrictions. There are various types of search filters ( Presence, Equality, AND, OR, NOT etc ) which we will see during the implementation part. 

 

DIT ( Directory Information Tree )

The entire data in the directory tree is called the DIT.

 

Search Base DN and Scopes

Search Base DN denotes the position from where to start the search in a DIT. The scope specifies how much of that subtree should be considered.

For example, consider we have two subgroups within the group cn=IT (cn=dev,dn=IT,ou=group,dc=devopsideas,dc=com) and (cn=admin,dn=IT,ou=group,dc=devopsideas,dc=com) from the diagram . If we specify the Search Base DN as, 

ou=group,dc=devopsideas,dc=com

the subgroup will specify how much of that subtree should be considered. For example,

  • The baseObject scope (often referred to as just “base”) indicates that only the entry specified by the search base DN should be considered. In this case only entries in ou=group,dc=devopsideas,dc=com will be considered
  • The singleLevel scope (often referred to as “one” or “onelevel“) indicates that only entries immediately below the search base DN (but not the base entry itself) should be considered. In this case, only the entries within ou=group ( i.e, cn=IT and cn=HR ) will be considered.
  • The wholeSubtree scope (often referred to as “sub”) indicates that the entry specified as the search base DN and all entries below it (to any depth) should be considered. In this case all entries within ou=group (i.e, cn=admin,cn=IT,ou=group.. , cn=dev,cn=IT,ou=group.. , cn=IT,ou=group.., cn=HR,ou=group.. ) will be considered including the base (ou=group,dc=devopsideas,dc=com).
  • The subordinateSubtree scope indicates that all entries below the search base DN (to any depth), but not the search base entry itself, should be considered.

 

Now that we have learnt some LDAP jargons, let us see what we will do in this series before we start our implementation by analysing the below scenario.

 

Scenario

Consider you are working in a startup as a System Engineer. You are managing quite a number of Linux servers ( say around 50 ) and various other monitoring tools and applications that requires authentication to gain access. Consider the below cases,

1)  You are responsible for providing access to the servers hosted in cloud

At present, you provide access to users by adding their ssh keys in each server. You have to manually revoke the ssh keys of an employee who has access to the servers exits the company as part of compliance and off boarding process.

 

2) You take care of web and application security

You have setup apache basic authentication for few applications. For ease of management you have created a generic user id and password by running the htpasswd command and shared it with the teams who needs access to those applications. You had to reset the password of the generic user id everytime when someone to whom the credentials were shared moves out of the company or to a different team as part of compliance.

 

3) You take care of the Devops tools

You are managing various monitoring tools ( for eg, graylog,  ) that requires authentication. You are using out of the box authentication system that comes with the product. Since various teams require access for monitoring you have created roles for each of them with the required level of access. You then create individual id’s and tag it with each role and share it with the respective teams. The credentials will further be shared within each team. This again requires you to reset the password of the id every time an employee terminates or switches team to meet the compliance.

 

You have been tasked to provide a better solution to address the difficulties of repeated creation and revocation of access and to provide individual access to users instead of a common id shared between teams.

 

Solution

Above cases quite clearly indicate the need for a common user directory ( openldap in this case ) where user data will be stored and make all other applications connect to that directory to fetch the required data. The user entries will include attributes like username, password, ssh certificate, mail id etc. With the help of this,

  • We can provide individual user access to applications

  • User management becomes easier. We don’t need to create new set of users for each application ( Just make application connect to the LDAP to get existing list of users )

  • Use the same id and password for all applications that are connected with LDAP

  • We can enforce password policies and manage groups and ACL’s from a single place.

  • Eliminate usage of common id’s and sharing of password.

  • Access revocation made easy when an employee exits ( Just remove the user entry from LDAP )

What we will do?

We will be doing the following technical implementation to fix the problems described in the scenario

  • Installation and configuration of openldap in Ubuntu

  • Installing phpLDAPadmin – Web based LDAP Client

  • Planning of LDAP DIT Structure and Config of Overlays ( access, ppolicy )

  • OpenLDAP – Graylog LDAP Integration

  • openLDAP – Linux Client LDAP Integration

  • openLDAP – Basic Authentication using LDAP

  • openLDAP – Self Service Password and Adhoc LDAP utilities

 

Completing above things will give you a greater confidence in understanding and using openldap and LDAP in general. Move on to the next article to get started with the technical implementation.

Series NavigationInstallation and configuration of openldap in Ubuntu >>
0 Shares
Tags: