Building an LDAP Server on Linux

[hoanggialiem]

Part 1

Your network is growing in size and complexity. It's taking on a life of its own, spreading and growing and absorbing everything in its path. You're tearing your hair out trying to keep track, and your users have somehow discovered your secret phone number and are pestering you with endless questions and demands — where do I find this; I don't want to keep track of a dozen different passwords; nothing works like it should.
Of several possible solutions, consider two: 1) find a new hiding place, or 2) implement an LDAP server. While finding a new hiding place might sound ideal, it's an option we're going to have to save for a future article. This series will instead explain what LDAP is good for, detail how to build an LDAP server, and cover what you can do with it.
What LDAP Can Do

In a nutshell, LDAP provides central management of access, authentication, and authorization. It's easily customizable and can:

• Centralize user and group management
• Centralize information stores
• Set security and access control
• Securely delegate read and modification authority
• Serve almost any platform
• Scale efficiently

What LDAP Cannot Do

• Be a heavy-duty relational or transactional database
• Be a filesystem
• Leap tall buildings in any number of bounds

The LDAP protocol is cross-platform, network-aware, and standards-based. There are all kinds of LDAP implementations from all kinds of vendors. This series will focus on OpenLDAP on Linux.

[hoanggialiem]

To DB or Not to DB
Let's get like all pedantic for a moment (please put on your geek beard and pocket protector for this). LDAP – Lightweight Directory Access Protocol – is a protocol, not a database. It accesses a special kind of database that is optimized for fast reads. Use it for relatively static information, such as company directories, user data, customer data, passwords, and security keys. OpenLDAP uses the Sleepycat Berkeley DB. Having said all that, I'm not the pedant police; I'm OK with calling the whole works a database and being done with it.
LDAP is not a good choice, though, when you need fast, frequent changes — for a retail backend, for example. It's not a relational database like Oracle, mySQL, or Postgres. In fact, its structure is very different from a relational database. Rather than storing information in columns and rows, and having a rigid set of indexes and fields, data are stored in attribute type/attribute value pairs. This structure offers great flexibility in designing records. A particular user record, for example, can have new types of data added without having to re-design the entire database. Any kind of text or binary data can be stored.



Roots and Hierarchies
An LDAP directory follows the familiar Unix filesystem structure — root directory at the top of the "tree," with sub-directories branching off. A typical design is to have a single master root directory for the company. Sub-directories are then organized by department, location, function, who's been naughty/nice — anything that works and makes sense for you. Not only is this a nice tidy way to organize the master directory, it lets you grant access permissions to specific pieces of a central data pool in a precise, controlled fashion.
The next step is distributing bits in a sensible fashion. Any individual subdirectory can be replicated elsewhere — for example, on a server in the department it belongs to. Updates from the master directory can be synchronized at whatever intervals you like, providing redundancy and faster access for users, and also placing less of a strain on the master server.
Updates can be initiated in either direction — or, if you want a reason to use buzzwords, "push" or "pull." For example, the accounting department can make updates to their directory, then push the updates to the master server — again, saving the worthy sysadmin much tedious and unnecessary labor. This also conserves bandwidth and system resources.



Easy Upgrading
What's really slick about the distributed nature of LDAP is you can start small. You can implement an LDAP directory in a limited way, testing and getting the hang of it, and then easily scale upwards and migrate more functions to it at your leisure.

[hoanggialiem]

Of ACIs and ACLs
LDAP access control instances (ACIs), which collectively form an access control list (ACL), allow extremely fine-grained control. Here are a few examples:

• Users can modify their own personal information – such as home address, phone extension, work email, etc. – but no one else's.
• All of the information for a particular user can be kept in a single record, but access to individual entries is completely configurable.
• Give managers a precise level of read and read/write permissions for their group. A popular need that this satisfies is giving managers sufficient access to monitor project documents and reports, but not monkey with them.
• Let groups or group leaders determine who gets what kind of access to resources under their control. I absolutely love not being pestered for minor chores like sharing documents and project directories. Power to the people.
• Put passwords and usernames, and other sensitive data, under the iron control of the diligent sysadmin.

User Authentication LDAP supports SASL (Simple Authentication and Security Layer), which incorporates Kerberos, GSSAPI, and DIGEST-MD. Adding LDAP user authentication to an existing network is not too dreadful at all. There are several very good utilities for migrating your existing user and password data provided by PADL Software (see Resources).



