Linux.com

Feature

LDAP in the enterprise

By Gary Sims on April 26, 2006 (8:00:00 AM)

Share    Print    Comments   

The Lightweight Directory Access Protocol (LDAP) is a network protocol used to access a special purpose database (called a directory) that stores information about people, organizations, and computers. What can LDAP do for your business and your network?

LDAP was developed as an easier version of the Directory Access Protocol that is part of the X.500 directory standard. It is the network language spoken between a piece of client software (such as an email client) and a directory. A directory is a type of database that stores information about your enterprise in a hierarchical form. Each entry in the directory is referenced using what is called a "distinguished name," which consists of the name of the entry itself as well as the names, from bottom to top, of the entries above it in the directory.

How does this work in practice? Suppose you wanted to write an email to Wile E. Coyote, a colleague in your organization, Acme Products. Rather than needing to know his email address or already have him in your personal address book, your email client can look up Mr. Coyote in the directory (using LDAP) and get his email address. It will discover his distinguished name to be "CN=Wile E. Coyote, O=Acme, C=US". Here CN means Common Name, O means Organization, and C stands for Country; all may be in upper or lower case.

Thanks to this hierarchical structure, a directory can be highly distributed, meaning that different parts of the overall directory can be held on different servers, which themselves can be in different physical locations.

Why would I want LDAP and a directory?

If you don't already have a LDAP directory in your organization, then you probably have several non-unified databases (in different forms) spread throughout your organization. You may have one for login information, one for email accounts, another for distribution lists, an online company phone book, and so on. If a new employee joins your organization, you must create a user account for him, then an email account, then the receptionist must be informed about him, and the mailing room, and so on. With an LDAP directory, the new employee can be added once; the information is then available to all the parts of your enterprise. By using an LDAP directory you can link your people's contact details, user accounts, mailboxes, and other information. An LDAP directory simplifies the task of adding, modifying, and deleting user information. Name changes, password changes, and new phone numbers are all dealt with in a single place.

There are several areas in which your organization can benefit from an LDAP directory. For instance, the messaging infrastructure of your enterprise needs information about all of the users in it. This includes routing data (mailbox account information), address book information, and mailing lists. An LDAP directory is ideal for providing an email infrastructure. Popular open source mail servers such as Sendmail and Postfix can be configured to use LDAP for routing information.

For example, Postfix has an aliases configuration file containing routing information on how to deliver mail to the correct mailboxes. Common aliases include sending mail for webmaster and postmaster to the administrator's mailbox. By storing this information in an LDAP directory and not locally on the mail server, an administrator can maintain the aliases from anywhere on the network. If you have multiple mail servers, they can all be configured to use the same directory information, which removes the need to maintain local copies of the same information (one for each mail server).

An LDAP directory is also well-suited to providing a single sign-on infrastructure. For example, in a mixed Windows and Linux environment, a Samba server can be configured as a primary domain controller with an LDAP-based authentication mechanism.

Linux's Pluggable Authentication Modules (PAM) provide an abstraction layer for the process of authentication. By using PAM, a Linux server can be configured to use LDAP as an authentication mechanism. This combined with Samba acting as a Primary Domain Controller means that a Linux server can provide single sign-on services in a heterogeneous network.

Integrating an LDAP directory into your enterprise needn't be too difficult. Many products, both open source and commercial, are already LDAP-enabled, and there are many software development libraries available to help you write custom software that uses LDAP.

The OpenLDAP server

An enterprise directory server must be fast, robust, secure, scalable, and cost-effective. OpenLDAP is an open source directory server that meets these requirements. It includes a standalone LDAP directory server plus a replication server. The server supports LDAP over both IPv4 and IPv6 as well as the Simple Authentication and Security Layer (SASL). The server provides a fully featured access control facility, allowing you to control access to the information in the directory based on LDAP authorization information, address, domain name, and other criteria.

OpenLDAP offers a choice of database back ends, and the server can be configured to serve multiple databases at the same time. This means that a single OpenLDAP server can respond to requests for many logically different portions of the directory tree, using the same or different database back ends.

Installing the OpenLDAP server isn't too difficult. Debian users can get the software using apt-get. Fedora Core, Red Hat, CentOS, and SUSE all provide OpenLDAP RPMs.

