Authentication with LDAP on DragonFly BSD
punosevac72 at gmail.com
Tue Nov 18 01:48:18 PST 2014
LDAP Authentication on DragonFly 4.0 simply works!!! Tested on
[predrag at df ~]$ uname -a
DragonFly df.int.autonlab.org.df.int.autonlab.org 4.1-DEVELOPMENT
DragonFly v126.96.36.199.gd1c25-DEVELOPMENT #0: Mon Nov 3 14:01:11 UTC 2014
root at pkgbox64.dragonflybsd.org:/usr/obj/usr/src/sys/X86_64_GENERIC
In June of this year I spend an evening playing with LDAP on DragonFly
3.8.2. At the time nss_ldap port was missing and after John Marino
added it I have not spend enough time trying to set LDAP client
properly. I needed it today so I carefully went through my configuration
files and put this small howto for myself. It is written in txt2tags so
it can be easily converted into html.
Looking forward to 4.0 release!!!
Using LDAP for authentication on DragonFlyBSD
Last Updated: %%mtime(%A %B %d, %Y)
%!options: --toc --toc-level 2 --css-sugar
In this brief article we describe the configuration of LDAP for
authentication on DragonFlyBSD. The Lightweight Directory Access
Protocol (LDAP for short) is an application protocol for accessing
and maintaining distributed directory information services over an
Internet Protocol (IP) network. In Auton Lab we use LDAP to provide
directory services i.e. to authenticates and authorizes all users and
computers on our network. We mention that authentication (Kerberos)
and authorization (LDAP) can be separated but due to the secure nature
of our internal network we have decided against the use of Kerberos
for more convenience to users and use LDAP for both roles.
In order of DragonFlyBSD to become an LDAP client we must configure
OpenLDAP client, Pluggable Authentication Module (PAM), and Name Service
== Software Installation ==
pkg install openldap-client pam_ldap nss_ldap
=== Note about software configuration ===
DragonFlyBSD users ``/etc/`` directory for system configuration files
while it uses ```/usr/local/etc/`` for package configuration files.
Similarly with start up scripts, ``/etc/rc.d/`` is default location of
system start up scripts while ``/usr/local/etc/rc.d/`` is default
location of package start-up scripts. However both scripts are started
from ``/etc/rc.conf`` file.
== OpenLDAP client configuration ==
OpenLDAP client is configured by editing
``/usr/local/etc/openldap/ldap.conf``. We could use exactly the same
``ldap.conf`` file we used with OpenBSD and Red Hat but we will adjust
it little bit due to the fact that the same file will be base for
configuring ``security/pam_ldap`` and ``net/nss_ldap``.
Note that we now must add certificate files into
``/usr/local/etc/openldap/certs`` directory. The only mandatory file is
``ca.crt`` which is self-signed.
== Authentication: PAM and pam_ldap.so ==
The Pluggable Authentication Module allows integration of various
authentication technologies such as standard UNIX, RSA, DCE, LDAP etc.
into system services such as login, passwd, rlogin, su, ftp, ssh etc.
without changing any of these services.
In our case, the pam_ldap module, implemented in the shared library
pam_ldap.so, allows user and group authentication using an LDAP service.
Each service that needs an authentication facility, can be configured
through the PAM configuration files to use different authentication
methods. This means that it is possible, using the PAM configuration
files, to write a custom list of requirements that an user must satisfy
to obtain access to a resource.
``security/pam_ldap`` is configured via ``/usr/local/etc/ldap.conf``
Note this is a different file than the OpenLDAP library functions'
configuration file, ``/usr/local/etc/openldap/ldap.conf``; however,
it takes many of the same options; in fact it is a superset of that
file. For the rest of this section, references to ``ldap.conf`` will
mean ``/usr/local/etc/ldap.conf``. Thus, we will want to copy all of
our original configuration parameters from ``openldap/ldap.conf``
to the new ``ldap.conf``. Once this is done, we want to tell
``security/pam_ldap`` what to look for on the directory server. We are
identifying our users with the ``uid`` attribute. To configure this
(though it is the default), set the ``pam_login_attribute`` directive
Actual file used in Auton Lab is little bit more complicated.
# nss_override_attribute_value loginShell /bin/sh
=== PAM ===
PAM, which stands for Pluggable Authentication Modules, is the method by
which DragonFlyBSD authenticates most of its sessions. To tell
DragonFlyBSD we wish to use an LDAP server, we will have to add a line
to the appropriate PAM file.
Most of the time the appropriate PAM file is ``/etc/pam.d/sshd``, if you
want to use SSH (remember to set the relevant options in
``/etc/ssh/sshd_config``, otherwise SSH will not use PAM).
Actual ``/etc/pam.d/sshd`` file used in Auton Lab
auth sufficient pam_opie.so no_warn no_fake_prompts
auth requisite pam_opieaccess.so no_warn allow_local
auth sufficient /usr/local/lib/pam_ldap.so no_warn try_first_pass
#auth sufficient pam_krb5.so no_warn try_first_pass
#auth sufficient pam_ssh.so no_warn try_first_pass
auth required pam_unix.so no_warn try_first_pass
account required pam_nologin.so
#account required pam_krb5.so
account required pam_login_access.so
account sufficient /usr/local/lib/pam_ldap.so
account required pam_unix.so
#session optional pam_ssh.so want_agent
session required pam_permit.so
# session required /usr/local/lib/pam_mkhomedir.so
#password sufficient pam_krb5.so no_warn
password sufficient /usr/local/lib/pam_ldap.so
password required pam_unix.so no_warn try_first_pass
Make sure you use set list option in vi editor to see separators. They
are actually tabs not spaces!
== Name Service Switch ==
Once an user is authenticated, many applications still need access
to user information. This information is traditionally contained in
text files (``/etc/passwd``, ``/etc/shadow``, and ``/etc/group``)
but can also be provided by other name services.
As a new name service (such as LDAP) is introduced it can be implemented
either in the C library (as it was for NIS and DNS) or in the
application that wants to use the new nameservice.
Anyway, this can be avoided using a common, general purpose, name
service API and by demanding to a set of libraries the task of
retrieving this information performing technology based operations.
This solution was adopted in the GNU C Library that implements the Name
Service Switch, a method originated from the Sun C library that permits
to obtain information from various name services through a common API.
NSS uses a common API and a configuration file (``/etc/nsswitch.conf``)
in which the name service providers for every supported database
Now that our user information is kept in LDAP, we need to tell NSS to
look there when queried.
The ``net/nss_ldap`` port does this. It uses the same configuration
file as security/pam_ldap, and should not need any extra parameters
once it is installed. We can just copy ``/usr/local/etc/ldap.conf`` to
Finally we edit ``/etc/nsswitch`` as follows
# group: compat
group: files ldap
hosts: files dns
# passwd: compat
passwd: files ldap
and restart ``nsswitch`` and ``sshd``.
More information about the Users