Accessing a shell with LDAP authentication - Revision history

Saruman!: split libnss-ldapd from libpam-ldap

2008-11-13T21:23:44Z

split libnss-ldapd from libpam-ldap

← Older revision		Revision as of 21:23, 13 November 2008
Line 3:		Line 3:
	=== 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'':		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		hostname:~# id root
	uid=0(root) gid=0(root) groups=0(root)		uid=0(root) gid=0(root) groups=0(root)
	id sixpajo		hostname:~# id sixpajo
	id: sixpajo: No such user		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.		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 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		* ''libnss-ldapd'', the NSS module that can use LDAP as a naming service
	* ''libpam-ldap'', the PAM module that allows LDAP interfaces		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.
	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:		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; 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; 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 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.		* 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.		When installing ''libnss-ldapd'', Debian asks the following questions:


	=== 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:		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 ^$		hostname:~# cat /etc/pam_ldap.conf \| grep -v ^# \| grep -v ^$
	base dc=saruman,dc=biz		base dc=saruman,dc=biz
	uri ldap://~~/192~~.~~168~~.67.10		uri ldap://127.0.0.1/
	ldap_version 3		ldap_version 3
	pam_password crypt		pam_password crypt
	Next, check if ''libnss-ldapd.conf'' has the right information as well:		Next, check if ''libnss-ldapd.conf'' has the right information as well:
	cat nss-ldapd.conf \| grep -v ^# \| grep -v ^$		hostname:~# cat nss-ldapd.conf \| grep -v ^# \| grep -v ^$
	uid nslcd		uid nslcd
	gid nslcd		gid nslcd

Saruman!: /* LDAP authentication for SSH */ described AllowGroups

2008-09-28T16:56:14Z

LDAP authentication for SSH: described AllowGroups

← Older revision		Revision as of 16:56, 28 September 2008
Line 76:		Line 76:

	== LDAP authentication for SSH ==		== 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.

Saruman!: /* Configuring PAM for LDAP authentication */ changed for nslcd

2008-09-27T22:18:12Z

Configuring PAM for LDAP authentication: changed for nslcd

← Older revision		Revision as of 22:18, 27 September 2008
Line 34:		Line 34:
	ldap_version 3		ldap_version 3
	pam_password crypt		pam_password crypt
	Next, check if ''libnss-~~ldap~~.conf'' has the right information as well:		Next, check if ''libnss-ldapd.conf'' has the right information as well:
	cat ~~libnss~~-~~ldap~~.conf \| grep -v ^# \| grep -v ^$		cat nss-ldapd.conf \| grep -v ^# \| grep -v ^$
			uid nslcd
			gid nslcd
			uri ldap:///192.168.67.10
	base dc=saruman,dc=biz		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.		All correct, and with [http://en.wikipedia.org/wiki/Advanced_Packaging_Tool APT] we wouldn't expect otherwise.

Line 55:		Line 56:
	session required pam_unix.so		session required pam_unix.so
	session required pam_mkhomedir.so skel=/etc/skel/ umask=0022		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:		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:

Saruman!: /* Testing the new configuration */ changed to nslcd

2008-09-27T22:15:39Z

Testing the new configuration: changed to nslcd

← Older revision		Revision as of 22:15, 27 September 2008
Line 67:		Line 67:

	=== Testing the new configuration ===		=== 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 root and Joe Sixpack:		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		id root
	uid=0(root) gid=0(root) groups=0(root)		uid=0(root) gid=0(root) groups=0(root)
	id sixpacjo		id sixpacjo
	uid=10001(sixpacjo) gid=10001(networkusers) groups=10001(networkusers)		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.		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 ==		== LDAP authentication for SSH ==

Saruman!: /* Testing the new configuration */ added root user

2008-09-27T22:08:42Z

Testing the new configuration: added root user

← Older revision		Revision as of 22:08, 27 September 2008
Line 67:		Line 67:

	=== Testing the new configuration ===		=== 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:		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 root and Joe Sixpack:
			id root
			uid=0(root) gid=0(root) groups=0(root)
	id sixpacjo		id sixpacjo
	uid=10001(sixpacjo) gid=10001(networkusers) groups=10001(networkusers)		uid=10001(sixpacjo) gid=10001(networkusers) groups=10001(networkusers)
	Success!		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.

	== LDAP authentication for SSH ==		== LDAP authentication for SSH ==

Saruman!: Shell access with LDAP added

2008-09-27T22:06:37Z

Shell access with LDAP added

@@ Line 2: / Line 2: @@
 === Preparatory steps ===
 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-ldap'', the NSS module that can use LDAP as a naming service
+* ''libnss-ldapd'', the NSS module that can use LDAP as a naming service
 * ''libpam-ldap'', the PAM module that allows LDAP interfaces
-* ''nscd'', the Name Service Cache Daemon, that handles & caches lookups of passwd/groups/hosts for running programs
+Note: the libnss-ldapd has the other one as dependencies, so you could limit yourself to
-Note: the libnss-ldap has the other two as dependencies, so you could limit yourself to
+  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-ldap'', 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".
-* LDAP protocol version to use: if you're not using this server with ancient applications, LDAP v3 is the best choice.
+* 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:
@@ Line 23: / Line 28: @@
 === Configuring PAM for LDAP authentication ===
 === Configuring NSS to consult the LDAP server ===
 == LDAP authentication for SSH ==

Saruman!: Page started

2008-09-27T18:43:21Z

Page started

New page

== Shell access with LDAP authentication and authorization ==

=== Preparatory steps ===
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-ldap'', the NSS module that can use LDAP as a naming service
* ''libpam-ldap'', the PAM module that allows LDAP interfaces
* ''nscd'', the Name Service Cache Daemon, that handles & caches lookups of passwd/groups/hosts for running programs
Note: the libnss-ldap has the other two as dependencies, so you could limit yourself to
apt-get install libnss-ldap
When installing ''libnss-ldap'', 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".
* LDAP protocol version to use: if you're not using this server with ancient applications, LDAP v3 is the best choice.
* The LDAP account for root: in our example this was "cn=admin,dc=saruman,dc=biz".
* The root LDAP account password.
The libnss-ldap configuration ends with a reminder that for the libnss-ldap package to work, you need to modify your /etc/nsswitch.conf to use the "ldap" datasource. Furthermore, should you ever want to remove this package, it is wise to remove the "ldap" entries from nsswitch.conf to keep basic services functioning.

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 ===

=== Configuring NSS to consult the LDAP server ===

== LDAP authentication for SSH ==