Once you've installed the OpenLDAP server there are some simple steps to getting your first results from it. First, read the slapd.conf file (which is probably in /etc/openldap) and check (and change accordingly) following attributes:

suffix "dc=MY-DOMAIN,dc=COM"
rootdn "cn=YOUR NAME,dc=MY-DOMAIN,dc=COM"
rootpw secret

You need to replace MY-DOMAIN and COM with the appropriate domain components of your domain name. For example, for hungrypenguin.net, I would use:

suffix "dc=hungrypenguin,dc=net"
rootdn "cn=Gary Sims,dc=hungrypenguin,dc=net"

Next you need to create some entries in the directory. The simplest way to do this is using a Lightweight Directory Interchange Format (LDIF) file. Create a file called example.ldif with content like the following:

dn: dc=hungrypenguin,dc=net
objectclass: dcObject
objectclass: organization
o: The Hungry Penguin
dc: hungrypenguin

dn: cn=Gary Sims,dc=hungrypenguin,dc=net
objectclass: person
cn: Gary Sims
sn: Sims

This will create an organization called "The Hungry Penguin" with a person in it called "Gary Sims." Notice the hierarchical nature of the directory -- Gary Sims is below Hungry Penguin.

Once you've created the LDIF file, you can use it to add entries to the directory using the ldapadd tool. Here is the example for The Hungry Penguin organization; you will need to put in your own values.

ldapadd -x -D "cn=Gary Sims,dc=hungrypenguin,dc=net" -W -f example.ldif

In this command, -x tells the tool to use simple authentication when connecting to the directory (instead of SASL). -D specifies which distinguished name to use to connect to the directory. This needs to be the same as the one you specified for the rootdn in slapd.conf. If you get it wrong, then authenticating with the LDAP server will fail. -W tells the ldapadd tool to prompt for the password. Finally, -f tells the tool to use the file example.ldif as the input.

The last step is to check your entires, this time using the ldapsearch tool:

ldapsearch -x -b dc=hungrypenguin,dc=net

As before you need to replace "dc=hungrypenguin" with your organization and "dc=net" with the appropriate domain components of your domain name. You should see your organization and the person in it returned in the results.

This, of course, is just the beginning. There are more details on deploying your LDAP server in the OpenLDAP documentation. There are also papers, presentations and conference materials on the openldap.org website. O'Reilly also publish a book called "LDAP System Administration" which includes sections on OpenLDAP.

Using Linux and the OpenLDAP server to deploy a directory in your enterprise can yield many benefits by bringing together disparate collections of data and turning them into a single, integrated information store.

Gary Sims has a degree in Business Information Systems from a British university. He worked for 10 years as a software engineer and is now a freelance Linux consultant and writer.

Gary Sims has a degree in Business Information Systems from a British university. He worked for 10 years as a software engineer and is now a freelance Linux consultant and writer.

Share    Print    Comments   

Comments

on LDAP in the enterprise

Note: Comments are owned by the poster. We are not responsible for their content.

Err - there's more to life than openldap...

Posted by: Anonymous Coward on April 27, 2006 09:11 AM
If you are serious about ldap for more than a few hundred users, you should be looking at something other than openldap.

Redhat have the fedora directory server (free, oss) and Sun have their free (as in beer) ds.

Openldap just isn't reliable enough for large scale use.

#

Re:Err - there's more to life than openldap...

Posted by: Anonymous Coward on April 27, 2006 10:45 AM
i got the same experience as well with my 800++ users. somehow sometime the database got corrupted!
will get fedora/sun ds a try<nobr> <wbr></nobr>:)

and for administration, i would suggest phpldapadmin - <a href="http://phpldapadmin.sourceforge.net/" title="sourceforge.net">http://phpldapadmin.sourceforge.net/</a sourceforge.net>

#

Re:Err - there's more to life than openldap...

Posted by: Anonymous Coward on April 27, 2006 04:11 PM
Weird.
Openldap with 1200+ users, 2000+ groups,used with samba,apache,squid and many other in house apps, over 9 different (master + 8 replicas) physical locations. No problem whatsoever.

#

I Call!

Posted by: Anonymous Coward on April 27, 2006 09:46 PM
Your environment sounds fascinating. It also sounds far larger that any other Linux/FOSS environment ever reported about on Newsforge!

