>I am provoked or compelled or whatever you say to write this article about this topic and the article that spurs the interest is here and many more on the internet by some brilliant guys and that’s reminds me of dealing with LDAP with one of my job assignment.Without doubt I must say it is a complex topic to deal with( at least my bend of mind says so.. YMMV).But having said that it is an absolute must for any administrator handling large network infrastructure in the corporation should be very well aware of this protocol as well the usability of it.
I do not issue any guarantee that this will work for you.
I am assuming that readers are aware of this protocol, if not then please look in OpenLDAP Website to get an idea of it.OpenLDAP is an open source suite of software that includes the LDAP server daemon (slapd), a replication daemon (slurpd) and a small collection of command line client tools, like ldapsearch and ldapadd, among others. In this article, we’ll set up and populate a small but functional LDAP server using the slapd daemon, and start to make use of it with a Linux client.
Definition and Components
LDAP stands for Lightweight Directory Access Protocol, which is to say that, by definition, LDAP is a protocol, and nothing else. However, the protocol exists to perform operations on data, and is really pretty useless without it. This brings up the components that make up an LDAP deployment: client software used to send LDAP requests, the server daemon that handles incoming LDAP requests, and the back-end data store. I will refer to the last two collectively as a “directory service.”
Back-end Data Storage
Of these components, the back-end data storage mechanism is the least relevant to you unless you’re administering a production LDAP deployment. Developers writing code that accesses an LDAP server and end users who access a directory service via some client utility should be happy to let the protocol do the job of getting data to them without knowing anything about the back end. Adding, removing, updating, deleting, and fetching data from a directory service occurs through the LDAP protocol.
Now there are few variant of the LDAP thing like :
a)OpenLDAP
b) FDS(Fedora Directory Server)
c) Novell’s eDirectory
d)Sun Java System Directory or formarly iPlanet
So we will sticks with OpenLDAP in this article to investigate with.
What Is LDAP Used For?
An LDAP directory service stores information for use by systems as well as end users (and their various applications). Probably the most common use of LDAP is for replacing either flat-file authentication (think /etc/passwd) or legacy networked authentication (think NIS). The benefit of any networked authentication mechanism over a flat file system is clearly that it lifts the burden of having to keep files on all of your systems in sync. The benefit of LDAP over, say, NIS is (among other things) a finer-grained control over the data and how it is accessed (and by whom). You can also make encrypted connections to LDAP servers using TLS or SSL, and you never have to muck with flat file “maps” or complicated Makefiles to change the data.
Because LDAP is a transaction-based system, operations that complete successfully are immediately “live.” Modern Unix-based systems (including Linux, BSD, and OS X) can rely on LDAP to get just about any information they could store in flat files or NIS, including hosts, automounter configuration, users, groups, and more. Add to that the ability to have Samba, Apache, PAM, tcpwrappers, Sendmail, and other applications talk to LDAP for authentication, aliases, and other tidbits of useful information, and you have the beginnings of a very well-integrated, easily maintained, authoritative data source for your entire infrastructure.
LDAP is also popular for use as a “white pages” directory for a department or corporation. For example, most email applications, from Mutt and Pine to Outlook, Evolution, and KMail all know how to talk to an LDAP server. This makes it very easy to, for example, tell KMail to autocomplete addresses as you type using an LDAP directory as its addressbook source instead of (or in addition to) local files.To add to the list Thunderbird too will support that protocol.
A Closer Look at LDAP Data
It’s extremely important when learning about LDAP and how it deals with data to separate the structure (or topology) of the data from the definitions of the objects themselves.
Simply, the structure of LDAP data is a hierarchical collection of objects. Objects can represent anything from people to printers and take their places within the hierarchy using whatever logic you like.
Objects?
Yes, objects. Each object has a list of attributes associated with it that describe that particular object. When you add or delete an object, make a request for an object, or change the value of an object’s attribute, you do so solely using the LDAP protocol. In short, LDAP exists to manipulate or fetch data about objects.
Hierarchical?
The layout of the data in an LDAP directory is the Directory Information Tree (DIT). You can customize it to the needs of your organization, but it’s still a hierarchical tree structure. This tree is not dissimilar to a typical filesystem; there’s a “top” or “root” directory, under which are high-level objects (directories in a filesystem). Those help you to categorize the lower level objects that you’re really interested in (in a filesystem, these are the files themselves).
Suppose you want to store information about people using a hierarchical collection of objects. Viewing things as a filesystem, you could create a /People directory, and under that, create a file–/People/whatEverYouWant. That file contains attribute name and value pairs to describe “steve.” One attribute might be “firstname,” with a value of “Dan.” Save the file, and create a new one for each person. Eventually, you have a filesystem that looks something like:
/people
Steve
Dan
Bhaskar
We might create it like department wise like this:
/people
/Engineering
Bhaskar
Dan
Jones
/Finance
Marry
Garth
LDAP data are represented in the LDIF(LDAP Data Interchange Format).
What Are Objectclasses?
Objectclasses are prototypes for entries that will actually exist in your directory server. The objectclass definition (which uses ASN.1 syntax) specifies which attributes may or must be used by LDAP entries declared as instances of a particular objectclass.
Get it? Let me explain it backward, in the way that most people get into LDAP: you want to store information about people. The most common attributes associated with people are:
* First name
* Last name
* Email address
* Phone numbers
* Room numbers
These attributes are great for setting up an office whitepages server that users can refer to for information about people in their office. The key now is finding out which objectclass definitions either require or allow for the use of these attributes. When I started with LDAP, I researched this by perusing the actual schema files that come with most (if not all) directory servers. These files are human-readable.
Object Class Definitions
Here’s the definition of the inetOrgPerson objectclass, which is a good place to start:
objectclass ( 2.16.840.1.113730.3.2.2
NAME ‘inetOrgPerson’
DESC ‘RFC2798: Internet Organizational Person’
SUP organizationalPerson
STRUCTURAL
MAY (
audio $ businessCategory $ carLicense $ departmentNumber $
displayName $ employeeNumber $ employeeType $ givenName $
homePhone $ homePostalAddress $ initials $ jpegPhoto $
labeledURI $ mail $ manager $ mobile $ o $ pager $
photo $ roomNumber $ secretary $ uid $ userCertificate $
x500uniqueIdentifier $ preferredLanguage $
userSMIMECertificate $ userPKCS12 )
The first line states that what follows is an objectclass definition, as opposed to an attributetype definition. The long number is the ASN.1 number assigned to the objectclass. If you create your own objectclasses, this number is significant; it’s where you use your organization’s IANA Enterprise Number to identify any objectclasses that you create.
The NAME line should be self explanatory. It is the name that will appear in your users’ entries to state that the user is of type inetOrgPerson. This line gives you license to use any of the attributes in the objectclass definition to describe the user.
The DESC line is usually a useful description that can help you use this object in a way appropriate to the intent of the definer. You don’t want to use objectclasses in a completely unorthodox way, because when you reach out to others for help, they’ll find themselves asking you more questions than you ask them, which is often a sign that you’ve gone off in the wrong direction.
The SUP line is critical, and the theory is tough to describe without getting pretty verbose. SUP is short for SUPERIOR, and it names another objectclass from which this objectclass inherits. In this case, the superior or parent objectclass is organizationalPerson. The organizationalPerson class inherits from the person objectclass, which inherits from an objectclass called top. If an objectclass has no other superiors, it is always a child of the top objectclass.
It’s an inheritance chain. You need to understand it, because some LDAP servers strictly enforce it, and if you violate it in the creation of your entries, the directory server will unceremoniously spit them back at you.
The MAY line is actually a block. That block (between parentheses) contains a list, delimited with the $ symbol, of all of the attributes that MAY be used to describe an object declared of the type inetOrgPerson.
OK enough internals..lets go ahead and install and deploy the thing.For more curious reader I will provide you the link from where this article is influenced in resource section in the end.
Installing OpenLDAP:
You can download OpenLDAP from the OpenLDAP website. While it is certainly possible to obtain precompiled binary distributions of OpenLDAP in RPM, deb, and other package formats, these tend to be somewhat older releases. There are many useful customizations you can make during an OpenLDAP compile, and I’ve never had much trouble compiling OpenLDAP from source, so this is the method I’m advocating.
This is not to say that there are absolutely no dependencies to satisfy. There are two major dependencies, both of which are very easy to handle:
Berkeley DB
The OpenLDAP team strongly recommends using Sleepycat Software’s Berkeley DB as the data storage mechanism for an OpenLDAP deployment. As we mentioned in Part One of the series, LDAP is not a database, but a protocol for accessing and managing data. But the data has to live somewhere, and Berkeley DB is easy to deal with, even for newbie admins. If you’re among those who have nightmares about databases, take heart in knowing that OpenLDAP does a superb job at hiding the fact that you’re even dealing with one. Download the Berkeley DB source from the user-friendly Sleepycat download page. For my test build, I used Berkeley DB 4.1.25 without strong encryption support.
Building Berkeley DB couldn’t be easier. Unpack the tarball, cd to the build_unix directory, and type ../dist/configure, followed by make and make install (the last as root). This will create a directory called /usr/local/BerkeleyDB.4.1, which contains all of the pertinent parts we need for our OpenLDAP installation.
OpenSSL for LDAPS
If you’re using Redhat, Fedora,Gentoo,Arch,Debian or any number of other recent distributions, OpenSSL is probably already installed. If it isn’t, and you wish to enable secure connections to your LDAP server, you need to install it. Luckily, this is a breeze. Grab a source tarball from the OpenSSL Download Page. Untar it, cd to the resulting directory, and run the standard configure and make commands. I also recommend that you run make test, and then (as root, of course) make install. This puts everything you need in the /usr/local/ssl directory by default.
Anyway I have created a user and group which will be able to operate the ldap thing going.Here is that:
bhaskar@bhaskar-laptop_14:51:17_Mon Sep 13:~> id ldap
uid=439(ldap) gid=439(ldap) groups=439(ldap)
Now we need to investigate the slapd.conf file,this is the file which drive ldap.So here we go:
Here’s a quick and dirty slapd.conf that gets the daemon up and running and allows an administrative user to manipulate data:
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
Schema files define objects and attributes. When the slapd daemon starts, it includes whichever schema files we tell it to here, and that determines the types of objects and attributes supported by that slapd daemon. So, for example, if we did not include the nis.schema file, we would not be able to add typical Unix accounts using only the other schema files we’ve included. Schema files are human-readable, and you could even create your own schema files if you needed some wacky object-types that aren’t already defined.
allow bind_v2
pidfile /var/run/slapd.pid
In newer versions of OpenLDAP, only LDAPv3 binds are allowed by default, which has caused many a mailing list crisis, since there are applications that don’t support making a version 3 bind to a directory server. In the event we come across any in our travels, we’ve allowed LDAPv2 binds for our proof-of-concept, as you can see here:
database bdb
suffix “dc=bhaskar-laptop,dc=localdomain”
rootdn “cn=Manager,dc=bhaskar-laptop,dc=localdomain”
rootpw secret ————> which is generated by slappasswd previously,just cut and paste
directory /var/lib/ldap
Our database backend is the Berkeley database, which OpenLDAP knows as “bdb.” The slapd.conf man page can tell you other possible values for the database directive. Our suffix uses what’s known as the “domain component” model. This model just takes the parts of a domain and references each part of the domain name as a separate domain component (dc). We’ll talk more about this in a future article.
The rootdn and rootpw values define the administrative username and password for performing on the directory or its data operations that require administrative priveleges. The username is defined using a common name (cn), and the object entry for that user is stored directly under our top-level entry — hence the trailing domain components. The password is generated using the slappasswd command, which simply prompts you for a password and generates output which can be cut and pasted into the slapd.conf file, as I’ve done here.
directory tells the slapd daemon where to store the data files for this particular database definition. There can be several database sections in a slapd.conf file. Here, we’re telling slapd to use its home directory as its data storage directory, which is why the ldap user must be able to write there.
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
Defining indexes at this early stage won’t make a great amount of difference. However, as the directory grows and more demands are placed upon it, indexes can mean the difference between users who don’t notice that things that used to be handle by, say, NIS are now handled by something else, and a completely unusable directory server.
Now all boil down to starting the ldap daemon that slapd like below:
/etc/init.d/slapd start——————> Every others else
or
/etc/rc.d/slapd start ————> Gentoo ,Arch and variant
or
service slapd start ————> Fedora and Redhat variant
Still it depend on the OS you sit on..but the intention would be same..
Resources:
a)LDAP
b)LDAP-data
c)OpenLDAP Install
d)OpenLDAP Install -II
e)OpenLdap Administration
Hope this will help.
Cheers!
Bhaskar
Unixbhaskar's Blog 