View source for Accessing a shell with LDAP authentication

== Shell access with LDAP authentication and authorization ==

=== Preparatory steps ===
Before we configure the use of LDAP, we confirm that the Linux system knows the ''root'' account, but does not know any ''sixpajo'' account. We do this with the command ''id'':
 hostname:~# id root
 uid=0(root) gid=0(root) groups=0(root)
 hostname:~# id sixpajo
 id: sixpajo: No such user
Yes, exactly what we'd expect. But once we've enabled LDAP, we expect the second command to return a valid user.

To be able to use the LDAP database for authentication, we must have the right software. So as usual, we install it using ''apt-get'' or ''aptitude''. The software we need consists of two packages:
* ''libpam-ldap'', the PAM module that allows LDAP interfaces
* ''libnss-ldapd'', the NSS module that can use LDAP as a naming service
Note: some HOWTO's speak of ''libnss-ldap'' and the separate package ''nscd''; however since there were some problems switching libraries from SSL to TLS, the ''libnss-ldap'' project forked ''libnss-ldapd''. And when you install ''libnss-ldapd'', you automatically get ''nslcd''  That extra "d" thus matters a lot :-) However, since all these files depend on a single configuration file (either ''nss-ldapd.conf'' or ''nss-ldap.conf'') there is little difference in the implementation of either.

We suggest you start by installing ''libpam-ldap''. Installing it will make your Debian package manager (debconf) ask you a couple of questions.
* the LDAP server Uniform Resource Identifier; it'll suggest ''ldapi:///'', but you should submit ''ldap://127.0.0.1/'' or whatever the IP address on your LDAP server's internal NIC is. Note: use "ldap:" and not "ldapi:". The difference is "ldapi:" signals LDAP over a Unix socket (and, to be complete, "ldaps:" signals LDAP over SSL).
* the DN of the LDAP search base: in our example this was "dc=saruman,dc=biz".
* the verions of the LDAP protocol to use - only when you have pressing reasons to use version 2 should you do so; version 3 should always be your LDAP protocol version.
* whether the local root user gets to be database admin: usually you'll answer "yes"; this makes dpkg-reconfigure store the LDAP admin user password in a file ''/etc/ldap.secret''; this file is secured so that only user root can read it. However, with certain custom setups this might not be the best idea. The example dpkg-reconfigure itself offers is that of an NFS mounted ''/etc'' directory: NFS hasn't got proper security, so the database admin password could be up for grabs. In those cases, you shouldn't do this. We don't cover these custom cases though; we just answer "yes".
* whether the LDAP database requires login; in other words, wheter anonymous binds are disallowed. We allow anonymous binds, so we can answer the default of "no".
* Next, you'll be asked the LDAP administrator account and password, e.g. "cn=admin,dc=saruman,dc=biz" and "wEt3udes". The former gets stored in the configuration file, the latter is stored in unencrypted form in a separate file, that is readable only for user root.
After these questions, you can see the configuration file ''/etc/pam_ldap.conf'' having been created, and (if you've chosen local root to get database admin powers) ''pam_ldap.secret''. You can always use ''dpkg-reconfigure'' to re-answer all these questions. The only notable thing is that you'll then get a bonus question:
* what "local crypt" to use when passwords must be changed; the default is "crypt", the standard Linux password encryption method, but other options are a.o. "exop" (LDAP extended operation) and "md5".

Next up, we'll install
* a list of services for which to enable LDAP lookups; select services ''group'', ''passwd'' and ''shadow'' - which should be the default.


When installing ''libnss-ldapd'', Debian asks the following questions:


=== Configuring PAM for LDAP authentication ===
First, let's check if the Debian installation has used the right information. Check ''/etc/pam_ldap.conf'' to contain the correct information on your LDAP server. If you run the correct cat-and-grep, you should see something like this:
 hostname:~# cat /etc/pam_ldap.conf | grep -v ^# | grep -v ^$
 base dc=saruman,dc=biz
 uri ldap://127.0.0.1/
 ldap_version 3
 pam_password crypt
Next, check if ''libnss-ldapd.conf'' has the right information as well:
 hostname:~# cat nss-ldapd.conf | grep -v ^# | grep -v ^$
 uid nslcd
 gid nslcd
 uri ldap:///192.168.67.10
 base dc=saruman,dc=biz
All correct, and with [http://en.wikipedia.org/wiki/Advanced_Packaging_Tool APT] we wouldn't expect otherwise.

Now we'll configure PAM to use LDAP. This means editing PAM configuration files in ''/etc/pam.d''. '''BE CAREFUL!''' Since PAM is quite fragile, it breaks easily when you make small mistakes in these files!

In ''/etc/pam.d/common-account'', change ''account-required pam_unix.so'' into
 account sufficient      pam_unix.so
 account required        pam_ldap.so

In ''/etc/pam.d/common-auth'', change ''auth required pam_unix.so nullok_secure'' into
 auth [success=1 default=ignore] pam_unix.so nullok_secure
 auth required           pam_ldap.so use_first_pass
 auth required           pam_permit.so

In ''/etc/pam.d/common-session'', add a line after ''session required pam_unix.so'' so you get
 session required        pam_unix.so
 session required        pam_mkhomedir.so skel=/etc/skel/ umask=0022

=== Configuring NSS to consult the LDAP server ===
To change NSS, we only have to change ''/etc/nsswitch.conf''. There are multiple entries in there, but we're only interested in the two lines that start with ''passwd:'', ''group:'' and ''shadow''. Probably they look like this:
 passwd:         compat
 group:          compat
 shadow:         compat
This means that for password, group and shadow information, the system will look into the normal files, and if no suitable answer is found there, in Sun's ancient NIS database. We don't employ NIS, but we do want to employ LDAP, so we change these three lines to:
 passwd:         files ldap
 group:          files ldap
 shadow:         files ldap

=== Testing the new configuration ===
The ''nslcd'' program is very nice for caching and generally speeding up all things LDAP, but when testing we don't want it to interfere. Stop the daemon with ''sudo invoke-rc.d nslcd stop''. If we now test for the presence of root and Joe Sixpack:
 id root
 uid=0(root) gid=0(root) groups=0(root)
 id sixpacjo
 uid=10001(sixpacjo) gid=10001(networkusers) groups=10001(networkusers)
Success! Root is still read from the Linux files (no object with a UID of "root" exists in your LDAP, at least not if you've followed this Wiki), and Joe Sixpack's account is found from the LDAP server. Note that if you restart your server, ''nslcd'' will be running automatically again. If you don't want to restart your server any time soon, you can manually start the ''nslcd'' daemon with ''sudo invoke-rc.d nslcd start''.

== LDAP authentication for SSH ==

By default, your Debian 5.0 "Lenny" setup is all ready to receive LDAP users. This is because by default the line
 usePAM yes
is present; this makes SSH use the PAM settings in ''/etc/pam.d/sshd'', which point to the standard PAM login methods "common-auth", "common-account" and "common-session". Thus, all settings you've made for shell access via the console automatically apply for SSH as well.

However, if you've configured your SSH server [[OpenSSH_server | as we've outlined here]], then to actually allow certain users, you need two distinct steps, that you've either performed already, or will need to do now:
# add all LDAP users that you want to allow SSH acces to one or more LDAP groups, e.g. "ldapwheel";
# add those group or groups to your SSH configuration in the ''AllowGroup'' line, e.g. ''AllowGroup wheel ldapwheel''.
Ofcourse, if you've edited ''sshd_config'', you'll need to restart the SSH server.