LDAP Authentication In Linux

Want to support HowtoForge? Become a subscriber!
 
Submitted by tdi (Contact Author) (Forums) on Thu, 2006-08-24 11:02. :: Other

LDAP Authentication In Linux

This howto will show you howto store your users in LDAP and authenticate some of the services against it. I will not show howto install particular packages, as it is distribution/system dependant. I will focus on "pure" configuration of all componenets needed to have LDAP authentication/storage of users. The howto assumes somehow, that you are migrating from a regular passwd/shadow authentication, but it is also suitable for people who do it from scratch.

Requirements

Introducion

The thing we want to achieve is to have our users stored in LDAP, authenticated against LDAP ( direct or pam ) and have some tool to manage this in a human understandable way.

This way we can use all software, which has ldap support or fallback to PAM ldap module, which will act as a PAM->LDAP gateway.

More information on LDAP idea can be found on Wikipedia: LDAP wikipedia

Configuring OpenLDAP

OpenLDAP consists of slapd and slurpd daemon. This howto covers one LDAP server without a replication, so we will focus only on slapd. I also assume you installed and initialized your openldap installation (depends on system/disribution). If so, let's go to configuration part.

On my system (Gentoo), openldap's configuration is stored in /etc/openldap, we are interested in /etc/openldap/slapd.conf file. But first we have to generate a password for LDAP administrator, to put it into the config file:

slappasswd -h {md5}

The config looks like this:
include         /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
allow bind_v2

pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args

modulepath /usr/lib/openldap/openldap

access to attrs=userPassword
by dn="uid=root,ou=People,dc=domain,dc=com" write
by dn="cn=Manager,dc=domain,dc=com" write
by anonymous auth
by self write
by * none

access to dn.base="" by * read

access to *
by dn="cn=Manager,dc=domain,dc=com" write
by * read


database bdb
suffix "dc=domain,dc=com"
rootdn "cn=Manager,dc=domain,dc=com" rootpw {MD5}Tk1sMytv5ipjr+Vhcf03JQ==

directory /var/lib/openldap-data
index objectClass eq

Remember to change suffix and paths to your needs.

These are basic options with some basic ACLs needed to change passwrods by user. If you want more functionality, please read the manual about openLDAP. Now when we have a proper config for slapd, we can start the daemon :

/etc/init.d/slapd start

Please remember to have something like that in the config file responsible for arguments passed to the slapd (the path should point to the slapd.sock):

OPTS="-h 'ldaps:// ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock'"

Now we can test if openldap is running and working properly. We do not have any data yet in the directory, but we can try to bind as cn=Manager,dc=domain,dc=com. When you are asked for password, you should use the one you generated (of course the plain text version of it :):

ldapsearch -D "cn=Manager,dc=domain,dc=com" -W

Migrate/Add data to the directory

Now when we have a running LDAP server, we have to fill it with data, either create or migrate entries. I will show you howto migrate existing entries from regular /etc/passwd, /etc/shadow , /etc/groups

The first step is to configure mogrationtools to your needs. The configuration file on gentoo is located in /usr/share/migrationtools/migrate_common.ph.

Generally you need to change only these:
$DEFAULT_BASE = "dc=domain,dc=com";
$EXTENDED_SCHEMA = 1;

Now you are ready to migrate the data (actually it works even without the export command):

export ETC_SHADOW=/etc/shadow
./migrate_base.pl > /tmp/base.ldif
./migrate_group.pl /etc/group /tmp/group.ldif
./migrate_hosts.pl /etc/hosts /tmp/hosts.ldif
./migrate_passwd.pl /etc/passwd /tmp/passwd.ldif

Now we have the data in the format understood by LDAP server. Please open one the files with text editor to get used to the syntax. After that we can add the data from ldifs.

ldapadd -D "cn=Manager,dc=domain,dc=com" -W -f /tmp/base.ldif

ldapadd -D "cn=Manager,dc=domain,dc=com" -W -f /tmp/group.ldif

ldapadd -D "cn=Manager,dc=domain,dc=com" -W -f /tmp/passwd.ldif

ldapadd -D "cn=Manager,dc=domain,dc=com" -W -f /tmp/hosts.ldif

You can try searching for some data:

ldapsearch uid=foouser

Client configuration

By client I mean the machine, which connects to LDAP server to get users and authorize. It can be also the machine, the ldap server runs on. In both cases we have to edit three files : /etc/ldap.conf, /etc/nsswitch.conf and /etc/pam.d/system-auth

