Authentication with LDAP on DragonFly BSD

Predrag Punosevac punosevac72 at
Tue Nov 18 01:48:18 PST 2014

LDAP Authentication on DragonFly 4.0 simply works!!! Tested on 

[predrag at df ~]$ uname -a
DragonFly v4.1.0.24.gd1c25-DEVELOPMENT #0: Mon Nov  3 14:01:11 UTC 2014
root at

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
Predrag Punosevac
Last Updated: %%mtime(%A %B %d, %Y)
%!target: xhtml
%!options: --toc --toc-level 2 --css-sugar
%!style: t2t.css

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
Switch (NSS)

== Software Installation ==

We install 
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``.
BASE dc=autonlab,dc=org
TLS_CACERT /usr/local/etc/openldap/certs/ca.crt
TLS_REQCERT     allow
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 ==

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, 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
in ``ldap.conf``.
pam_login_attribute uid
Actual file used in Auton Lab is little bit more complicated.
base dc=autonlab,dc=org
# nss_override_attribute_value loginShell /bin/sh
nss_base_passwd dc=autonlab,dc=org
nss_base_group dc=autonlab,dc=org
ssl start_tls
tls_cacertfile /usr/local/etc/openldap/certs/ca.crt
ldap_version 3
timelimit 30
bind_timelimit 30
bind_policy soft
pam_ldap_attribute uid
=== 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             no_warn no_fake_prompts
auth            requisite       no_warn allow_local
auth            sufficient      /usr/local/lib/      no_warn try_first_pass
#auth           sufficient             no_warn try_first_pass
#auth           sufficient              no_warn try_first_pass
auth            required             no_warn try_first_pass

# account
account         required
#account        required
account         required
account         sufficient      /usr/local/lib/
account         required

# session
#session        optional              want_agent
session         required
# session               required        /usr/local/lib/ 

# password
#password       sufficient             no_warn
password        sufficient      /usr/local/lib/
password        required             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
are specified.

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
group_compat: nis
hosts: files dns
networks: files
# passwd: compat
passwd: files ldap
passwd_compat: nis
shells: files
services: compat
services: files
services_compat: nis
protocols: files
rpc: files
and restart ``nsswitch`` and ``sshd``.

More information about the Users mailing list