But, you post anonymously and fail to provide any details or even a company name. If it's for real, the community would be very interested in details about it, perhaps even a Newsforge article.

You upped the ante. I call!

#

Re:I Call!

Posted by: Anonymous Coward on April 28, 2006 10:45 PM
My university runs openldap for 50 000 accounts. Our backup policy has taken care of the slight corruption issues the database had in earlier versions.

#

Re:I Call!

Posted by: Anonymous Coward on April 29, 2006 04:34 AM
Agreed, I'd like to see a NewsForge article on this as well. At worst, it'd be a good "lessons learned" on what to look out for. At best, it'd inspire others to do the same, like what Largo, FL did with netbooting clients.

Please, do post some details if you're at liberty to do so.

#

Yea. So??

Posted by: Anonymous Coward on April 27, 2006 10:01 PM
LDAP in the enterprise is old news. Most every enterprise already has LDAP in the form of Novell's eDirectory or Microsoft's Active Directory. What they lack is applications that integrate with LDAP. While it's great that most email clients have the typically unused ability to search LDAP as an address book, most other applications want to implement their own directory rather than use an existing LDAP directory. This is a most annoying problem for most people. Administrators suffer with it because they must manage multiple directories and sets of rights. Users suffer from it because the are forced to remember multiple logins.

Database applications are the most notorious for their insistence on creating their own user directory and rights rather than integrating into the enterprise directory and centralizing management. Hell, MySQL isn't even capable of doing this. PostgreSQL is capable but, most developers don't bother. That's one of the really nice features of MS SQL, it easily and seamlessly integrates into Microsoft's Active Directory.

We're all set for directories. We need application developers to start using them rather than arbitrarily deciding that their way is better.

#

Your examples are non-Free

Posted by: Anonymous Coward on April 28, 2006 11:02 PM
The problem is that the examples that you site--Novell eDirectory and Microsoft's Craptive Directory--are not Free. OpenLDAP is...as is Fedora (formerly Netscape) Directory Server, for that matter.

So, why aren't some application vendors supporting RFC-compliant (i. e. not just Microsoft's) LDAP?

The problem is that OpenLDAP can be a real pain in the keester to implement, and that's bad, because OpenLDAP+Samba is a terrific replacement for the Craptive Directory, with similar scalability. It's been available for years, but precious few organizations use it because their Windows admins can't handle setting it up.

What we need are user-friendly interfaces that allow, say, a Windows administrator (I refuse to call them "engineers") to set up and deploy Samba+OpenLDAP with similar drag 'n' drop ease that you do with the Craptive Directory today. I can do it, but I have yet to meet anyone else other than John Terpstra himself (he came to our LUG a while back) who can do it, too.

#

Re:Your examples are non-Free

Posted by: Anonymous Coward on April 29, 2006 12:58 AM
I agree with what you're saying 100%, though I feel the need to ask that you point the rest of us in the right direction with an FAQ or a quickstart guide of some sort.


I've read the books, but don't feel I've masted the "drag 'n' drop ease" that you speak of.

#

Re:Your examples are non-Free

Posted by: Anonymous Coward on April 29, 2006 04:31 AM
That's my point. OpenLDAP, with Samba integration, can be a pain if you're not very comfortable with RTFM'ing and putting in the time. It is emphatically not pointy-and-clicky to set up and make work. That's the problem with otherwise terrific software. Once set up, it is excellent, but getting it there can be a challenge.

However, someone did indeed write up a pretty good guide. A fellow named David Trask up in Maine put one together, and that helped me to learn how in a reasonable amount of time. Here is a link.

<a href="http://web.vcs.u52.k12.me.us/linux/" title="k12.me.us">http://web.vcs.u52.k12.me.us/linux/</a k12.me.us>

I hope this helps you as much as it helped me.

#

Re:Your examples are non-Free

Posted by: Anonymous Coward on April 29, 2006 01:38 AM
If you want any manager to take your view seriously, stop using pejorative terms. Speak properly. "Active Directory" is no swear word. Point its weaknesses, elaborate on the strong points of OpenLDAP with respect for all the other players. This is what in the end will make the difference. Otherwise, managers will think, 'o well, on the one hand we have MS, on the other hand just a bunch of kids who cannot even speak properly'. Guess what product they will choose.