Let's start woth ldap.conf, the ldap's client:

BASE    dc=domain, dc=com
scope sub
suffix "dc=domain,dc=com"

## when you want to change user's password by root
rootbinddn cn=Manager,dc=domain,dc=com

## there are needed when your ldap dies
timelimit 5
bind_timelimit 5

uri ldap://ldap.domain.com/
pam_password exop

ldap_version 3
pam_filter objectclass=posixAccount
pam_login_attribute uid
pam_member_attribute memberuid

nss_base_passwd ou=Computers,dc=cognifide,dc=pl
nss_base_passwd ou=People,dc=cognifide,dc=pl
nss_base_shadow ou=People,dc=cognifide,dc=pl
nss_base_group ou=Group,dc=cognifide,dc=pl
nss_base_hosts ou=Hosts,dc=cognifide,dc=pl

Now it is time for nsswitch.conf and pam

Add these to nsswitch.conf:
passwd: files ldap
shadow: files ldap
group: files ldap
And change the system-auth (or hatever you have like login, sshd etc) to :
auth       required     pam_env.so
auth sufficient pam_unix.so likeauth nullok
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so

account sufficient pam_unix.so
account sufficient pam_ldap.so
account required pam_ldap.so

password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3
password sufficient pam_unix.so nullok md5 shadow use_authtok
password sufficient pam_ldap.so use_first_pass
password required pam_deny.so

session required pam_limits.so
session required pam_unix.so
session optional pam_ldap.so

Time to test it. The best tool for it is a good old getent. Pick a user from your system and issue:

getent passwd | grep foouser

You should get the result twice, if so the nss_ldap works fine. The pam part can be tested by deleting a user from the /etc/passwd and trying to log in through ssh.

Apache mod_auth_ldap

To have LDAP authorization in apache, you have to load mod_auth_ldap module

LoadModule mm_auth_ldap_module modules/mod_auth_ldap.so

Now it is enought to make .htaccess like that:

AuthName "Restricted"
AuthType Basic
AuthLDAPURL ldap://ldap.domain.com:389/ou=People,dc=domain,dc=com?uid
AuthLDAPBindDN "cn=Manager,dc=domain,dc=com"
AuthLDAPBindPassword "your_secret_secret_password_to_ldap_admin"
require valid-user

Note that this method can be also used for webdav subversion authorization

Administration tools for ldap

There are few tool I recommend using to administrate OpenLDAP server

Other ldap aware applications

  • Postfix
  • Courier IMAP
  • jabberd
  • eGroupware
  • Summary

    If someone has something to add, please do it. I know the configuration may not be perfect.


Please do not use the comment function to ask for help! If you need help, please use our forum.
Comments will be published after administrator approval.
Submitted by Anonymous (not registered) on Thu, 2013-10-24 12:31.
Hi , i configured ldap client to search from ldap server, now i want to authenticate any user who want to login into my linux system using Ldap. please can somebody tell me the steps to do..
Submitted by Anonymous (not registered) on Fri, 2010-07-09 18:37.

Given that the PADL migration scripts don't specify a minimum UID or GID for migration, and that one may wish to use an LDAP store across multiple distros where UIDs and GIDs may not always be the same at install, and where new accounts may be created during the installation of software, how much of that data should we really have in our LDAP servers?

The gentoo ldap document even goes so far as to test the function of nss-ldap after migration by using getent to test for multiple root accounts.

 As far as I can imagine, the only groups and users we should have in LDAP are those which are associated with human and automated logins which we wish to administrate from a central location and wish to make available across systems and/or applications.

 However, where an account needs to be a part of a group created by the system, this brings up the obvious question. Either location we decide to locate this information creates a potential for inconsistency. The lesser of two evils appears to be to add LDAP users to file based groups on a system by system basis, which then creates another type of management overhead.

 If we are to keep all the migrated information in LDAP, then do we leave all or some of the duplicated entries in the system? Do we leave system sensitive accounts such as root in LDAP?

It isn't a good idea to remove the root account (among others) from the system files as tempting a thought as it is to have a centrally managed root password (there are better ways to deal with root access anyway), and how do we then manage the concept of multiple distributions with differing uid/gid setups? Much of the latter has been mitigated by a fairly standard stock set of uid/gid mappings, and through the creation of many accounts on an install basis. I am not sure at all that any given package will check first to see that an account/group has been previously created via some reliable method (getent) before performing a creation, which could create another overhead in administration.

