OpenLDAP is enterprise-level software with the great benefit of providing a central point for configuring credentials as well as managing an organisation. By default, OpenLDAP operates on nothing more than a tree structure allowing a manager or administrator to add any type of components: for instance, you can define users, you can define groups, you can define departments, sub-departments and even hardware and equipment if you so desire all with the extra benefit of providing a central point of authentication for various services that the organisation may be running.
This tutorial is rather Debian-centric because Debian provides a lot of the necessary software as packages without having to mess with compiling and manually installing packages although the rough install procedure should apply to any distribution.
On Debian, the required packages can be installed with:
aptitude install slapd libnss-ldapd ca-certificates
where:
slapd
is the standalone OpenLDAP daemon,libpam-ldapd
and libnss-ldapd
will help authentication through Linux PAM.ca-certificates
are the root CA certificates required by SSL/TLS.
When slapd
installs, it will ask for an administrator password - the requested password is not in any way related to the Linux root
password but should be equally or if not more important since if other services will use OpenLDAP for authentication, then compromising the LDAP administration password could compromise the entire organization.
However, slapd
on Debian will assume the entire local Top-Level Domain (TLD) as the single Domain Component (DC) and it is customary to also include the hostname of the machine running OpenLDAP.
Create the file /etc/ldap/ldap.conf
with the following contents:
# # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. BASE dc=ldap,dc=home URI ldap://192.168.0.1 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never # TLS certificates (needed for GnuTLS) TLS_CACERT /etc/ssl/certs/ca-certificates.crt
This file assumes that:
ldap.home
- where home
is the TLD, in this case, a non-existing domain name with only the internal network as its scope.192.168.0.1
.Next, issue:
dpkg-reconfigure -plow slapd
and now perform the same configuration when you installed slapd
whilst entering ldap.home
or equivalent for the domain name and home
for the organization.
If all steps have been performed correctly, you can issue:
slapcat
and at the very top you should see:
dn: dc=ldap,dc=home objectClass: top objectClass: dcObject objectClass: organization o: home dc: ldap structuralObjectClass: organization ... dn: cn=admin,dc=ldap,dc=home objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator
which means that:
dc=ldap,dc=home
,cn=admin,dc=ldap,dc=home
(the Common Name (CN) of the administrator being admin
).The setup of a bare-bones LDAP server based on OpenLDAP is now complete.
Whilst terminal commands are available to configure the LDAP structure, it is convenient to have a graphical interface that can enumerate the contents of LDAP and to add new components without having to write text files. One such tool is phpLDAPAdmin which can be installed by issuing:
aptitude install phpldapadmin
phpLDAPAdmin now has to be configured by editing /etc/phpldapadmin/config.php
. In order to tell phpLDAPAdmin where to find the LDAP server, the following configuration has to be made:
$servers->setValue('server','host','192.168.0.1');
Next, the LDAP base has to specified via the following setting:
$servers->setValue('server','base',array('dc=ldap,dc=home'));
Finally, the administrator DN has to be specified:
$servers->setValue('login','bind_id','cn=admin,dc=ldap,dc=home');
The file can now be saved and you can navigate to http://192.168.0.1/phpldapadmin
in order to log-in and manage LDAP. phpLDAPAdmin will prompt for the administrator DN which, in this case, will be cn=admin,dc=ldap,dc=home
and the password will be the one set when configuring the slapd
package.
One of the cool features of LDAP is that LDAP can now be used as an authentication backend and many software packages have extensions that allow them to authenticate via an LDAP server. For instance, you may have a bunch of Linux machines to which a given set of users have access but you do not want to create local accounts for every user. In this case, Pluggable Authentication Modules (PAM) can be used to perform authentication against LDAP.
On Debian, issue:
aptitude install libpam-ldapd
to install the LDAP PAM module.
Debian will prompt to configure libpam-ldapd
and the following parameters can be entered:
ldap://192.168.0.1
),dc=ldap,dc=home
)
and on the last screen when the configuration tool prompts to update /etc/nsswitch.conf
select all the options (this step is not needed just for password authentication but the settings do not hurt regardless).
On Debian, a file must be created that will instruct PAM to add a module to its configuration that will create a home directory for new users that first log-in to the machine. This is necessary because users that are not created locally do not have a home directory by default. In order to add the module, create the file /usr/share/pam-configs/mkhomedir
with the following contents:
Name: Create home directory during login Default: yes Priority: 0 Session-Interactive-Only: yes Session-Type: Additional Session-Final: optional pam_mkhomedir.so
and issue:
pam-auth-update
Finally, issue:
dpkg-reconfigure nslcd
and specify:
ldap://192.168.0.1
),dc=ldap,dc=home
),simple
for authentication,cn=admin,dc=ldap,dc=home
).
followed the by the administrator password - no StartTLS
is necessary.
nslcd
scans the entire LDAP registry starting from the search base (dc=ldap,dc=home
) and searches for users. It does not matter on what leaf of the tree they are found, nslcd
will accept authenticating any defined users.
The next step is to create users:
ldapscripts
which are command-line utilities to facilitate managing users via LDAP.
To use ldapscripts
, install them via:
aptitude install ldapscripts
Here is a short list of tools included in the ldapscripts
package:
ldapadduser
- for adding an user, ex.: ldapadduser system users
(add an user system
with group name users
),ldapsetpasswd
- for changing the password of an user, ex.: ldapsetpasswd system
(change the password for the user system
),ldapdeleteuser
- for deleting an user, ex.: ldapdeleteuser system
(delete the user system
),ldapaddgroup
- for adding a group, ex.: ldapaddgroup users
(add the group named users
),ldapaddusertogroup
- for adding an user to a group, ex.: ldapaddusertogroup system users
(add the user system
to group users
),ldapdeleteuserfromgroup
- for deleting an user from a group, ex.: ldapdeleteuserfromgroup system users
.There are more commands available, to see them all, issue:
apt-file list ldapscripts | grep bin
When users or groups are created via LDAP and then used by PAM-LDAP, the users and groups behave as if they exist on the local system. For that reason, if you already have users and group defined, and you happen to pick an UID or GID in LDAP that has the same value as an existing local user or group then the local user and group will take precedence and instead of logging-in as the LDAP user or group, you will end up logging-in as a local user instead. This can be particularly harmful in case some of your users are configured with administrative permissions, say, via /etc/sudoers
.
To prevent clashes, before creating users, check out /etc/adduser.conf
and look for (Debian defaults):
FIRST_SYSTEM_UID=100 LAST_SYSTEM_UID=999 FIRST_SYSTEM_GID=100 LAST_SYSTEM_GID=999
These settings imply that system users have UIDs and GIDs in the 100
to 999
range. In this case, you probably do not want to create an LDAP user with an UID or GID in that range or you may end up impersonating a system user.
The other settings to look for in /etc/adduser.conf
are (Debian defaults):
FIRST_UID=1000 LAST_UID=29999 FIRST_GID=1000 LAST_GID=29999
which means that common users range with UID and GID between 1000
and 29999
.
One decision would be to have LDAP users and groups with IDs over 30000
or narrow the settings in /etc/addusers.conf
depending on how may users are expected to login to a machine. A different approach is based on the USERS_GID
setting:
USERS_GID=100
which states that if USERGROUPS
is not set to yes
, then new users are automatically added to the group with GID 100
- which corresponds to the literal users
in /etc/groups
.
A lot of frustration can arise from nscd
which is the caching component of nslcd
. In case the authentication fails, attempt to restart nscd
via:
systemctl nscd restart
nscd
caches credentials such that if you have made a configuration change, the old credentials may have been cached and will not be released until after nscd
is restarted.
With an LDAP server installed, on other Linux machines meant to use the LDAP server, only the libpam-ldapd
package is needed:
aptitude install libpam-ldapd
which should pull nslcd
and nscd
as dependencies.
The search base of the LDAP server will have to be configured (in this case dc=ldap,dc=home
) followed by selecting the changes to /etc/nsswitch.conf
.
Next, create the /usr/share/pam-configs/mkhomedir
file with the contents from the Linux Authentication section and then issue:
pam-auth-update
followed by:
dpkg-reconfigure nslcd
where you will have to enter the LDAP address of the server, the LDAP search base and the administrator DN configured in the previous sections.
Finally, restart the services with:
/etc/init.d/nslcd restart /etc/init.d/nscd restart
and you should be able to log-in with users created on the LDAP server.