The Cheese Stands Alone
It's recommended to run OpenLDAP on a dedicated, standalone server. On a smaller, low-demand network you can get away with using a shared server. In the documentation, you'll see many references to slapd and slurpd. slapd is the LDAP daemon, while slurpd handles replication.
Coming Attractions
In part 2 we'll step through installation, configuring the server, and creating LDAP records. Part 3 will cover user authentication and creating a single login.

[hoanggialiem]

Part 2

Welcome back! In Part 1 we learned basic concepts of LDAP and the uses for an LDAP server. Today we'll install and configure an OpenLDAP directory.
A quick note before we get started: this is LDAP 101. We are not installing any kind of encryption or strong authentication; we'll get to that in part 3. In my experience, learning LDAP in small chunks works best. (Then again, perhaps I'm just a bit dim.) So sit back, strap in, and keep your fingers away from the training wheels.
The Easy Way

The wise sysadmin will consult the documentation for their distro; it's quite possible that OpenLDAP will be packaged and ready to go in a pleasing manner (or ready to go in an odd manner — you never know). I'm all for easy — if your particular distribution provides an easy way, use it. RPMs can also be obtained from rpmfind.net, which thoughtfully lists all the required additional packages.
Debian of course goes its own merry way. apt-get does the job just fine; the tricky bit is finding out the package names. Debian users want ldap-utils; slapd, which is OpenLDAP; and libdb4.1, to get the Sleepycat DB. These three components are enough to get you up and running. apt-get will walk you through a minimal configuration and will automatically start up slapd, the LDAP server daemon.
Installing from Source
At the barest minimum, two tarballs are needed:

• Berkeley Sleepycat DB
• OpenLDAP tarball

The Berkeley DB must be installed before OpenLDAP. OpenLDAP will not build without it. (See Resources for information on how to get it.)

The OpenLDAP tarball is under 2 megabytes, which means even us dial-up lusers can download it without pain. As of this writing, the stable edition is openldap-stable-20030709.tgz. I like to park the tarball and unpack it in /usr/src/:
root@windbag:/usr/src# tar xfz openldap-stable-20030709.tgz
This creates the openldap-2.1.22 directory:
root@windbag:/usr/src# cd openldap-2.1.22

[hoanggialiem]

Here there be README, INSTALL, LICENSE, ANNOUNCEMENT, and COPYRIGHT documents. Take the time to read these, as they contain important information. To take quick a look at compile-time options, type:
root@windbag:/usr/src# ./configure --help
This is interesting reading, with the defaults clearly marked and the options self-explanatory. For now let's just stick with the defaults. Do the magic three commands:

# ./configure
# make depend
# make
Lots of things happen after each one; relax and wait. When it's all done, run the handy built-in test script to verify all is well:
# make test
If there are errors, I fear I must abandon you at this point, and refer you to OpenLDAP.org (See Resources). If all is well, the final step is to actually install the newly-created binaries and man pages. From the root of the OpenLDAP directory, run:

# make install
And you're done. Pay attention to the output of 'make install'; it contains a lot of useful information. Direct it to a file for leisurely perusal:
# make install | tee openldap-install.txt




Configuring slapd.conf
This is the main config file for our shiny new OpenLDAP server. It can be in any number of imaginative locations — I personally like to run updatedb after installing software, so I can find things quickly. On my Libranet system, it's /etc/ldap/slapd.conf.
Guard this file carefully. Find yours and make a backup copy. The original contains useful defaults. For security reasons the default permissions are 600 (only root can read or write to this file).



lapd.conf defines three categories of information: global settings, settings pertinent to a specific backend, and settings pertinent to a specific database. This bit is important, and will save you many a headache if you get it correct now: backend and database directives can override global settings, and database directives can override backend directives.
Blank lines and comments are ignored. A line that begins with white space is a continuation of the previous line — this little nugget alone is responsible for much premature hair loss.
More white-space gotchas: directives can take arguments, and even multiple arguments. These are separated by white spaces. An argument with white space must be enclosed in double quotes: "loud argument." Arguments containing double-quotes or backslashes must be escaped with backslashes: "really \"loud\" argument," for example.
With our wee, simple setup here there is not much to configure in slapd.conf. The following should be enough to get the ball rolling. If your slapd.conf does not contain headings like "Global Directives" and "Backend Directives," you can add them. The important thing is to have three sections, in this order: global, backend, and database.



