When you have a number of computers, in a medium/large business, or an over-the-top home setup, and you want to be able to manage a number of user accounts across all these machines, you don’t have many choices.
You can manage each machine separately. This soon gets tedious, and prone to errors or inconsistency.
For linux/unix you have NIS or LDAP. For the windows side of things, there are several cludgy hacks you can use (yes Home Server, I include you in this category) or the official way is to run a server with a domain. This can either be an expensive microsoft product, or a free samba implementation of a domain server. Either way you get the benefits of central management across a number of machines.
I don’t include kerberos in the linux/unix list because kerberos is purely an authentication system. You still need some mechanism if identifying user ID numbers with user login details. Basically this means LDAP or NIS.
NIS is very simple, it does basic management, it provides simple redundancy and is light weight. My one big complaint about NIS is that it seems to give away all the user’s password hashes to anyone that asks. This is such a backward step in security. Since linux moved to having the password in /etc/shadow, it has become impossible for anyone except the superuser to read the password hashes. Someone with a password hash and access to a moderate amount of processing power, or rainbow tables or something can easily nobble several passwords, if not many.
OpenLDAP configuration
The debian default openldap package is a fine starting point. It is configured correctly to serve authentication information. The only thing that isn’t configured is the SSL part. There are many tutorials on how to do this, so I won’t cover this here.
Some things to note:
- Use the debian dpkg configuration to set up the base and administrator account for you LDAP directory.
- Ensure that the nis.schema line is included in /etc/ldap/slapd.conf.
- For large numbers of users, make sure you tune for performance, with indexes etc.
- Check the access lines for your particular configuration.
You need to choose a few things about how your ldap server is to work.
- Is your directory going to be used for other things as well as user authentication? If so, do you want to limit your user accounts to a particular area of the tree?
- Are you going to have different classes of user? There are two ways of achieving this: Separating two different branches of the tree or use of attributes. You can even use a combination of both.
Create any containers that you need for your user accounts:
$ ldapadd -x -D cn=admin,dc=mydomain,dc=com -W Enter LDAP Password: <enter the administration password here> dn: ou=users,dc=mydomain,dc=com ou: users objectClass: top objectClass: organizationalUnit adding new entry "ou=users,dc=mydomain,dc=com"
Create your first user account using ldapadd:
$ ldapadd -x -D cn=admin,dc=mydomain,dc=com -W Enter LDAP Password: <enter the administration password here> dn: uid=taskme,ou=users,dc=mydomain,dc=com uid: taskme objectClass: top objectClass: person objectClass: posixAccount objectClass: shadowAccount objectClass: inetOrgPerson givenName: Task sn: Me loginShell: /bin/bash uidNumber: 1201 gidNumber: 100 shadowMin: -1 shadowMax: 999999 shadowWarning: 7 shadowInactive: -1 shadowExpire: -1 shadowFlag: 0 cn: Task Me homeDirectory: /home/taskme adding new entry "uid=taskme,ou=users,dc=mydomain,dc=com"
As you can see, the entry has all the important parts that you can see in /etc/passwd and /etc/shadow:
uid, uidNumber, gidNumber, loginShell, homeDirectory, and cn which matches to the comment field in the password file.
Now we have a suitable user account, that we can configure to appear as an account on our system.
NSS and PAM
There are two parts that need to be configured correctly. The Name Switching Service provides the fields in the passwd file, the home directory, shell, uid number, default gid number etc. The Pluggable Authentication Module layer provides verification of a users identification, ie matching a username and a password.
Install the two ldap packages, libpam-ldap and libnss-ldap. These two are both configured with configuration files, which clearly had the same source. The files (on debian) are /etc/libnss-ldap.conf and /etc/pam_ldap.conf. It may be possible to configure both with the same configuration file, but sometimes it helps to have differences.
For instance, the NSS information is generally requred to be published and there is not much need to encrypt NSS data, as it is easy to determine. Unless of course, you intend to manage it using the rootbinddn parameter, in which case you will be sending the cn=admin password in the clear.
The PAM information should always be kept secret, so all PAM information should be encrypted using ssl.
File configuration parameters
The dpkg configuration basically sets the base and uri parameters in both /etc/libnss-ldap.conf and /etc/pam_ldap.conf. These are not normally enough to configure a working system. As each file has the same parameters and settings, here are some pointers on what to configure:
OpenLDAP by default can be accessed using anonymous binds, so there is no need to set binddn and bindpw.
If you would like the root user to be able to set and reset passwords, set the rootbinddn parameter appropriately. You should only do this on machines that are well trusted, like the server. Anyone that gains access to these credentials can compromise your entire authentication system. So worth considering where to do this carefully. Also, as mentioned above, you should consider SSL if you intend to use this system across your network.
ssl should be set to on if desired, or start_tls if you have configured this.
tls_checkpeer is set to yes by default. This ensures that the client validates the certification authority for the server. Using the ssl authentication mechanism, this ensures that noone can easily impersonate your server.
tls_cacertdir specifies where your certificate authority certificate resides. If you leave this as the default on your debian system, (/etc/ssl/certs), then you may find a lot of certificates in this directory. This makes searching for the correct CA slow, so I would recommend changing this to another directory with only the relevant CA file(s) in.
You may configure nss_base_passwd, nss_base_shadow and nss_base_group to be more specific to reduce search times. These paramaters take the form of an ldap filter.
Finally, pam_password specifies how a new password is encrypted into the ldap directory. I would recommend md5 or similar, this is equivalent to the has used in /etc/shadow.
Next step, is to configure /etc/nsswitch.conf.
There are two basic ways to do this, the simpliest is to add “ldap” to passwd, group and shadow parameters.
Alternatively you can use the compat mechanism. Simply add three lines:
passwd_compat: ldap shadow_compat: ldap group_compat: ldap
This allows the use of + and – in the /etc/passwd, /etc/shadow and /etc/group files.
To add your ldap users you need to put a single ‘+’ in a line on it’s own in each file (no quotes).
For more flexibility, you can have
+taskme, which would just add one of the ldap users to this machine.
Or you can have a ‘+’ line and a subsequent line ‘-taskme’ to remove that particular user from this machine.
Or you can even have lines like this:
+taskme:::::/home/temporary/taskme:
Which would override the value of the home directory from the ldap directory setting to what is specified in the passwd file.
Now, you should be at the stage where you can see your ldap users in the list of accounts.
$ getent passwd ... taskme:x:1201:100:Task Me:/home/taskme:/bin/bash
All that remains is to configure the PAM side, which is certainly more complicated.
PAM is a wonderful system, which allows you to write arbitrary authentication systems, to allow pretty much any mechanism to authenticate users. This could be passwd/shadow files, or voice recognition, or fingerprint scanners or anything.
PAM also supports resetting passwords.
There are two issues that I see:
- Messing with the PAM configuration is potentially nasty. You can make it impossible to log in to your machine, or possible for anyone to log in without a password. Any changes you make should be thoroughly tested.
- Installing random PAM modules is installing some software that you must have complete trust in. If there is any flaw in that particular module, your system may be vulnerable.
On your debian system, you need to change three files in /etc/pam.d, common-auth, common-password and common-account. Before you change these files, make sure you know what you are doing. The settings that result in PAM should allow you to manage both local and ldap accounts without worrying about what kind it is.
common-account:
account sufficient pam_unix.so account sufficient pam_ldap.so
common-auth:
auth sufficient pam_unix.so nullok_secure auth required pam_ldap.so use_first_pass
common-password:
password sufficient pam_ldap.so password sufficient pam_unix.so nullok obscure md5
So, with these changes you should be able to authenticate your user:
Except that your LDAP user doesn’t have a password yet.
If you have configured the rootbinddn parameter, and it is set correctly, you need merely type passwd taskme as root on the appropriate system.
If you have not done so, you can set the password like so:
$ ldapmodify -x -D cn=admin,dc=mydomain,dc=com -W Enter LDAP Password: <Enter your admin password here> dn: uid=taskme,ou=users,dc=mydomain,dc=com changetype: modify replace: userPassword userPassword: wibble modifying entry "uid=taskme,ou=users,dc=mydomain,dc=com"
Of course, this puts a cleartext password in your database. This is probably a bad idea. Alternatively you can use the slappasswd utility to create a hash of the password, then put this into the ldap directory.
Interestingly, ldap supports multiple values for userPassword. So you could have more than one valid working password for your account. If you are prepared to manage it at the ldap layer.
To confirm it all works:
ssh localhost -l taskme
Advanced Configuration
I like to configure any process I run so that it doesn’t allow anyone outside of my LAN to get any data from it. So even if my firewall fails, then noone can abuse my server from the internet.
So, to the slapd.conf file, I changed the default access line to the following:
access to *
by dn="cn=admin,dc=my,dc=com" write
by peername.ip=192.168.0.0%255.255.255.0 read
by peername.ip=127.0.0.1 read
This ensures that anyone that connects via the internet will not be able to retrieve any data.
However, as a normal user, I was not seeing any of the ldap accounts. Only the root user could see them.
This seemed very peculiar to me. I was unable to determine why this was the case.
This was until I looked in the /etc/hosts file:
127.0.0.1 localhost
127.0.1.1 myhost.mydomain.com myhost
Debian configures the host file so that the name of the machine has IP address 127.0.1.1, which is fine as all 127.* address connect to the localhost.
Except that my access list is only expecting connection from 127.0.0.1, so refused to serve the user data.
To fix this, I simply had to change the last line of my access list to:
by peername.ip=127.0.0.0%255.0.0.0 read
And all was as expected.
Congratulations. You have now configured your system to authenticate your ldap users as local users.
