This is my quick summary of how to configure a machine to be a client machine in a centrally managed cluster, as in these computers are clients of other LDAP / Kerberos servers.
There's two ldap packages available for Debian. The older libnss-ldap and libpam-ldap packages and newer libnss-ldapd / libpam-ldapd packages. The older non-d versions have been languishing in Debian's work-needed list for at least a year, and haven't been being maintained that well.
As far as I can tell the maintainer of the d variant occasionally helps fix release critical issues with the older non-d variant.
So what's different between the two? Both connect to ldap through nsswitch & pam, and in general are attepmting to solve the same problem. The big difference is nss-pam-ldapd adds in a daemon whose purpose is to manage connections with the ldap server. This gets you two things, connection pooling, and not needing to duplicate the code in the pam & nssswitch specific modules.
At one point I did see a complaint that the d-variant didn't support ldap nesting groups in a group. However I wasn't using complex group logic, and thus that didn't impact me.
There's also another option with sssd. Its linux only, but supports some more features than nss pam ldapd but it rather wants to work with RedHat's FreeIPA, and unfortunately that is huge collection of packages that haven't been ported to the Debian world yet.
As I'd been using the non-d variant of the ldap modules previously switching to the ldapd version was much simpler.
I would like to investigate credential caching at some point, but haven't gotten around to it.
For any kind of cluster you'll want time keeping software, especially if you want to use Kerberos.
apt-get install openntp | ntpd
Pick whichever one meets your needs.
To configure just LDAP authentication on your client install the pam & nsswitch modules
apt-get install libpam-ldapd libnss-ldapd
The LDAPd debconf scripts helpfully prompt for several of the important configuration options.
For your LDAP server URI you'll need to match the common name you use in your LDAP certifificate. I had requested X.509 certificates based on the domain name, so I had to use the domain name and couldn't use an IP address. (You could also consider requesting certificates based on the IP addresses instead.)
If you put end up listing your ldap servers by DNS name, you may want to list their names in /etc/hosts. Or just accept that the machines wont allow remote logins if DNS is broken.
- LDAP Server
- Specify a list of LDAP servers to query.
- LDAP Search base
- Where you want the root of your LDAP search to be. this is usually going to be something like dc=lab,dc=university,dc=edu or ou=lab or similar.
- Name servers to configure
- pick what databases you want to query LDAP for you probably want at least group, passwd, shadow. I also included netgroup for my configuration.
To use a local certificate authority, you'll should install your certificate root into /usr/local/share/ca-certificate it will neeed to be named <useful name>.crt in the share/ca-certificate directory. When it gets symlinked into /etc/ssl/certs, it will be renamed as <useful name>.pem.
to install the certificate into /etc/ssl/certs.
Once your certificate is ready you should update nslcd.conf to use your certificate authority.
update ssl options
ssl start_tls tls_reqcert hard tls_cacertfile /etc/ssl/certs/<useful name>.pem
Since you should probably require a login to browse what's available in your LDAP server you should probably set up the binddn / bindpw. for example.
binddn cn=proxyuser,dc=example,dc=org bindpw <bind password>
Once that's all done make sure the permissions for nslcd is now
-rw-r----- 1 root nslcd 744 Dec 12 10:39 nslcd.conf
as it contains a password.
Now that everything is configured you should be able to query your LDAP server. first make sure that nslcd has picked up the configuration changes, and then actually query the passwd list.
service nslcd restart getent passwd
You should verify you can see users that are not in your local machines /etc/passwd
recent Debian / Ubuntu machines have been wanting to try to use nfs4 by default. The nfs4 id mapper will, by default use the machines local domain name. However if all your hosts aren't grouped in a single related domain. (e.g. host.lab.university.edu) you may want to investigate manually setting a Domain in /etc/idmap.conf to your administrative domain.
If you also want support for Kerberos, you can also install the following for the MIT version of Kerberos.
Debconf will prompt you for the core kerberos options. you'll need to know what your Kerberos domain is called, what kerberos replicates there are, and which machines support kpasswd.
apt-get install libsasl2-modules-gsspapi-mit krb5-user
- configure kerberos
- kerberos domain
- kerberos servers
- kerberos administrative servers
To get Kerberos working on a you'll need a keytab set you'll probably want to consider the following services
- provides ssh
- needed for nfsv4
- SASL ldap
At least the host/ and nfs/ keys will need to go into the system keytab /etc/krb5.keytab.
to enable kerberos ssh edit /etc/ssh/sshd_config and add the following
GSSAPIAuthentication yes GSSAPICleanupCredentials yes
service sshd restart kinit SSH_AUTH_SOCK= ssh -Kv $(HOST) klist
the ssh command should report: Authentication succeeded (gssapi-with-mic) and once you log in the klist command should show you a ticket on the remote computer like the following.
Ticket cache: FILE:/tmp/krb5cc_1000_GMRx1E7U3s Default principal: diane@EXAMPLE.ORG Valid starting Expires Service principal 05/03/2014 15:07 06/03/2014 15:07 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG
The Debian default is unfortunately to PerimitRootLogin. You should also change your /etc/sshd_config to PermitRootLogin to be at least without-password or even no.