[plug] LDAP

[Craig Ringer]

On Fri, 2005-02-11 at 03:54 +0000, Simon Scott wrote:
> Id be interested in this as well. I found very few beginner's resources for
> it, and basically learned from installing openldap and phpldapadmin, and then
> battling through installing pam_ldap etc. Its one of those technologies where
> after a while the zen of it just 'clicks' :)
> 
> It definitely worthwhile, but the main problem Ive found is that most of the
> ldap administration tools are not task specific (ie, there's no ldap user
> admin tool AFAIK) so you end up editing accounts etc through a generic editor.
> 
> My local lan now authenticates pretty much everything via ldap, including
> samba, pam, proftpd, phpgroupware, courier-imap etc. The fact that there are
> only 2 users is of secondary importance :)
> 
> Just remember not to shift your root account into LDAP and make sure your
> nsswitch is set to use files as well as LDAP. If anything goes wrong with the
> LDAP server, you can still login to fix it :)

My experience was similar. I was unable to locate any beginner
resources, and just stumbled through until it started making sense.

If you're used to relational databases, forget all that while dealing
with LDAP and you'll be doing yourself a big favour. LDAP directories
are tree of entities, each of which has one or more attributes. There's
no relational-style stucture here, and trying to think of it that way
will only confuse you further.

If you're looking to use LDAP for user accounts, I find
directory_administrator (http://diradmin.open-it.org/index.php) to be a
useful too, though unfortunately not extensible to cover site specific
issues.

The thing that frustrates me the most about LDAP is the lack of widely
used task-specific schema. Everything seems to be "roll your own" beyond
a few things like authentication and staff directories. This flexibility
is nice, but some common schemas for basic uses would be nicer. I'm yet
to even get my mail aliases into LDAP with postfix, for example.

Despite this mild frustration, I find LDAP to be a lifesaver for network
management.

If you're looking to authenticate agianst LDAP, your clients will
probably want _both_ libpam_ldap and libnss_ldap (Debian names). You'll
also probably want to set the client's default server and base DN
in /etc/ldap/ldap.conf (may be /etc/openldap/client.conf instead, distro
dependent - argh). Also, ldapsearch needs the '-x' argument to work with
basic (non-SASL) authentication, so initial testing can be done with
that before you get TLS ("SSL" though they're not the same thing) and
SASL up and running.

There's also a useful trick in the PAM configuration that makes PAM fail
gracefully and still permit root logins if it can't contact the LDAP
server. Thanks for pointing this out, Cameron.

Most distros have shared PAM include files so I'm going to assume those
are present, speficially the Debian ones. I'm also assuming you only
want to use traditional UNIX authentication and LDAP authentication,
though the scheme is easy to extend to other types.

Your auth section should look like:

auth [success=1 default=ignore] pam_unix.so
auth required pam_ldap.so use_first_pass
auth required pam_permit.so

The use of pam_permit.so here freaks me out, but is apparently ok since
authentication will always fail or succeed at pam_ldap. What this does
is check the user against the UNIX password/shadow files first. If they
authenticate OK, the pam_ldap check is skipped causing them to hit
pam_permit. If they fail the check against pam_unix, they're
authenticated against pam_ldap.

As far as I can see you could get the same effect from:

auth [success=done default=ignore] pam_unix.so
auth required pam_ldap.so use_first_pass

so I'm not really clear on why the first approach was suggested. I'd be
interested to find out.

The other sections look similar:

account [success=1 default=ignore] pam_unix.so
account required pam_ldap.so
account required pam_permit.so

password   sufficient pam_ldap.so
password   required   pam_unix.so

session sufficient      pam_ldap.so
session required        pam_unix.so

and if you're setting up LDAP authentication, don't forget to tweak
nsswitch.conf too. I'm using:

passwd:         files [NOTFOUND=continue] ldap
group:          files [NOTFOUND=continue] ldap
shadow:         files [NOTFOUND=continue] ldap

('compat' having been replaced with 'files'). I understand some folks
keep using 'compat' but I recall issues with this in the past, though I
must admit they're escaping me now.

The client side is the easy bit, though ;-) . It's getting the LDAP
server populated with the data you want that can be tricky, largly due
to a general lack of user level documentation for LDAP. I'd consider
starting out with something like directory_administrator.

Also, remember that for directory testing, ldapsearch is your friend. A
simple:

ldapsearch -x -h ${ldap_server} -b ${base_dn}

will at least confirm the server is running, responding to requests, and
give you a chance to look at what's in the directory. If your ldap.conf
on the client is correct you should be able to just do:

ldapsearch -x

and get the same result. If you have SASL set up (please do) then you
can omit the -x too.

--
Craig Ringer