Difference between revisions of "LDAP authentication"

From ArchWiki
Jump to: navigation, search
m (Install OpenLDAP)
m (Bot: Removing from Category:HOWTOs (English))
Line 1: Line 1:
 
[[Category:Security (English)]]
 
[[Category:Security (English)]]
[[Category:HOWTOs (English)]]
 
 
{{Poor writing}}
 
{{Poor writing}}
  

Revision as of 17:49, 10 June 2011

Tango-edit-clear.pngThis article or section needs language, wiki syntax or style improvements.Tango-edit-clear.png

Reason: please use the first argument of the template to provide a brief explanation. (Discuss in Talk:LDAP authentication#)

HOWTO - LDAP Authentication in Arch Linux

Overview

What you need to install, configure, and know, to get LDAP RFC 2251 Authentication working on Arch.

Steps:

  1. Install OpenLDAP
  2. Design LDAP Directory
  3. Configure and Fill OpenLDAP
  4. Configure NSS
  5. Configure PAM

References

http://aqua.subnet.at/~max/ldap/

For the newbies

If you are totally new to those concepts, here is an good introduction that is easy to understand and that will get you started, even if you are new to everything LDAP.

http://www.brennan.id.au/20-Shared_Address_Book_LDAP.html

Install OpenLDAP

This part is easy:

pacman -S openldap 

The openldap package basically contains two things: The LDAP server (slapd) and the LDAP client. You will probably want to run the server on your computer. After you design the directory, the server will be able to provide authentication services for LDAP clients. It is quite likely that you will run services reauiring the LDAP authentication on that very computer, in which case the LDAP client will query the LDAP server from the same package.

Configure OpenLDAP

The server (slapd)

You can start the server like any other daemon, by executing

/etc/rc.d/slapd start

There are two config files you may have to edit, though:

/etc/openldap/slapd.conf

You can define the access rules here, the root "user" etc.

If you want to use SSL, you have to specify a path to your certificates here.

/etc/conf.d/slapd

Very important, you define here on which port the server should listen and if you want to use SSL, you will want to use the ldaps:// URI instead of the default ldap:// You can also specify additional slapd options here.

The client

The client is usually not such a big deal, just keep in mind that your apps that require LDAP auth use it, so if something goes wrong with LDAP, don't waste your time with the app, start debugging the client instead.

The client config file is located at /etc/openldap/ldap.conf It is actually very simple.

If you decide to use SSL:

  • The protocol (ldap or ldaps) in the URI entry has to conform with the slapd configuration
  • If you decide to use self-signed certificates, you have to add them to TLS_CACERT

Test your new OpenLDAP installation

This is easy, just run the command below:

ldapsearch -x -D <root dn from slapd.conf> -W

You should get at least some output, containing the line

result: 0 Success // Could anyone actually confirm this? I don't have a clean LDAP directory to test this with it...

Just for the basic insight, the -x option means "use simple authentication", you specify the dn you want to bind to with the -D switch and -W means "prompt for password"

Design LDAP Directory

This all depends on what organization your network/computer is modeling.

Here is my initial layout in LDIF Format
dn: dc=tklogic,dc=net
dc: tklogic 
description: The techknowlogic.net Network
objectClass: dcObject
objectClass: organization
o: techknowlogic.net 

dn: ou=People,dc=tklogic,dc=net
ou: People
objectClass: organizationalUnit

dn: ou=Groups, dc=tklogic,dc=net
ou: Groups
objectClass: top
objectClass: organizationalUnit

dn: cn=tklusers,ou=Groups,dc=tklogic,dc=net
gidNumber: 2000
objectClass: posixGroup
objectClass: top
cn: tklusers

dn: ou=Roles,dc=tklogic,dc=net
ou: Roles
description: Org Unit for holding a basic set of ACL Roles.
objectClass: top
objectClass: organizationalUnit

dn: cn=ldap-reader,ou=Roles,dc=tklogic,dc=net
userPassword: {CRYPT}xxxxxxxxxxxxx
objectClass: organizationalRole
objectClass: simpleSecurityObject
cn: ldap-reader
description: LDAP reader user for any unrestricted reads (i.e. for NSS)

dn: cn=ldap-manager,ou=Roles,dc=tklogic,dc=net
userPassword: {CRYPT}xxxxxxxxxxxxx
objectClass: organizationalRole
objectClass: simpleSecurityObject
cn: ldap-manager
description: LDAP manager user for any unrestricted read/writes (i.e. root-like)
Now for each user:
dn: uid=user,ou=People,dc=tklogic,dc=net
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: user
cn: Test User
sn: User
givenName: Test
title: Guinea Pig
telephoneNumber: +0 000 000 0000
mobile: +0 000 000 0000
postalAddress: AddressLine1$AddressLine2$AddressLine3
userPassword: {CRYPT}xxxxxxxxxx
labeledURI: http://test.tklogic.net/
loginShell: /bin/bash
uidNumber: 10000
gidNumber: 2000
homeDirectory: /users/test/
description: A Test User for the ArchWiki LDAP-Authentication HOWTO

Configure and Fill OpenLDAP

Client Side

/etc/openldap/ldap.conf

BASE    dc=yourdomain,dc=com
URI     ldap://yourdomain.com

/etc/pam_ldap.conf and /etc/nss_ldap.conf

If there is an actual difference between these files, please let me know.

>> There's not. In Gentoo we use only one /etc/ldap.conf file, so I made hardlinks on these two, using only one file it works. Wonder why Arch has it separated. Anybody knows?

>>> Actually I have moved the /etc/nss_ldap.conf to /etc/ldap.conf. /etc/openldap/ldap.conf and /etc/nss_ldap.conf are only sym-links to /etc/ldap.conf. Works fine for me.

host yourdomain.com
base dc=yourdomain,dc=com
uri ldap://yourdomain.com/
ldap_version 3
rootbinddn cn=Manager,dc=yourdomain,dc=com
scope sub
timelimit 5
bind_timelimit 5
nss_reconnect_tries 2
pam_login_attribute uid
pam_member_attribute gid
pam_password md5
pam_password exop
nss_base_passwd		ou=People,dc=yourdomain,dc=com
nss_base_shadow		ou=People,dc=yourdomain,dc=com

/etc/ldap.secret

plaintextpassword

Chmod to 600


Server Side

/etc/openldap/slapd.conf

include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/nis.schema
include         /etc/openldap/schema/courier.schema
allow bind_v2
password-hash {md5}
pidfile   /var/run/slapd.pid
argsfile  /var/run/slapd.args
database        bdb
suffix          "dc=yourdomain,dc=com"
rootdn          "cn=Manager,dc=yourdomain,dc=com"
rootpw          password (Use slappasswd -h {MD5} -s passwordstring)
directory       /var/lib/openldap/openldap-data
index   objectClass     eq
index   uid     eq

Configure NSS

/etc/nsswitch.conf

passwd:         files
group:          files
hosts:          dns
services:   files 
networks:   files 
protocols:  files 
rpc:        files 
ethers:     files 
netmasks:   files
bootparams: files
publickey:  files
automount:  files
aliases:    files
sendmailvars:   files
netgroup:   file

/etc/nsswitch.ldap

passwd:         files ldap
group:          files ldap
hosts:          dns ldap
services:   ldap [NOTFOUND=return] files
networks:   ldap [NOTFOUND=return] files
protocols:  ldap [NOTFOUND=return] files
rpc:        ldap [NOTFOUND=return] files
ethers:     ldap [NOTFOUND=return] files
netmasks:   files
bootparams: files
publickey:  files
automount:  files
sendmailvars:   files
netgroup:   ldap [NOTFOUND=return] files


/etc/rc.sysinit

Be sure to modify this file before you reboot or your machine will hang on "Starting UDev Daemon"

Add this before UDev starts

cp /etc/nsswitch.file /etc/nsswitch.conf

And this after UDev is started

cp /etc/nsswitch.ldap /etc/nsswitch.conf

Hopefully there will be a fix later.

udev / ldap boot update -> please see: http://wiki.archlinux.org/index.php/Udev-ldap_workaround </pre>

Alternative Fix

If you don't require LDAP to discover your host is to have the nsswitch.conf read

hosts:          files dns

this will bypass the need to modify /etc/rc.sysinit and not hang on boot

Configure PAM

This is what my files look like. It may not be exactly right, but it works on my systems.

/etc/pam.d/login

auth            requisite       pam_securetty.so
auth            requisite       pam_nologin.so
auth            sufficient      pam_ldap.so
auth            required        pam_unix.so use_first_pass
auth            required        pam_tally.so onerr=succeed file=/var/log/faillog
account         required        pam_access.so
account         required        pam_time.so
account         required        pam_unix.so
account         sufficient      pam_ldap.so 
password        sufficient      pam_ldap.so
session         required        pam_mkhomedir.so skel=/etc/skel/ umask=0022
session         required        pam_unix.so
session         required        pam_env.so
session         required        pam_motd.so
session         required        pam_limits.so
session         optional        pam_mail.so dir=/var/spool/mail standard
session         sufficient      pam_ldap.so 
session         optional        pam_lastlog.so

/etc/pam.d/shadow

auth            sufficient      pam_rootok.so
auth            required        pam_unix.so
auth            sufficient      pam_ldap.so use_first_pass
account         required        pam_unix.so
account         sufficient      pam_ldap.so
session         required        pam_unix.so
session         sufficient      pam_ldap.so
password        sufficient      pam_ldap.so
password        required        pam_permit.so

/etc/pam.d/passwd

password        sufficient      pam_ldap.so 
password        required        pam_unix.so shadow nullok

/etc/pam.d/su

auth            sufficient      pam_rootok.so
auth            sufficient      pam_ldap.so
auth            required        pam_unix.so use_first_pass
account         sufficient      pam_ldap.so
account         required        pam_unix.so
session         sufficient      pam_ldap.so
session         required        pam_unix.so

Note: pam_rootok.so must come before pam_ldap.so, otherwise startup scripts like '/etc/rc.d/postgres' ask for a password

/etc/pam.d/sudo

auth            sufficient      pam_ldap.so
auth            required        pam_unix.so use_first_pass
auth            required        pam_nologin.so

/etc/pam.d/sshd

auth            required        pam_nologin.so
auth            sufficient      pam_ldap.so 
auth            required        pam_env.so
auth            required        pam_unix.so use_first_pass
account         sufficient      pam_ldap.so
account         required        pam_unix.so
account         required        pam_time.so
password        required        pam_ldap.so 
password        required        pam_unix.so
session         required        pam_mkhomedir.so skel=/etc/skel/ umask=0022
session         required        pam_unix_session.so
session         sufficient      pam_ldap.so 
session         required        pam_limits.so

Troubleshooting

After migrating to LDAP or updating an LDAP-backed system udevd can hang at boot at the message "Starting UDev Daemon". This is usually caused by udevd trying to look up a name from LDAP but failing, because the network is not up yet. The solution is to ensure that all system group names are present locally.

Extract the group names referenced in udev rules and the group names actually present on the system:

# fgrep -r GROUP /etc/udev/rules.d/ /lib/udev/rules.d | perl -nle '/GROUP\s*=\s*"(.*?)"/ && print $1;' | sort | uniq > udev_groups
# cut -f1 -d: /etc/gshadow /etc/group | sort | uniq > present_groups

To see the differences, do a side-by-side diff:

# diff -y present_groups udev_groups
...
network							      <
nobody							      <
ntp							      <
optical								optical
power							      |	pcscd
rfkill							      <
root								root
scanner								scanner
smmsp							      <
storage								storage
...

In this case, the pcscd group is for some reason not present in the system. Add the missing groups:

# groupadd pcscd

Also, make sure local resources are looked up before resorting to LDAP. Template:Filename should contain the line

group: files ldap