OpenLDAP installation on Debian

Posted by docelic on Wed 19 Mar 2008 at 10:40

The purpose of this article is to give you a straight-forward, Debian-friendly way of installing and configuring OpenLDAP. By the end of this guide, you will have a functional LDAP server that will serve as a central authentication system for user logins onto all machines in the network, without the need to manually create users' accounts on individual machines.

However, for improved authentication security and a true networked solution, it is recommended to use LDAP in combination with Kerberos, with a matching Kerberos setup explained in the MIT Kerberos 5 Guide.


The newest version of this article can be found at http://techpubs.spinlocksolutions.com/dklar/ldap.html.

Table of Contents

Introduction
The role of LDAP within a network
Glue layers: integrating LDAP with system software
Conventions
OpenLDAP
Server installation
Initial configuration
Initial test
Creating basic tree structure
Creating user accounts
Graphical LDAP browsers
NSS configuration
PAM configuration
Conclusion
Links

Introduction

LDAP is a service that has been traditionally captivating system administrators' and advanced users' interest, but its (seemingly or not) high entry barrier and infrastructure requirements have been preventing many from using it.

LDAP has already been the topic of numerous publications. Here, we will present only the necessary summary; enough information to establish the context and to achieve practical results.

You do not need to follow any external links; however, the links have been provided both throughout the article and listed all together at the end, to serve as pointers to more precise technical treatment of individual topics.

The role of LDAP within a network

OpenLDAP is an open source implementation of the Lightweight Directory Access Protocol. Directory itself is a tree-structured, read-optimized database. Yellow pages or a phonebook are good associations to have in mind, even though LDAP is much more powerful.

We will use OpenLDAP to provide a central authentication location for user logins anywhere on the network, with their home directories being automatically created on their first access to individual machines.

This guide can be followed standalone to make OpenLDAP both perform authentication and serve user meta data. However, using LDAP for authentication as shown here is not secure due to plain text connections made to the LDAP server and passwords travelling over the wire. It is therefore advised to use LDAP in combination with a superior and secure network authentication mechanism Kerberos, as explained in another article from the series, the MIT Kerberos 5 Guide. That said, let's move onto our LDAP setup.

From a technical perspective, LDAP directory consists of a set of hierarchically organized entries. Each entry belongs to certain Object Classes and contains various key=value pairs called attributes.

Each entry is uniquely identified by a Distinguished name ("DN"). DN is formed as a list of components, separated by commas, that provide "full path" to the entry, starting from the top of the tree. For example, company Example, Inc. would have the root of the tree in dc=example,dc=com. A person employed by Example, Inc. would then have a corresponding LDAP entry with DN cn=person,ou=People,dc=example,dc=com. Which attributes may or may not be present under an entry is then governed by the entry's objectClasses.

You might notice the individual components themselves, such as cn=person above, are also formed as key=value pairs. Those "keys", cn, ou and dc, stand for Common Name, Organizational Unit and Domain Component. They are a part of every-day LDAP terminology that you will get used to.

ObjectClasses, attributes, syntaxes, matching rules and other details of the tree structure are loaded at LDAP server startup by reading the configured schema files.

Let's quickly identify LDAP-specific elements in the metadata retrieval process:

  • LDAP is not in any way related to traditional system usernames or other data. However, part of its functionality in our setup will consist in storing information traditionally found in Unix files /etc/passwd and /etc/group, thus making that data network-accessible at a centralized location.

    People's login names will be used in pairing people with the corresponding information in the LDAP tree. For example, username person will map to an LDAP entry uid=person,ou=People,dc=example,dc=com.

  • LDAP can be configured to contain user passwords. Passwords can be used both for authenticating as specific users and gaining access to protected entries, and for verifying whether the user knows the correct password.

    When a user opens a LDAP client and intends to browse the directory, his password is used to establish his identity and the set of privileges. When LDAP is configured to perform user authentication, his password is only used to perform a connection to the LDAP directory — successful connection ("bind") implies the user knew the correct password.

You can find the complete LDAP documentation at the OpenLDAP website. For an authoritative OpenLDAP book, see Gerald Carter's LDAP System Administration by O'Reilly.

Glue layers: integrating LDAP with system software

NSS

On all GNU/Linux-based platforms, NSS is available for network data retrieval configuration. NSS is an implementation of the Name Service Switch mechanism.

NSS will allow for inclusion of LDAP into the "user data" path of all services, regardless of whether they natively support LDAP or not.

You can find the proper introduction (and complete documentation) on the NSS website. Also take a look at the nsswitch.conf(5) manual page.

PAM

Likewise, on all GNU/Linux-based platforms, another piece of the puzzle, Linux-PAM, is available for service-specific authentication configuration. Linux-PAM is an implementation of PAM ("Pluggable Authentication Modules") from Sun Microsystems.

Network services, instead of having hard-coded authentication interfaces and decision methods, invoke PAM through a standard, pre-defined interface. It is then up to PAM to perform any and all authentication-related work, and report the result back to the application.

Exactly how PAM reaches the decision is none of the service's business. In traditional set-ups, that is most often done by asking and verifying usernames and passwords. In advanced networks, that could be retina scans or — Kerberos tickets, as explained in another article from the series, MIT Kerberos 5 Guide.

You can find the proper introduction (and complete documentation) on the Linux-PAM website. Pay special attention to the PAM Configuration File Syntax page. Also take a look at the Linux-PAM(7) and pam(7) manual pages.

Conventions