Under 'Global Directives,' add a logging level directive:
loglevel 256
Under 'Backend Directives' for bdb:
backend bdb
Under 'Database Directives':
database bdb
suffix "dc=carlasworld,dc=net"
rootdn "cn=Manager,dc=carlasworld,dc=net"
rootpw secret
directory "/var/lib/ldap"
I think you can figure out the bits that need to be changed to fit your system. Note how the domain, carlasworld.net, is broken into two type/value pairs. This is planning for the future, in case either value ever needs to be changed or merged with another directory.





Type/Value Pairs
While LDAP is very flexible, there are certain types and values that are already defined, such as access levels, database backends, and debugging levels. Please refer to the essential (and excellent) "OpenLDAP 2.1 Administrator's Guide" (again, see Resources).



I B CN U!
Yes, now we have come to the point where we learn what all those weirdo abbreviations mean. Impress your friends by using them in casual conversations.
DN = distinguished name
O = organization
OU = organizational unit
DC = domain components
CN = common name
SN = surname
UID = user ID
Want to look like a real genius? Peek into the core.schema file, which identifies all of them (there are dozens more).
This is a good time to start up slapd. Depending on your installation, it may already be running — check with ps ax | grep slapd first. If it isn't running, type which slapd to find the executable, and then run it with no arguments. The installation program should have automatically configured startup files to start upon boot, so you'll never have to do this again. OpenLDAP is chock-full of self-tests; run <filepath>/slapd -t to confirm your slapd.conf contains no syntax errors

A Peek Ahead
Well here we are at the end already. To get a jump on Part 3, peruse man ldapadd and man ldif. In Part 3 we'll populate the database and figure out how to use LDAP for single sign-on.

[hoanggialiem]

Part 3

So, you've come back for more OpenLDAP fun. part 1 of this series served as an introduction to the Lightweight Directory Access Protocol, with a breakdown of what the protocol can and cannot do. In part 2 we covered installation and a very basic configuration. Today we'll populate our directory with actual data and glide effortlessly through some of the more common showstoppers.
Let's start with a review of our slapd.conf configuration from part 2:
##Database Directives##
database bdb
suffix "dc=carlasworld,dc=net"
rootdn "cn=Manager,dc=carlasworld,dc=net"
rootpw secret
directory "/var/lib/ldap"



Let's take a good look at each line in the configuration.

• First, make sure to replace "carlasworld.net" with your real domain.
• The rootdn is extremely important. This is where you create the authorized user to make entries into the database. Here I've called it Manager. You can make this anything: admin, boss, ldapdeitysupreme — whatever your heart desires.
• rootpw is also of extreme importance. This is the authorized user's (Manager's) password. For now, we'll use a cleartext password. In the example above, it's "secret"; again the password can be anything you want.
• The directory where OpenLDAP stores the actual database files is on the next line. This directory MUST exist before starting slapd.

"/var/lib/ldap" is a common location created by the installer. Your Linux distribution may have plonked it somewhere else, though. You can also create a location of your own choosing. However, there is more to it than just creating the directory — see the OpenLDAP Administrator's Guide for the gory details. The directory will already be populated by the following files:
$ ls /var/lib/ldap
__db.001 __db.003 __db.005 id2entry.bdb objectClass.bdb
__db.002 __db.004 dn2id.bdb log.0000000001

[hoanggialiem]

Is It Working Yet?
First, check slapd.conf for syntax errors:
# slapd -t


Then run the following command exactly as written:
$ ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts
It will return several lines of mysterious stuff; look for this line:
dn:
namingContexts: dc=carlasworld,dc=net


Changing slapd.conf
Anytime you change slapd.conf, it must be restarted:
# /etc/init.d/slapd restart
Adding Entries
Now we get to the fun part. Manually creating entries is a two-step process. First, create an .ldif file, and then use the command ldapadd to put the new entries in the database. In the .ldif file — let's call it test.ldif — define some attributes of your company:
##my company##
dn: dc=carlasworld,dc=net
objectclass: dcObject
objectclass: organization
o: Tuxcomputing, inc.
dc: carlasworld
dn: cn=Manager,dc=carlasworld,dc=net
objectclass: organizationalRole
cn: Manager
.ldif Pitfalls
Be sure to trim all leading and trailing spaces, as well as any leading blank lines. Any leading spaces, or a leading blank line, will make ldapadd think there is nothing there, while a trailing space at the end of a line tells ldapadd that the next line is a continuation of the previous line. Use blank lines to separate entries.
The next step is to add the test.ldif file to ldap:
# ldapadd -x -D "cn=Manager,dc=carlasworld,dc=net" -W -f test.ldif
See man ldapadd for explanations of the various flags. ldap will ask for your LDAP password and then confirm the entry was added. If you get the infamous "ldap_bind: Invalid credentials (49)" error, it means you gave either the wrong "cn=" entry or the wrong password.
Both the common name (cn) and the password are right there in slapd.conf, so there shouldn't be any mysteries on these items. Note that we will eliminate these later. (While they are needed when creating a new database, we will replace them later on when we add stronger authorization.)
Let's see what our database looks like now:
# ldapsearch -x -b 'dc=carlasworld,dc=net' '(objectclass=*)'
This will display every entry in the database.







