Authentication with LDAP on DragonFly BSD

Tim Darby t+dfbsd at timdarby.net
Tue Nov 18 13:42:59 PST 2014


Thanks for this great write-up! Should this go in the wiki?

Tim

On Tue, Nov 18, 2014 at 2:48 AM, Predrag Punosevac <punosevac72 at gmail.com>
wrote:

> 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 v4.1.0.24.gd1c25-DEVELOPMENT #0: Mon Nov  3 14:01:11 UTC 2014
> root at pkgbox64.dragonflybsd.org:/usr/obj/usr/src/sys/X86_64_GENERIC
> x86_64
>
>
> 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!!!
> Predrag
>
>
> 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
> ----------------------------------------------------------------------
>
> ===Introduction===
> 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``.
> ```
> HOST atlas.int.autonlab.org
> 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 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
> in ``ldap.conf``.
> ```
> pam_login_attribute uid
> ```
> Actual file used in Auton Lab is little bit more complicated.
> ```
> host atlas.int.autonlab.org
> base dc=autonlab,dc=org
> rootbinddn
> # 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      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
> account         required        pam_nologin.so
> #account        required        pam_krb5.so
> account         required        pam_login_access.so
> account         sufficient      /usr/local/lib/pam_ldap.so
> ignore_authinfo_unavail
> account         required        pam_unix.so
>
> # session
> #session        optional        pam_ssh.so              want_agent
> session         required        pam_permit.so
> # session               required        /usr/local/lib/pam_mkhomedir.so
>
> # password
> #password       sufficient      pam_krb5.so             no_warn
> try_first_pass
> password        sufficient      /usr/local/lib/pam_ldap.so
> try_first_pass
> 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
> 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
> /usr/local/etc/nss_ldap.conf``
>
> 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``.
> ---------------------------------------------------------------------
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20141118/a0efd460/attachment-0002.html>


More information about the Users mailing list