It's quite disappointing when you are not able to follow the instructions found in the documentation. Let's agree on a few points before going down to work:

  • Our platform of choice, where we will demonstrate a practical setup, will be Debian GNU.

  • Install sudo. Sudo is a program that will allow you to carry out system administrator tasks from your normal user account. All the examples in this article requiring root privileges use sudo, so you will be able to copy-paste them to your shell.

    su -c 'apt-get install sudo'
    

    If asked for a password, type in the root user's password.

    To configure sudo, add the following line to your /etc/sudoers, replacing $USERNAME with your login name:

    $USERNAME ALL=(ALL) NOPASSWD: ALL
    

  • Debian packages installed during the procedure will ask us a series of questions through the so-called debconf interface. To configure debconf to a known state, run:

    sudo dpkg-reconfigure debconf
    

    When asked, answer interface=Dialog and priority=low.

  • Monitoring log files is crucial in detecting problems. The straight-forward, catch-all routine to this is opening a terminal and running:

    cd /var/log; sudo tail -f daemon.log sulog user.log auth.log debug kern.log syslog dmesg messages kerberos/*
    

    The command will keep printing log messages to the screen as they arrive.

  • Our test system will be called monarch.spinlock.hr and have an IP address of 192.168.7.12. Both the server and the client will be installed on the same machine. However, to differentiate between client and server roles where relevant, the client will be referred to as monarch.spinlock.hr and the server as ldap.spinlock.hr. The following addition will be made to /etc/hosts to completely support this scheme:

    192.168.7.12	monarch.spinlock.hr krb.spinlock.hr ldap.spinlock.hr monarch krb ldap
    

OpenLDAP

Server installation

The following procedure uses the libdb library version 4.6. If this version is not available in your Debian repository, use libdb4.4 or libdb4.2.

sudo apt-get install slapd ldap-utils libldap2 libdb4.6

Debconf answers for reference:

Omit OpenLDAP server configuration? No
DNS domain name: spinlock.hr
Organization name? spinlock.hr
Administrator password: password
Confirm password: password
Database backend to use: BDB
Do you want the database to be removed when slapd is purged? No
Allow LDAPv2 protocol? No

As soon as the installation is done, the OpenLDAP server (command slapd) will start.

Initial configuration

Our OpenLDAP server is already running, so let's first configure /etc/ldap/ldap.conf, a common configuration file for all LDAP clients. This will allow us to run ldapsearch and other commands without having to list all the basic parameters by hand each time.

Enable the following two lines in /etc/ldap/ldap.conf, creating the file if necessary:

BASE  dc=spinlock, dc=hr

URI ldap://192.168.7.12/

Then, let's edit the server's configuration file, /etc/ldap/slapd.conf, to fine-tune its behavior.

Make sure all the schema files are enabled:

include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/nis.schema
include         /etc/ldap/schema/inetorgperson.schema

Change the verbosity level from 0 or "none" to 256:

loglevel 256

Search for line "index objectClass eq" and add another search index. In particular combinations, it may be possible to receive no results when the searched entries are not indexed, so this step is important:

index           objectClass eq
index           uid         eq

To make the new index option apply, run the following three commands.

sudo invoke-rc.d slapd stop
sudo slapindex
sudo chown openldap:openldap /var/lib/ldap/*
sudo invoke-rc.d slapd start

Initial test

It's already the time to test the installation. Our OpenLDAP server does not contain much information, but a basic read operation can be performed normally.

In LDAP terms, read operation is called a "search". To perform a search using generic command-line utilities, we have ldapsearch and slapcat available.

Ldapsearch (and other LDAP utilities prefixed "ldap") perform operations "online", using the LDAP protocol.

Slapcat (and other OpenLDAP utilities prefixed "slap") perform operations "offline", directly by opening files on the local filesystem. For this reason, they can only be ran locally on the OpenLDAP server and they require administrator privileges. When they involve writing to the database, the OpenLDAP server usually needs to be stopped first.

In the output of the two search commands, you will notice two LDAP entries, one representing the top level element in the three, and another representing the LDAP administrator's entry.

ldapsearch -x

# extended LDIF
#
# LDAPv3
# base <dc=spinlock, dc=hr> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# spinlock.hr
dn: dc=spinlock,dc=hr
objectClass: top
objectClass: dcObject
objectClass: organization
o: spinlock.hr
dc: spinlock

# admin, spinlock.hr
dn: cn=admin,dc=spinlock,dc=hr
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2

Now, in the following slapcat output, pay attention to the extra attributes not printed with ldapsearch. One of those is userPassword, which is not shown to anonymous readers due to an appropriate access restriction in /etc/ldap/slapd.conf.

sudo slapcat

dn: dc=spinlock,dc=hr
objectClass: top
objectClass: dcObject
objectClass: organization
o: spinlock.hr
dc: spinlock
structuralObjectClass: organization
entryUUID: 350a2db6-87d3-102c-8c1c-1ffeac40db98
creatorsName:
modifiersName:
createTimestamp: 20080316183324Z
modifyTimestamp: 20080316183324Z
entryCSN: 20080316183324.797498Z#000000#000#000000

dn: cn=admin,dc=spinlock,dc=hr
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: e2NyeXB0fVdSZDJjRFdRODluNHM=
structuralObjectClass: organizationalRole
entryUUID: 350b330a-87d3-102c-8c1d-1ffeac40db98
creatorsName:
modifiersName:
createTimestamp: 20080316183324Z
modifyTimestamp: 20080316183324Z
entryCSN: 20080316183324.804398Z#000000#000#000000

Creating basic tree structure

As explained, the LDAP database is structured as a tree. The top level element in the tree for your organization is often its domain name. In case of a domain spinlock.hr, the toplevel tree element would be dc=spinlock,dc=hr.

On the next level below, an organization is often divided into "organizational units", such as people, groups, hosts, services, networks, protocols etc.

Accordingly, to support people's Unix "meta data" in our LDAP directory, we will be interested in creating two of the mentioned organizational units, People and Group. The two will roughly correspond to the Unix /etc/passwd and /etc/group files.

Ldap data is interchanged in a textual format called LDIF. Command-line LDAP utilities receive and output data in this format. Note that LDIF stream can also contain commands, such as for adding, modifying or removing LDAP entries.

Knowing this, we'll put together a simple LDIF file, /var/tmp/ou.ldif, that will instruct the server to add the two organizational units. Pay attention to the empty lines separating the entries:

dn: ou=People,dc=spinlock,dc=hr
ou: People
objectClass: organizationalUnit

dn: ou=Group,dc=spinlock,dc=hr
ou: Group
objectClass: organizationalUnit

To load the LDIF file into the server, let's show an example using the offline tool, slapadd:

sudo invoke-rc.d slapd stop
sudo slapadd -c -v -l /var/tmp/ou.ldif
sudo invoke-rc.d slapd start

Let's use ldapsearch to verify the entries have been created.

ldapsearch -x ou=people

# extended LDIF
#
# LDAPv3
# base <dc=spinlock, dc=hr> (default) with scope subt
# filter: ou=people
# requesting: ALL
#

# People, spinlock.hr
dn: ou=People,dc=spinlock,dc=hr
ou: People
objectClass: organizationalUnit

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Creating user accounts

In the same manner we've created the two organizational units, let's create our first group and a person belonging to it. Again, we approach the problem by constructing and loading an LDIF file, /var/tmp/user1.ldif:

dn: cn=mirko,ou=group,dc=spinlock,dc=hr
cn: mirko
gidNumber: 20000
objectClass: top
objectClass: posixGroup

dn: uid=mirko,ou=people,dc=spinlock,dc=hr
uid: mirko
uidNumber: 20000
gidNumber: 20000
cn: Mirko
sn: Mirko
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
loginShell: /bin/bash
homeDirectory: /home/mirko

To load the LDIF file into the server, let's show an example using the online tool, ldapadd. Since, as said previously, ldapadd uses the LDAP protocol, we'll have to bind to the server as system administrator and type in the correct password:

ldapadd -c -x -D cn=admin,dc=spinlock,dc=hr -W -f /var/tmp/user1.ldif

Enter LDAP Password: PASSWORD
adding new entry "cn=mirko,ou=group,dc=spinlock,dc=hr"

adding new entry "uid=mirko,ou=people,dc=spinlock,dc=hr"

To define the new user's password, let's run an online tool ldappasswd. This step is not needed if you plan to use LDAP in combination with Kerberos and therefore leave Kerberos to store passwords and perform authentication-related work, as explained in MIT Kerberos 5 Guide.

ldappasswd -x -D cn=admin,dc=spinlock,dc=hr -W -S uid=mirko,ou=people,dc=spinlock,dc=hr

New password: new user password
Re-enter new password: new user password
Enter LDAP Password:  admin password
Result: Success (0)

Let's use ldapsearch to verify the user entry has been created. Note that the password field, userPassword, will not be shown even if you created it, due to the default access restrictions in /etc/ldap/slapd.conf.

ldapsearch -x uid=mirko

# extended LDIF
#
# LDAPv3
# base <dc=spinlock, dc=hr> (default) with scope subtree
# filter: uid=mirko
# requesting: ALL
#

# mirko, people, spinlock.hr
dn: uid=mirko,ou=people,dc=spinlock,dc=hr
uid: mirko
uidNumber: 20000
gidNumber: 20000
cn: Mirko
sn: Mirko
objectClass: top
objectClass: person
objectClass: posixAccount
loginShell: /bin/bash
homeDirectory: /home/mirko

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Congratulations! You have a working LDAP setup.

Graphical LDAP browsers

While the LDIF format shown represents the basis of data interchange in LDAP, for day to day work a graphical client may be preferred.

There are many LDAP GUI clients, only few of which seem useful for general-purpose LDAP editing. Two of those are gq, the "Gentleman's LDAP client", and luma.

Gq version 1.0.0 packaged in Debian has a bug in configuration saving code. The straightforward way to using it is:

  • running gq on the same machine as the LDAP server ('localhost')

  • following menu File —> Preferences —> Servers —> 'localhost' —> Edit, typing "dc=spinlock,dc=hr" under "General/Base DN" and "cn=admin,dc=spinlock,dc=hr" under "Details/Bind DN".

  • back on the main program window, following Browse —> localhost, typing in admin password and browsing the LDAP tree

NSS configuration

Now that we have a new user created in LDAP, we should allow the system to see it. For example, let's test for existence of users root and mirko. The administrator will be present, while mirko will not:


id root
uid=0(root) gid=0(root) groups=0(root)

id mirko
id: mirko: No such user

To enable the system see LDAP accounts, we need to install and configure libnss-ldap (which may automatically install libpam-ldap as well):

sudo apt-get install libnss-ldap nscd

All debconf answers for reference:

LDAP server Uniform Resource Identifier: ldap://192.168.7.12/ (Note the "ldap://", NOT "ldapi://"!)
Distinguished name of the search base: dc=spinlock,dc=hr
LDAP version to use: 3
Does the LDAP database require login? No
Special LDAP privileges for root? No
Make the configuration file readable/writeable by its owner only? No
Make local root Database admin. No
Does the LDAP database require login? No
Local crypt to use when changing passwords. crypt

To configure the NSS module further, open /etc/libnss-ldap.conf. Locate and adjust the configuration lines as shown:

base dc=spinlock,dc=hr
uri ldap://192.168.7.12/

Finally, to activate the LDAP NSS module, edit /etc/nsswitch.conf by replacing the two lines mentioning passwd and group with the following:

passwd:         files ldap
group:          files ldap

Stop nscd, the Name Service Caching Daemon, but do leave it starting up automatically on the next system boot:

sudo invoke-rc.d nscd stop

Nscd is used to cache metadata locally, instead of querying the LDAP server each time. It is a very efficient service in the long run, but we have disabled it for the moment to always retrieve the data directly from the LDAP server.

Finally, verify LDAP users are now visible:

id mirko
uid=20000(mirko) gid=20000(mirko) groups=20000(mirko)

PAM configuration

The final step in this article pertains to integrating LDAP into the system authentication procedure.

Let's install and configure libpam-ldap. (You might have already done this step automatically, during libnss-ldap installation — in that case Debian will just report the package is already installed).

sudo apt-get install libpam-ldap

Debconf answers for reference:

Make local root Database admin. No
Does the LDAP database require login? No
Local crypt to use when changing passwords. crypt

To configure the PAM module, open /etc/pam_ldap.conf. Locate and adjust the configuration lines as shown:

base dc=spinlock,dc=hr
uri ldap://192.168.7.12/

Now let's configure Linux-PAM itself. PAM configuration is quite fragile, so use the provided examples that have been verified to work. For any modifications, you will want to look at PAM Configuration File Syntax and pay special attention to seemingly insignificant variations — with PAM, they often make a whole world of difference.

PAM will require the user to be present either in the local password file or in LDAP and to know the correct password, for the authentication process to continue.

Note that authentication through LDAP, as shown here, is not secure, due to connections to the LDAP server being made in plain text and passwords travelling over the wire.

Instead of encrypting the connection to the LDAP server, the PAM files shown below also support Kerberos for authentication, if you've installed Kerberos as explained in MIT Kerberos 5 Guide. In that case, modify the PAM lines as noted in file comments and the authentication will be performed in a completely secure and superior manner using Kerberos.

/etc/pam.d/common-account

account sufficient      pam_unix.so
account required        pam_ldap.so

# Enable if using Kerberos:
#account required        pam_krb5.so

/etc/pam.d/common-auth

# Disable the three lines if using Kerberos:
auth [success=1 default=ignore] pam_unix.so nullok_secure
auth required pam_ldap.so use_first_pass
auth required pam_permit.so

# Enable the three lines if using Kerberos:
#auth    sufficient        pam_unix.so nullok_secure
#auth    sufficient        pam_krb5.so use_first_pass
#auth    required          pam_deny.so

/etc/pam.d/common-session

session required        pam_unix.so
session required        pam_mkhomedir.so skel=/etc/skel/ umask=0022

# Enable if using Kerberos:
#session  optional  pam_krb5.so minimum_uid=1000

Logging in into the system

Having everything adjusted as shown, login to the system should succeed as user mirko:

Login: mirko
Password: password

Debian GNU/Linux tty5

Creating directory '/home/mirko'.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
mirko@host:~$

Conclusion

At this point, you have a functional LDAP installation.

You can rely on LDAP for central network authentication and sharing of user metadata (user IDs, group IDs, real names, group memberships, etc.).

However, as said above, the authentication through LDAP is not done in a network-secure manner, due to plain text connections and passwords travelling over the wire. To solve that problem, using Kerberos for network authentication instead of LDAP is recommended, as explained in the previous article in the series, the MIT Kerberos 5 Guide.

When users authenticate successfully, they will be logged in and placed in their home directory. However, in a central network authentication scheme, where users are not created on individual machines, their corresponding home directories will not exist. This problem is taken care of by the pam_mkhomedir module above, which automatically creates missing home directories.

The newest version of this article can always be found at http://techpubs.spinlocksolutions.com/dklar/ldap.html.

Davor Ocelic
http://www.spinlocksolutions.com/

Copyright (C) 2007,2008 Davor Ocelic, <docelic@spinlocksolutions.com>
Spinlock Solutions, http://www.spinlocksolutions.com/

Links

Platforms:
GNU
Debian GNU

Kerberos:
OpenLDAP

Glue layer:
NSS
Linux-PAM

Related infrastructural technologies:
MIT Kerberos

Commercial support:
Spinlock Solutions

Misc:
DocBook

 

 


Posted by Steve (80.68.xx.xx) on Wed 19 Mar 2008 at 10:48
[ Send Message | View Steve's Scratchpad | View Weblogs ]

That was a nice read; and with the addition of LDAP-based password authentication it would have been perfect!

One thing that you glossed over a little was the creation of home directories automatically. We covered that her previously:

Steve

[ Parent | Reply to this comment ]

Posted by docelic (212.15.xx.xx) on Wed 19 Mar 2008 at 17:24
[ Send Message ]
I've added LDAP-based password authentication, so now LDAP as explained in the guide can be used standalone for centralized network logins.

[ Parent | Reply to this comment ]

Posted by joshuadf (74.61.xx.xx) on Wed 19 Mar 2008 at 15:01
[ Send Message ]
This is a great article for understanding what's going on with LDAP (and basically what I'm using right now) but openLDAP is very low-level. I'm hoping to soon switch to FreeIPA which basically wraps the LDAP and Kerberos servers and some friendly management tools. I haven't had the time to try it yet, but they have a 0.99 tarball on the downloads page. Has anyone installed it on Debian?

[ Parent | Reply to this comment ]

Posted by Anonymous (75.166.xx.xx) on Wed 19 Mar 2008 at 17:08
Thanks for the great debian OpenLDAP article. Please consider a future article that extends this installation to support directory services for evolution addressbook.

[ Parent | Reply to this comment ]

Posted by barbacha (82.227.xx.xx) on Wed 19 Mar 2008 at 17:18
[ Send Message ]
Good article !

You could also use lat or directory-administrator to manipulate your directory data. For example, I love lat for it's ability to show views like "samba users" etc.

All three programs (gq included) are available on Debian and Ubuntu. All three have severe bugs in my opinion (crashes upon binding to the OpenLDAP server, and other). So sometimes I have to revert to PHPLdapAdmin to do the stuff.

When I'm in the "geeky" mood, or when I need to make mass-modifications, I use ldapvi. You use it with the same API as ldapsearch or ldapadd and you can edit the result of the search query in $EDITOR (vi by default). Upon saving, ldapvi constructs and applies a LDIF change file.

Happy ldapping all !

Nico

http://www.nbi.fr/

[ Parent | Reply to this comment ]

Posted by procesd (85.58.xx.xx) on Wed 19 Mar 2008 at 19:44
[ Send Message ]
Take a look on phpLdapAdmin (http://phpldapadmin.sourceforge.net/)

PROS:
-Pretty easy configuration (but lot of options once you go deep)
-Have a script pages to automatize creation of particular entries, so if you use a combination of objects and want to assign default values
-Easy and usable interface (have space to improve)

CONTRAS:
-It needs a web browser, not my favourite interface.

[ Parent | Reply to this comment ]

Posted by docelic (78.134.xx.xx) on Wed 19 Mar 2008 at 22:49
[ Send Message ]
CONTRAS:
-It's PHP

[ Parent | Reply to this comment ]

Posted by Anonymous (204.26.xx.xx) on Thu 20 Mar 2008 at 05:30
Very good article.

Although it does add a few additional steps, enabling SSL/TLS for LDAP communication is not particularly difficult, and significantly increases security, especially if you are using LDAP for password authentication. The biggest hassle is generating the SSL cert, signing it, and distributing it to the 'client' machines. Still worth it, IMO.

Two other extremely useful things you can put in LDAP, that I don't think enough people are familiar with, are sudo and automounts. Particularly in a corporate environment, having sudoer information and automount information centralized in an LDAP server is amazingly handy.

[ Parent | Reply to this comment ]

Posted by Anonymous (201.250.xx.xx) on Thu 20 Mar 2008 at 19:06
Creating and Using a self signed SSL Certificates in debian:

http://www.debian-administration.org/articles/284

[ Parent | Reply to this comment ]

Posted by daemon (146.231.xx.xx) on Fri 21 Mar 2008 at 21:46
[ Send Message | View Weblogs ]

Are you talking about something like the sudo-ldap package?

I recently set up a lab of linux machines that allow users to authenticate off an AD domain (not the way I wanted to go, but the domain was all there already). To make things more complicated, I'm only using the AD for kerberos (not nss lookups, which are querying an OpenLDAP install), and I think due to this, I can't seem to get sudo-ldap to work.

My thoughts are that I'll probably have to use GSSAPI authetication for sudo-ldap to work, but I haven't had the time to really test it out fully. Basically, if you're using sudo-ldap, how are you managing the auth'ing, and do you think GSSAPI is the way to go in a situation like mine?

Cheers.

:wq

[ Parent | Reply to this comment ]

Posted by Anonymous (67.168.xx.xx) on Fri 21 Mar 2008 at 21:14
Another great addition is using 'host' attributes to restrict which hosts a user may log into.

If the 'host' attribute isn't available as part of your structural object class' schema, you can add auxiliary object classes (there's a schema included in OpenLDAP) to add hostObject object classes to the entry, in turn allowing you to add the 'host' attribute to any entry you want.

Then, you can specify values like this:

host: ns1.foo.net
host: www.foo.net

And on all of your servers, use the pam_filter option in ldap.conf to specify what filter to use when finding users...

pam_filter &(accountStatus=active)(host=ns1.foo.net)

Only entries with 'host=ns1.foo.net' will be returned when PAM searches, so nobody else will be allowed to log in.

Hope that's useful to someone. Nice article!

[ Parent | Reply to this comment ]

Posted by docelic (78.134.xx.xx) on Fri 21 Mar 2008 at 21:34
[ Send Message ]
Great tip. Like you say, one simple variant is using the existing 'host' attribute by enabling the following in /etc/pam_ldap.conf:

pam_check_host_attr yes

Then under the user's entry in LDAP, adding host: [hostname] for the host where the user is allowed to log in (the hostname must or must not contain the domain name, depending on system setup).

Browsing through pam_ldap.conf is a good exercise in any case, as you can also setup authorization through LDAP (using pam_check_service_attr option).

The other option you mention is good in the event that 'host' isn't available, although that's a bit unlikely on default slapd install in Debian.

[ Parent | Reply to this comment ]

Posted by Anonymous (195.19.xx.xx) on Tue 25 Mar 2008 at 15:15
$ su mirko -c passwd
Password:
passwd: User not known to the underlying authentication module
passwd: password unchanged
$

[ Parent | Reply to this comment ]

Posted by Anonymous (195.19.xx.xx) on Tue 25 Mar 2008 at 16:04
$ cat /etc/pam.d/common-password
password sufficient pam_unix.so nullok md5
password required pam_ldap.so try_first_pass
$

[ Parent | Reply to this comment ]

Posted by Anonymous (195.19.xx.xx) on Tue 25 Mar 2008 at 16:10
$ id mirko
uid=20000(mirko) gid=20000(mirko)id: failed to get groups for user `mirko': No such file or directory

$ su mirk<Tab>
malloc: unknown:0: assertion botched
free: start and end chunk sizes differ
last command: id mirko
Aborting...

why bash crashed? Problem in coreutils?

[ Parent | Reply to this comment ]

Posted by Anonymous (15.219.xx.xx) on Wed 30 Apr 2008 at 03:21
This is a problem with libnss-ldap. try libnss-ldapd.

This came about when they changed from the openssl libraries to the gnutls libraries

[ Parent | Reply to this comment ]

Posted by Anonymous (157.193.xx.xx) on Thu 12 Jun 2008 at 11:36
Thank you! I had the same problem in Hardy Heron! With
apt-get install libnss-ldapd
everything works again.
Greetz
BYPS

[ Parent | Reply to this comment ]

Posted by kroshka (66.253.xx.xx) on Fri 18 Apr 2008 at 21:44
[ Send Message | View Weblogs ]
This is a good read to understand more of ldap, but is outdated with regards to installing it on debian: http://home.subnet.at/~max/ldap/index.php

I have a working ldap setup here. What I need is to introduce a password policy. This howto describes that: http://blog.zrmt.com/index.php/2007/10/19/howto-ppolicy-openldap/ and this is a man page of ppolicy: http://www.openldap.org/software/man.cgi?query=slapo-ppolicy&sekt ion=5&apropos=0&manpath=OpenLDAP+2.4-Release

My problem is just that it seems ppolicy is an overlay for the ldap directory as a whole. I'd need to selectively introduce a policy, say for ou=People, but not for ou=ftpaccounts. I am not able to figure out if this is possible and if so how.

[ Parent | Reply to this comment ]

Posted by Anonymous (201.248.xx.xx) on Sun 15 Jun 2008 at 00:22
This is a great ldap walk-through. I want to just add that the section "NSS configuration" is really the start of the client setup. Perhaps you could add that.

Also, if the client is indeed a separate computer, as will be the case if you are using ldap to do what it's supposed to do, you need to change the "shadow:" line in your /etc/nsswitch.conf file.

from:
shadow: compat

to:
shadow: files ldap

Otherwise you may not be able to log in.

Also I experienced a problem upon first configuring a client. I could sign in with users added to the ldap database only via ssh and not via gnome or gdm. The issue was init 3 and init 5 applications only read nsswitch.conf once at start up, so a restart was needed on the client after initial configuration. Hope this helps someone.

[ Parent | Reply to this comment ]

Posted by Anonymous (67.207.xx.xx) on Wed 24 Sep 2008 at 20:37
It does, thank you. How about connecting from Windows? Any pointers?

[ Parent | Reply to this comment ]

Posted by Anonymous (208.67.xx.xx) on Thu 13 Aug 2009 at 21:58
I second the thank you (a year late but whatever).

[ Parent | Reply to this comment ]

Posted by Anonymous (211.27.xx.xx) on Mon 3 Nov 2008 at 23:39
Thanks, and for the maintained version of this document at Spinrock, too (http://techpubs.spinlocksolutions.com/dklar/ldap.html).

Could you add some information about using the incredibly useful 'memberOf' overlay.

The memberOf overlay allows you to see which groups to which a DN belongs, which can be very useful when using LDAP for web based autentication and your web server only allows you to do a single search (e.g. lighttpd).

e.g. a search could look something like (&(uid=dolly)(memberOf=biggirls)) to return the DN of dolly only if she is a member of the group biggirls. In the case of ligttpd, the server uses the returned DN, and the supplied password, to see it it can authenticate against the directory. If it can, it allows access. (Sorry I have no idea if this is relevant to other web server software such as Apache).

See http://www.openldap.org/doc/admin24/overlays.html for details.

Cheers
Richard

[ Parent | Reply to this comment ]

Posted by docelic (77.237.xx.xx) on Tue 4 Nov 2008 at 00:19
[ Send Message ]
I will add it on next iteration; thanks for a good idea.
Apart from fixes here and there that I've been doing over the time, one other thing I have on the list is, at the end of each guide, summarize which steps are necessary for setting up a server, and which for setting up a client. It seems like people have success following the guides for a 1-server/1-client scenario, but then have trouble figuring out what's the minimum set of changes needed to install another client machine.

[ Parent | Reply to this comment ]

Posted by Anonymous (134.2.xx.xx) on Thu 15 Jan 2009 at 15:24
Hi !
I have followed your tutorial and when I try to add user from the ldif file I get the following error:
adding new entry "cn=oz,ou=group,dc=HiPOS,dc=loc"
ldap_add: No such object (32)
matched DN: dc=HiPOS,dc=loc

adding new entry "uid=oz,ou=people,dc=HiPOS,dc=loc"
ldap_add: No such object (32)
matched DN: dc=HiPOS,dc=loc


the file I created is:
dn: cn=oz,ou=group,dc=HiPOS,dc=loc
cn: oz
gidNumber: 1000
objectClass: top
objectClass: posixGroup


dn: uid=oz,ou=people,dc=HiPOS,dc=loc
uid: oz
uidNumber: 1000
gidNumber: 1000
cn: oz
sn: oz
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
loginShell: /bin/bash
homeDirectory: /shared/home/oz

Will be happy if you can help solving this error:
ldapadd -c -x -D cn=admin,dc=HiPOS,dc=loc -W -f /var/tmp/oz.ldif
Enter LDAP Password:
adding new entry "cn=oz,ou=group,dc=HiPOS,dc=loc"
ldap_add: No such object (32)
matched DN: dc=HiPOS,dc=loc

adding new entry "uid=oz,ou=people,dc=HiPOS,dc=loc"
ldap_add: No such object (32)
matched DN: dc=HiPOS,dc=loc

thanks, Oz

[ Parent | Reply to this comment ]

Posted by docelic (78.134.xx.xx) on Thu 15 Jan 2009 at 15:41
[ Send Message ]
From what I see, I think this is pretty simple. You can't "skip" elements in the path -- in other words, you can't create cn=oz,ou=group,dc=HiPOS,dc=loc before you've created ou=group,dc=HiPOS,dc=loc.

So at the top of your ldif file add:

dn: ou=group,dc=HiPOS,dc=loc
objectClass: top
objectClass: organizationalUnit
ou: group

See if it helps.

[ Parent | Reply to this comment ]

Posted by Anonymous (134.2.xx.xx) on Thu 15 Jan 2009 at 16:08
Partially,
I need to create that group and HiPOS, dc=loc only once.
I am trying to creat a template file for adding users.
In any case here is the situation now:

ldapadd -c -x -D cn=admin,dc=HiPOS,dc=loc -W -f /var/tmp/oz.ldif
Enter LDAP Password:
adding new entry "cn=oz,ou=group,dc=HiPOS,dc=loc"
ldap_add: Already exists (68)

adding new entry "uid=oz,ou=people,dc=HiPOS,dc=loc"
ldap_add: Naming violation (64)
additional info: value of naming attribute 'uid' is not present in entry

master:/# pico /var/tmp/oz.ldif master:/# pico /var/tmp/oz.ldif master:/# ldapadd -c -x -D cn=admin,dc=HiPOS,dc=loc -W -f /var/tmp/oz.ldif
Enter LDAP Password:
adding new entry "cn=oz,ou=group,dc=HiPOS,dc=loc"
ldap_add: Already exists (68)

adding new entry "uid=oz,ou=people,dc=HiPOS,dc=loc"
ldap_add: No such object (32)
matched DN: dc=HiPOS,dc=loc

master:/# ldapsearch -x
# extended LDIF
#
# LDAPv3
# base <dc=HiPOS,dc=loc> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# HiPOS.loc
dn: dc=HiPOS,dc=loc
objectClass: top
objectClass: dcObject
objectClass: organization
o: HiPOS.loc
dc: HiPOS

# admin, HiPOS.loc
dn: cn=admin,dc=HiPOS,dc=loc
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator

# group, HiPOS.loc
dn: ou=group,dc=HiPOS,dc=loc
objectClass: top
objectClass: organizationalUnit
ou:: Z3JvdXAg

# mirko, group, HiPOS.loc
dn: cn=mirko,ou=group,dc=HiPOS,dc=loc
cn: mirko
gidNumber: 20000
objectClass: top
objectClass: posixGroup

# oz, group, HiPOS.loc
dn: cn=oz,ou=group,dc=HiPOS,dc=loc
cn: oz
gidNumber: 20000
objectClass: top
objectClass: posixGroup

# search result
search: 2
result: 0 Success

# numResponses: 6
# numEntries: 5


my file looks like this:
dn: cn=oz,ou=group,dc=HiPOS,dc=loc
cn: oz
gidNumber: 20000
objectClass: top
objectClass: posixGroup

dn: uid=oz,ou=people,dc=HiPOS,dc=loc
uid: oz
uidNumber: 20000
gidNumber: 20000
cn: oz
sn: oz
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
loginShell: /bin/bash
homeDirectory: /shared/home/oz

I hope this helps because I still get this error
adding new entry "uid=oz,ou=people,dc=HiPOS,dc=loc"
ldap_add: No such object (32)
matched DN: dc=HiPOS,dc=loc

Thanks again, Oz

[ Parent | Reply to this comment ]

Posted by docelic (78.134.xx.xx) on Thu 15 Jan 2009 at 16:47
[ Send Message ]
Well now you need to create ou=people in the same way you have
created ou=group (I hear you going "Ah ha!").

This (creation of ou=group and ou=people) is clearly mentioned
in the Guide, in the section "Creating basic tree structure".

Also, if you'll have further LDAP questions, you're welcome to channel
#ldap at IRC network FreeNode. For running issues like yours, it's cleaner
and faster to discuss it there.

[ Parent | Reply to this comment ]

Posted by Anonymous (134.2.xx.xx) on Thu 15 Jan 2009 at 19:30
I am sorry to tell you, but I followed your tutorial step by step, and your suggestion didn't solve my problem.
Kind of desperate by now. I even installed gui manager for ldap but that only made more confused, because there are just too many options.

[ Parent | Reply to this comment ]

Posted by dreuff (81.65.xx.xx) on Sat 14 Feb 2009 at 21:00
[ Send Message ]
Thanks for this great HOWTO, it worked perfectly !

But i have a little problem, i googled a lot about it but didn't find the answer...

I've created a group, 'teammates', and a user who is in it, Allan and all works perfectly, he can log-in nice. I created a second group 'sudoers' and added Allan in it, it works too :
#id allan
uid=20000(allan) gid=20000(teammates) groupes=20000(teammates),20001(sudoers)

In my /etc/sudoers i have %sudoers ALL=(ALL) ALL, but sudo doesn't work for him.
It's not a sudoers configuration issue, if i use %teammates instead of %sudoers, it works perfectly.

Any idea of what's hapenning, and/or where i could find an answer ?

Thanks again for this great article,
regards, dreuff

[ Parent | Reply to this comment ]

Posted by Anonymous (83.202.xx.xx) on Thu 19 Feb 2009 at 15:19
(I finally solved my problem with sudo-ldap)

[ Parent | Reply to this comment ]

Posted by greenmang0 (123.252.xx.xx) on Sat 21 Mar 2009 at 08:09
[ Send Message ]
thanks, this worked flawlessly....

[ Parent | Reply to this comment ]

Posted by Anonymous (118.175.xx.xx) on Fri 5 Feb 2010 at 10:51
Did u get through secure ldap too ? I couldn't do it. Could you help?

[ Parent | Reply to this comment ]

Posted by neverland (118.175.xx.xx) on Fri 5 Feb 2010 at 10:59
[ Send Message ]
I am trying to make secure ldap but using tls/ssl After I run this "slapd -h 'ldap:// ldaps://'; -d1" I got below error messege. please help

*****ERROR MESSEGE START****
>>> slap_listener(ldaps://)
connection_get(15): got connid=7
connection_read(15): checking for input on id=7
connection_get(15): got connid=7
connection_read(15): checking for input on id=7
connection_get(15): got connid=7
connection_read(15): checking for input on id=7
connection_get(15): got connid=7
connection_read(15): checking for input on id=7
connection_read(15): unable to get TLS client DN, error=49 id=7
connection_get(15): got connid=7
connection_read(15): checking for input on id=7
ber_get_next
ber_get_next on fd 15 failed errno=0 (Success)
connection_closing: readying conn=7 sd=15 for close
connection_close: conn=7 sd=15

[ Parent | Reply to this comment ]

Posted by jim_fields (173.49.xx.xx) on Wed 22 Apr 2009 at 03:00
[ Send Message ]
Hello,
I've followed this guide verbatim, but I cant seem to get nss to comm with ldap:
slapd[1913]: nss_ldap: could not connect to any LDAP server as (null) - Can't contact LDAP server
Any pointers?

[ Parent | Reply to this comment ]

Posted by abel (82.183.xx.xx) on Mon 13 Jul 2009 at 17:30
[ Send Message ]
Thanks for a good article and overview. But I have a couple of comments that may be useful to consider for people setting up ldap-servers to use for name services.

1)

Why do most articles and howtos on the web on LDAP authentication not differ between people and accounts? The uid:s are almost always used to identify people. But in reality people can have more accounts than one, even in one organziation. Ok, this may not be a common thing, but it does happen. To resolve this it is useful to have a group of entries that are "accounts". Possibly one can have "people" also, and in that case couple each account to an individual by the roleOccupant attribute.

2)

It may be better to use uidNumber in the distinguished name of an account, rather than uid. As people move on and quit their job or even die, it is useful to be able to reuse uid:s, at least after enough time has passed since a previous user last was employed or so. However, it is important that the ownership of files belonging to a previous user are not automatically transferred to the new user. It may be the case that files are in fact still around even if someone quit some time ago. In fact, for a large organization it is indeed a likely problem. To counter this, the uidNumber should not be reused. Then the ownership of files are always possible to determine as accounts created for a person not longer with the organization still have the uidNumber associated with that person. Similarly, creating entries where the dn is determined by the actual name of the person is not so good. People change names for a number of reason, one common example is that they marry.

3)

As an example of how the layout may be planned consider the following. People and groups within organization Examplecompany are organized into two organizational units, people and groups. Accounts are considered an organizational role that people can have. We have used a few schemas available on standard Debian installs of ldap. It is straigtforward to add an ou for "stuff" where computers, cars, tables or other things may be handled.



dn: ou=people,dc=examplecompany,dc=com
objectClass: top
objectClass: organizationalUnit
ou: people
description: People within examplecompany.com.

dn: ou=groups,dc=examplecompany,dc=com
objectClass: top
objectClass: organizationalUnit
ou: groups
description: Groups within examplecompany.com.

dn: cn=accounts,dc=examplecompany,dc=com
objectClass: top
objectClass: organizationalRole
cn: accounts
description: Computer accounts within examplecompany.com.

dn: employeeNumber=10000,ou=people,dc=examplecompany,dc=com
objectClass: inetOrgPerson
cn: Bruce Campbell
givenName: Bruce
sn: Campbell
displayName: Bruce Campbell
employeeNumber: 10000
homePhone: +1-234-5678901
mobile: +1-234-5678902
mail: bruce@examplecompany.com
title: Dr

dn: employeeNumber=10001,ou=people,dc=examplecompany,dc=com
objectClass: inetOrgPerson
cn: Mary Poppins
givenName: Mary
sn: Poppins
displayName: Mary Poppins
employeeNumber: 10001
homePhone: +1-234-5678903
mobile: +1-234-5678904
mail: mary@examplecompany.com
title: Professor

dn: employeeNumber=10002,ou=people,dc=examplecompany,dc=com
objectClass: inetOrgPerson
cn: Tom Marcus
givenName: Tom
sn: Marcus
displayName: Tom Marcus
employeeNumber: 10002
homePhone: +1-235-4678905
mail: tom@examplecompany.com

dn: uidNumber=10000,cn=accounts,dc=examplecompany,dc=com
objectClass: organizationalRole
objectClass: posixAccount
cn: bruce
uid: bruce
uidNumber: 10000
gidNumber: 10000
homeDirectory: /home/bruce
loginShell: /bin/bash
roleOccupant: employeeNumber=10000,ou=people,dc=examplecompany,dc=com

dn: uidNumber=10001,cn=accounts,dc=examplecompany,dc=com
objectClass: organizationalRole
objectClass: posixAccount
cn: mary
uid: mary
uidNumber: 10001
gidNumber: 10001
homeDirectory: /home/mary
loginShell: /bin/bash
roleOccupant: employeeNumber=10001,ou=people,dc=examplecompany,dc=com

dn: uidNumber=10002,cn=accounts,dc=examplecompany,dc=com
objectClass: organizationalRole
objectClass: posixAccount
cn: tom
uid: tom
uidNumber: 10002
gidNumber: 10002
homeDirectory: /home/tom
loginShell: /bin/bash
roleOccupant: employeeNumber=10002,ou=people,dc=examplecompany,dc=com

dn: gidNumber=10000,ou=groups,dc=examplecompany,dc=com
objectClass: posixGroup
cn: bruce
gidNumber: 10000
description: Group to account bruce.

dn: gidNumber=10001,ou=groups,dc=examplecompany,dc=com
objectClass: posixGroup
cn: mary
gidNumber: 10001
description: Group to account mary.

dn: gidNumber=10002,ou=groups,dc=examplecompany,dc=com
objectClass: posixGroup
cn: tom
gidNumber: 10002
description: Group to account tom.














[ Parent | Reply to this comment ]

Posted by Anonymous (80.229.xx.xx) on Thu 21 Oct 2010 at 11:48
Excellent article, thanks.

I have just one question; when configuring /etc/pam.d/common-auth (without Kerberos), isn't it sufficient to just use the following lines instead:
auth sufficient pam_unix.so nullok_secure
auth required   pam_ldap.so use_first_pass

I'm a newbie, but I can't see why this wouldn't work just as well. Please correct me if I'm wrong.

[ Parent | Reply to this comment ]

Posted by docelic (78.134.xx.xx) on Thu 21 Oct 2010 at 22:21
[ Send Message ]
Yes, seems should work. The config I've shown comes from an installation where it was used in an extended scenario. Regards, -doc

[ Parent | Reply to this comment ]

Posted by Anonymous (59.177.xx.xx) on Wed 9 Feb 2011 at 07:59
LokeshBisht:
Superb and awesome steps for configure ldap..but is you are trying installation in debian/ubuntu please make sure here is command for install

sudo apt-get install slapd ldap-utils libldap-2.4-2 libdb4.6

Libldap2 won't work on Debian/Ubuntu

After this command run #dpkg-reconfigure slapd

then put other information it's work perfectly..

For support mail on lokesh.stu@gmail.com (Welcome)

[ Parent | Reply to this comment ]

Posted by dante (189.123.xx.xx) on Fri 24 Jun 2011 at 18:35
[ Send Message ]
I'd like to know if there is difference between the ldap installation in debian 5 or debian 6. Can I follow this instruction here to install it in both versions? Thanks very much.

[ Parent | Reply to this comment ]

Posted by Anonymous (78.134.xx.xx) on Fri 24 Jun 2011 at 22:09
Not much difference, except that the new slapd packages in Debian now use the cn=config style instead of the old slapd.conf. So, you will need the slaptest utility if you'll want to "port" the changes from slapd.conf into the cn=config tree.

[ Parent | Reply to this comment ]

Sign In

Username:

Password:

[Register|Advanced]

 

Flattr

 

Current Poll

Which init system are you using in Debian?






( 1066 votes ~ 7 comments )