Adding Users
Ok, now we're rolling. Let's add some actual users, with a users.ldif file:
#Tux Entry
dn: cn=Tux P Tuxedo,dc=carlasworld,dc=net
cn: Tux P Tuxedo
cn: Tux Tuxedo
objectClass: person
sn: Tuxedo



# ldapadd -x -D "cn=Manager,dc=carlasworld,dc=net" -W -f users.ldif
Enter LDAP Password:
adding new entry "cn=Tux P Tuxedo,dc=carlasworld,dc=net"
# ldapsearch -x -b 'dc=carlasworld,dc=net' '(objectclass=*)'
# extended LDIF
#
# LDAPv3
# base with scope sub
# filter: (objectclass=*)
# requesting: ALL
#

# carlasworld.net
dn: dc=carlasworld,dc=net
objectClass: top
objectClass: dcObject
objectClass: organization
o: Tuxcomputing, Inc.

# Tux P Tuxedo, carlasworld.net
dn: cn=Tux P Tuxedo,dc=carlasworld,dc=net
cn: Tux P Tuxedo
cn: Tux Tuxedo
objectClass: person
sn: Tuxedo

Hurrah! It works, it works! Note that you cannot append new entries to your .ldif file, as it must contain only new entries. If ldapadd finds any existing entries, it will stop and not process any more entries.



The Debian Difference
If you use apt-get to install OpenLDAP, dpkg will automatically configure it and set up the root domain, company, and the authorized LDAP admin and password. You can also create another LDAP admin/password combo in slapd.conf, as we did above, and use either one.

[hoanggialiem]

Schema
Major sources of confusion are schema and object classes. In slapd.conf, see:
# Schema and objectClass definitions
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema


These files contain the attributes that you are allowed to use in your LDAP records. Spend some time reading through these. I know, it's a painful exercise, but understanding the schema is the key to understanding how to use LDAP.
Now might be a good time to mention a useful GUI front-end for LDAP called GQ LDAP Client. It helps a great deal in visualizing the relationships between the different attributes. The excellent Web site LDAPman Schema Reference is another valuable tool you'll want to review.
Conclusion
Ok, it looks like we'll have one more LDAP article after all. In part 4 we'll add encryption and authenticate actual users. We'll wrap up the article (and the series) with some detailed sample configs.

[hoanggialiem]

Part 4

So, you have come back for more OpenLDAP fun (you glutton for punishment, you). Welcome to the final installment of this series, where we'll be discussing how to add security to our OpenLDAP server.
As a quick review of the series, part 1 served as an introduction to the Lightweight Directory Access Protocol, with a breakdown of what the protocol can and cannot do. In part 2 we covered installation and a very basic configuration, while part 2 looked at populating a directory with actual data as well as how to avoid some of the more common showstoppers.
Let's start today's security coverage with a quick look at how to hash your password.



Password Hash
We don't want to store the rootpw in cleartext on the server, so we need to hash it instead. There are several commonly-used hashing methods available via the slappasswd command, including SHA, SSHA, MD5, and CRYPT. CRYPT is the weakest; don't use it. SSHA is the default, and MD5 is good as well. Use slappasswd to generate a nice hashed rootpw:
$ slappasswd
New password:
Re-enter new password:
{SSHA}Lr7P++EoH6GpIS4GZ36vkV4R422RuW7R
Now copy & paste this nice fresh hash into /etc/ldap/slapd.conf:



rootpw {SSHA}Lr7P++EoH6GpIS4GZ36vkV4R422RuW7R
This can be a permanent arrangement. It's fine for a small, simple LAN. An even better solution would be to create an LDAP record that defines the LDAP administrator, and then define access rights for the LDAP admin using ACLs (access control list) in slapd.conf. Please see the OpenLDAP Administrator's Guide for an excellent chapter on ACLs — it's the best tutorial I've seen on ACLs.
Encryption
By default, OpenLDAP sends traffic over the network in cleartext, including passwords and logins. Adding encryption foils snoopers and eavesdroppers. To add it, you'll need:
OpenSSL
Cyrus SASL
These should already exist on your system. If they're not, first take a minute to cuss and then visit your installation disks or your distribution's Web site to get them. On Debian, look for libssl and libsasl; on RPM-based systems, look for openssl, cyrus-sasl, and cyrus-sasl-md5. (If you feel the need to freak out at this point, go ahead. LDAP is quite complex, so freaking out is an accepted, normal reaction.)



Generating a TLS Certificate
First we must generate a server certificate. This is a self-generated certificate for only slapd to use. This method works fine if you don't need to set up a "Certificate Authority" to authorize other certificates and don't need some sort of trusted third-party certificate authority, like Thawte.
Run the following command in the directory that holds slapd.conf. This will generate a new X509 certificate, without a password. It names the certificate slapd_cert.pem, and it names the key slapd_key.pem, and gives it a lifetime of one year:



root@windbag:/etc/ldap/# openssl req -new -x509 -nodes -out slapd_cert.pem -keyout slapd_key.pem -days 365
Generating a 1024 bit RSA private key
...........++++++
...................++++++
writing new private key to 'slapd_key.pem'

Then it asks you a bunch of questions. Go ahead and tell it everything it wants to know. Both of these files must be owned by the the ldap user, which on Red Hat is 'ldap.' (On Debian it's 'root.') Now set your permissions — slapd_cert.pem must be world-readable, and slapd_key.pem must be readable only by the ldap user, and writable by no one.
Edit slapd.conf Yet Again
Next we need to tell slapd where to find these files:



database bdb
# The base of your directory in database #1
suffix "dc=carlasworld,dc=net"
rootdn "cn=Metest,dc=carlasworld,dc=net"
rootpw {SSHA}Lr7P++EoH6GpIS4GZ36vkV4R422RuW7R
# Where the database file is physically stored for database #1
directory "/var/lib/ldap"
#Specify ciphers
TLSCipherSuite HIGH:MEDIUM:+SSLv2:+SSLv3
#TLS keyfile locations
/etc/ldap/slapd_cert.pem
/etc/ldap/slapd_key.pem
How do you know what ciphers to name? First see what your OpenSSL supports:
$ openssl ciphers -v
This will generate a long, impressive list. The terms used in the example above are wildcards. HIGH means use all ciphers with key lengths longer than 128 bits (MEDIUM = 128 bits). I don't believe we want to use LOW, which includes 56 and 64-bit strengths. (Visit OpenSSL.org to find out more about these things.)
Now we need to restart the ldap daemon. On Red Hat, type:
# /etc/init.d/ldap restart
On Debian:
# /etc/init.d/slapd restart




Migrating User Data
There are some lovely scripts provided by PADL Software to ease the chore of populating your LDAP directory. These extract your existing user data and create nice LDAP directory entries. Look for "Migration Tools" on their website. You'll need to edit migrate_common.ph to include your specific network settings.
It doesn't make sense to throw an inordinate burden on the LDAP server by cluttering it with things like /etc/services or /etc/protocols. These are quite static and common to Linux systems; you don't need LDAP to serve them up. Start out with migrating /etc/passwd and /etc/group. I recommend making copies of /etc/passwd and /etc/group, and running the appropriate scripts first on the copies (migrate_group.pl, migrate_passwd.pl).



This will generate .ldif files that you can examine to make sure they're done the way you like. The scripts are easy as pie to use:
# migrate_passwd.pl /etc/passwd passwd.ldif
Then add the .ldif files to the database in the usual manner, via ldapadd:
# ldapadd -x -D "cn=Manager,dc=carlasworld,dc=net" -W -f passwd.ldif


Wrapping Up
OpenLDAP is a great program. It's also hugely complicated. Hopefully this series has helped you get over the initial speed bumps, and you now have a running server to test and learn on. In Resources I've listed what I've found to be the most helpful resources for understanding the most difficult LDAP components: schema, ACLs, and encryption.
I also recommend looking for useful documentation included with your Linux distribution, as there are a number of variations in the way each distribution installs and configures OpenLDAP, as well as things like TLS and SASL.

[thanhtam]

build xong ldap có thể cài thêm phpldapadmin để quản lý. Còn trên win thì dùng ldapbrowser ^_^