OpenLDAP is not really hard to implement if you read the fine manual. It is far from the ease of configuration of AD. Plus, you do not need to understand how ldap servers work to get AD working, but you will need to understand them as soon as you run into problems with it (and believe me, you will sooner or later).

#

Re:Your examples are non-Free

Posted by: Anonymous Coward on April 29, 2006 04:23 AM
I was speaking correctly, and I wasn't speaking to other managers here (I am one, actually--yes, I am a manager who actually kept his chops). I was speaking to the hackers.

"Active Directory" actually is indeed a swear word for those who believe in freedom. That's one major reason that Red Hat bought and GPL'd Netscape Directory Server (thank goodness, too!). It's like Broadcom and Texas Instruments with their wireless chipsets; both of those names will be swear words to many of us until, like RaLink and others, they get a clue and open up their wireless chipset specs. Free Software hackers typically value freedom. I was speaking of one way for them to help make that desired freedom more prevalent. Were I a hacker myself, I'd have written one long ago.

The "Craptive Directory" is a proprietary, non-standard bastardization of LDAP+Kerberos, and other systems which actually implement standard LDAP+Kerberos do not interact well at all with it. The Samba team has gone into this in rather significant detail, since they're the ones who are working on reverse-engineering those secret tweaks.

You're right about Reading The Fine Manual (RTFM); that's how I learned, too. You're also right about needing to understand how LDAP servers work. But remember, most Windows administrators cannot handle either of these, and that's who I was talking about. To become ubiquitous in corporate America, there will need to be a GUI that's at least as easy to use as the GUI on Windows Server, and that GUI will need to handle authentication and authorization, including Samba configuration. Sadly, there aren't enough people like you and I are that can RTFM and do it at the command line. I wish that there were; we recently had positions open, and I'd have hired them!

Hopefully, Red Hat will have the resources to pull off such an easy-to-use GUI, now that they've freed the Netscape Directory Server code. I would love to see this.

#

Look RMS, Are You On Crack?

Posted by: Anonymous Coward on April 29, 2006 05:09 AM
Spare me the "it's not free" drivel. Having suffered through years of FOSS garbage I've had it! The fact that it's free does not in and of itself make any software worthwhile. Additionally, using "cute" derogatory names for commercial products does not reduce their value. Not in the least bit.

If and when you have ever used a real directory in a medium or large enterprise, you will very quickly come to realize that OpenLDAP does not scale well (I'm not talking about the number of objects you can load into an LDIF file), is relatively very difficult to setup and is far far far more difficult to manage on a daily basis. Combine these negative aspects with the fact that no software vendors offer any real or direct application compatibility or support for OpenLDAP and I am left wondering why ANYONE would EVER want to use it in the enterprise.

I have yet to use the Fedora/Red Hat directory but, I have used the Netscape directory from which it has been derived and I can tell you with absolute certainty that, compared to eDirectory or even the Active Directory that you seem to loathe, the Netscape directory is also a steaming pile!

Sun fans don't bother chiming in. Sun's future is far too dim and there course is far to shaky for anyone to take their offering seriously. There's just too much risk that Sun will be gone tomorrow or they will decide to abandon the directory market for yet another hair brained strategy.

A good directory with good management tools and and applications that integrate with it are essential for any enterprise of more than 5 people. So much so that any such enterprise is more than willing to spend large amounts of cash on such a directory. OpenLDAP isn't even in the running!

Right now there are two real directories for the enterprise. eDirectory is the best of the bunch but, Active Directory has a large installed base and is well supported by third party vendors so it cannot be ignored. Active Directory also has great management tools, Novell seems to have trouble deciding which tools and which names they are going to wear on any given week.

You think that you and Terpstra being the only ones to be able to properly implement Samba and OpenLDAP (you do think highly of yourself) is a bragging point. You think it makes you 1337. It doesn't. Instead, your claim just lends further credibility to my assertion that OpenLDAP is not the answer that people are looking for.

We already have good working (non-free (TM)RMS) directories. What we need is for developers to leverage those directories and stop insisting that we manage yet another one! Novell has done a great job of addressing this issue with their DirXML software which allows bidirectional synchronization between directories such as eDirectory, Active Directory, SAP, etc. But, this adds yet another point of failure that could all be eliminated if the application developers would just get a clue (MySQL).

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya