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