Accessing a shell with LDAP authentication: Difference between revisions
(Page started) |
(Shell access with LDAP added) |
||
Line 2: | Line 2: | ||
=== Preparatory steps === | === 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'': | |||
id root | |||
uid=0(root) gid=0(root) groups=0(root) | |||
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 is: | 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 is: | ||
* ''libnss- | * ''libnss-ldapd'', the NSS module that can use LDAP as a naming service | ||
* ''libpam-ldap'', the PAM module that allows LDAP interfaces | * ''libpam-ldap'', the PAM module that allows LDAP interfaces | ||
Note: the libnss-ldapd has the other one as dependencies, so you could limit yourself to | |||
Note: the libnss- | apt-get install libnss-ldapd | ||
apt-get install libnss-ldap | Note 2: 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 differenc in the implementation of either. | ||
When installing ''libnss- | |||
When installing ''libnss-ldapd'', Debian asks the following questions: | |||
* the LDAP server Uniform Resource Identifier; you can submit ''ldap:///192.168.67.10'' 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 LDAP server Uniform Resource Identifier; you can submit ''ldap:///192.168.67.10'' 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 DN of the LDAP search base: in our example this was "dc=saruman,dc=biz". | ||
* LDAP | * a list of services for which to enable LDAP lookups; select services ''group'', ''passwd'' and ''shadow'' - which should be the default. | ||
Next is the libpam-ldap configuration: | Next is the libpam-ldap configuration: | ||
Line 23: | Line 28: | ||
=== Configuring PAM for LDAP authentication === | === 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: | |||
cat /etc/pam_ldap.conf | grep -v ^# | grep -v ^$ | |||
base dc=saruman,dc=biz | |||
uri ldap:///192.168.67.10 | |||
ldap_version 3 | |||
pam_password crypt | |||
Next, check if ''libnss-ldap.conf'' has the right information as well: | |||
cat libnss-ldap.conf | grep -v ^# | grep -v ^$ | |||
base dc=saruman,dc=biz | |||
uri ldap:///192.168.67.10 | |||
ldap_version 3 | |||
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 === | === 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 ''nscd'' 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 nscd stop''. If we now test for the presence of Joe Sixpack: | |||
id sixpacjo | |||
uid=10001(sixpacjo) gid=10001(networkusers) groups=10001(networkusers) | |||
Success! | |||
== LDAP authentication for SSH == | == LDAP authentication for SSH == |
Revision as of 23:06, 27 September 2008
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:
id root uid=0(root) gid=0(root) groups=0(root) 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 is:
- libnss-ldapd, the NSS module that can use LDAP as a naming service
- libpam-ldap, the PAM module that allows LDAP interfaces
Note: the libnss-ldapd has the other one as dependencies, so you could limit yourself to
apt-get install libnss-ldapd
Note 2: 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 differenc in the implementation of either.
When installing libnss-ldapd, Debian asks the following questions:
- the LDAP server Uniform Resource Identifier; you can submit ldap:///192.168.67.10 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".
- a list of services for which to enable LDAP lookups; select services group, passwd and shadow - which should be the default.
Next is the libpam-ldap configuration:
- Make root database owner: default is yes, but we choose "no".
- Does the LDAP database require login: as long as we haven't disabled anonymous queries, it does not. We can answer "no".
Funny enough, if we run dpkg-reconfigure after installation, we get more 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:
cat /etc/pam_ldap.conf | grep -v ^# | grep -v ^$ base dc=saruman,dc=biz uri ldap:///192.168.67.10 ldap_version 3 pam_password crypt
Next, check if libnss-ldap.conf has the right information as well:
cat libnss-ldap.conf | grep -v ^# | grep -v ^$ base dc=saruman,dc=biz uri ldap:///192.168.67.10 ldap_version 3
All correct, and with 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 nscd 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 nscd stop. If we now test for the presence of Joe Sixpack:
id sixpacjo uid=10001(sixpacjo) gid=10001(networkusers) groups=10001(networkusers)
Success!