What are your experiences with, and solutions to, managing authentication data across a collection of systems using LDAP?

Submitted by Borwinius (not registered) on Thu, 2009-02-19 13:10.

i would use an account with minimal rights to recursive searching from the LDAP.

Your "Manager" should only created for this function an should not have an right to interactive logon.

 

Submitted by Anonymous (not registered) on Thu, 2008-11-27 05:24.

Don't understand why I'm getting this after generating the LDIFs from migration tools:

ldapadd -D "cn=admin,dc=home-network" -W -f /tmp/passwd.ldif -x -c
Enter LDAP Password:
adding new entry "uid=root,ou=People,dc=home-network"
ldap_add: Invalid syntax (21)
    additional info: objectClass: value #5 invalid per syntax

adding new entry "uid=daemon,ou=People,dc=home-network"
ldap_add: Invalid syntax (21)
    additional info: objectClass: value #5 invalid per syntax

adding new entry "uid=bin,ou=People,dc=home-network"
ldap_add: Invalid syntax (21)
    additional info: objectClass: value #5 invalid per syntax

adding new entry "uid=sys,ou=People,dc=home-network"
ldap_add: Invalid syntax (21)
    additional info: objectClass: value #5 invalid per syntax

...Lot's more of the above

Any ideas why this is happening and how to fix it?

Submitted by Anonymous (not registered) on Fri, 2011-12-23 11:28.
Use this,

  ldapadd -x -h <LDAP IP Address> -D cn=xxxx,dc=xxx,dc=xxx,dc=xxx -f  /xxx/xxx.ldif -W

It works to me.
Submitted by Joerg Ryska (not registered) on Fri, 2009-04-24 15:54.

I had the same Problem in Debian Lenny and found an answer as a comment from another www-user - look at:
http://www.stanford.edu/services/directory/openldap/configuration/custom-schema.html
and include the mentioned 
http://www.stanford.edu/services/directory/openldap/configuration/krb5-kdc.schema
as schema into your slapd.conf - this file isn't installed with e.g. Debian Packages - so You have to do it manually.
Hope, this helps ;-)

Submitted by crazyivan (registered user) on Sat, 2009-11-21 17:37.
This is certainly the solution. Maybe Debian can add this scheme to the migration tools package? 
Submitted by Anonymous (not registered) on Fri, 2008-11-28 02:42.

that error comes becouse you don't have a schema included in your slapd.conf for kerberos5 authentications.

You have to remove all lines with krb5 occurrences in /tmp/passwd.ldif

 I spent some time to understand it...

Submitted by djtremors (registered user) on Tue, 2008-01-22 13:39.

OPTS="-h 'ldaps:// ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock'"

There is no sock file on CentOS5. I also had to put 'bind_policy soft' in /etc/ldapd.conf otherwise ldap wouldn't start and hang forever but now just keeps dumping into logs :

Jan 22 23:43:46 hybrid runuser: nss_ldap: failed to bind to LDAP server ldap://domain.local/: Can't contact LDAP server Jan 22 23:43:46 hybrid runuser: nss_ldap: could not search LDAP server - Server is unavailable Jan 22 23:43:46 hybrid runuser: nss_ldap: failed to bind to LDAP server ldap://domain.local/: Can't contact LDAP server Jan 22 23:43:46 hybrid runuser: nss_ldap: could not search LDAP server - Server is unavailable Jan 22 23:43:46 hybrid slapd[16452]: nss_ldap: failed to bind to LDAP server ldap://domain.local/: Can't contact LDAP server Jan 22 23:43:46 hybrid slapd[16452]: nss_ldap: could not search LDAP server - Server is unavailable Jan 22 23:43:46 hybrid slapd[16452]: nss_ldap: failed to bind to LDAP server ldap://domain.local/: Can't contact LDAP server Jan 22 23:43:46 hybrid slapd[16452]: nss_ldap: could not search LDAP server - Server is unavailable

Submitted by bruno.vernay (registered user) on Wed, 2006-09-20 21:34.

Nice work, thank you !

You may add a note that on Fedora, migrations tools are in /usr/share/openldap/migration/

Add references to others (of good quality too) like http://www.grennan.com/ldap-HOWTO.html