Part 6 - Directory Services under Linux

Small businesses usually have an abundance of one type of resource and a shortage of others. If your workplace is short of funds but has a relatively large number of technically proficient staff members, setting up a Linux server may be a viable alternative.
A number of pre-packaged, low-cost SBS alternatives based on Linux already exist, including ClarkConnect, SME Server and Novell Open Workgroup Suite Small Business Edition (that’s a mouthful). However, for complete control with minimal cost, you can roll your own server using the multitude of packages available for your favourite Linux distribution.

Caveat emptor

The instructions detailed in this Masterclass should apply to most if not all Linux distributions. For example’s sake, this series
will go through the process of configuring a CentOS 5 system as a small business server, but the applications that are used throughout are available as binaries on most distributions.

If worse comes to worse though, you may have to manually compile some packages mentioned in this guide. This guide will also assume that you know how to install the Linux distribution of your choice and that you have already done so.
If you’re unsure of how to do this, I would recommend that you stick with Microsoft Windows SBS, as the learning curve for rolling your own server is steep. If you wish to ignore this advice though, there are plenty of Linux installation tutorials online (or you could refer to my Mastering Linux series published in APC over 2005-2006).

Single sign-on

Centralised authentication is the key element in being able to easily lock down access to resources within your network. It is the feature that allows your users to use one set of credentials to log on to their workstations, email account, remote access web sites etc.

At the heart of SBS lies the Windows Active Directory, which essentially is an object-oriented database which is accessed via the Lightweight Directory Access Protocol (LDAP). Many of the administrative tools included in an SBS installation directly modify objects within this database — either directly or through LDAP calls.

LDAP is not limited to use on Windows systems (in fact, its origins do come from Unix systems). OpenLDAP is a free and widely used LDAP implementation designed for Linux systems. In general, once OpenLDAP has been configured with a basic database schema and a number of account objects have been added to the database, you can configure various services to provide access to users based on successful authentication with the LDAP server, as opposed to having each service use its own individual authentication database.

OpenLDAP is typically installed by default under most Linux distributions. If for some reason it is not installed, use the package maintenance application for your distro to download and install it (you’ll generally need to install openldap, openldap-servers and openldap-clients binaries). If no packages are available for your distribution, you may have to resort to downloading the source
code.

Configuring OpenLDAP can be a daunting task, so the KISS approach (keep it simple, stupid!) should be adhered to if you’re not familiar with LDAP — you’re not going to easily create a schema as complex as what you see under Active Directory in any short period of time. OpenLDAP’s main configuration file is located at /etc/openldap/slapd.conf. Open this file in your favourite text editor.

The first task is to change the suffix lines to properly identify your authentication realm. Search for the line:

suffix “dc=your-domain,dc=com”

And edit it to reflect a distinguished name that reflects the fully qualified domain name organisation. Assuming that our FQDN is contoso.corp (as has been used previously in this series), the line would be changed to:

suffix    “dc=contoso,dc=corp”

The next line (the rootdn directive) defines the distinguished name (DN) of a user who has unfettered access to the LDAP directory. You should change the line to something like:

rootdn    “cn=root,dc=contoso,dc=corp”

In order to set the password for this root user, bring up another shell and run the slappasswd command. You’ll be prompted to enter your desired password and then confirm it. Upon completing these steps, a hash will be generated. Copy this line into your slapd.conf file nest to the rootpw directive as shown in the following example:

rootpw    {SSHA}+wptsprgJZMDL9dtRiCVqR26624Eu74/

One important thing to remember is that unless Transport Layer Security (TLS) has been enabled, LDAP passwords (including the root DN password) are sent in plain text. Therefore, as a security measure, it’s good practice to comment out the rootpw directive after you have populated your directory.

Once you’ve made these changes, save the configuration file and restart (or start) the ldap daemon (on Red Hat derived distros, “/sbin/service ldap restart” should do this). If you get numerous warnings such as ‘/var/lib/ldap/dn2id.bdb is not owned by “ldap”’ when attempting to start the LDAP daemon, execute the following commands and re-attempt to start the daemon:

chown –R ldap:ldap /var/lib/ldap

These warnings can appear if the file system permissions for OpenLDAP’s database back end have not been properly set upon installation. The other problem that can occur with new installations is when a default database configuration file is not present. If
the DB_CONFIG file is not present under the /var/lib/ldap directory, you need to copy the DB_CONFIG.example file from /etc/openldap and rename it.

Once you’ve successfully started the LDAP daemon, consider configuring your system to automatically start the daemon upon booting (under Red Hat derived systems, “chkconfig --level 2345 ldap on” command).

Adding user accounts and groups

The ldapadd command is used to add users to the directory. Once you’ve authenticated with the directory, you can interactively add objects to the database — but it’s generally easier to prepare a list of objects that you’d like to add in a separate text-based “ldif” file and import them in one hit.

In your favourite text editor, create a new file and add the following lines (substituting the italicised values for ones that more closely reflect your installation):

# Set up the organisation container
dn: dc=contoso,dc=corp
objectclass: dcObject
objectclass: organization
o: Contoso Limited
dc: contoso

# Set up a users container
dn: ou=users,dc=contoso,dc=corp
objectclass: organizationalUnit
ou: Users


# Create a new user
dn: cn=Jarrod Spiga,ou=users,dc=contoso,
dc=corp
objectclass: top
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: shadowAccount
cn: Jarrod Spiga
sn: Spiga
# The Unix login-name for the user
uid: jspiga
gidnumber: 1000
uidnumber: 1000
homedirectory: /home/jspiga
userpassword: {SSHA}iyIpTV02oprUtVWs4TmZnbT5TfGUxGQE

# Create a new group called admins
dn: cn=admins,ou=groups,dc=contoso,dc=corp
objectclass: top
objectclass: posixGroup
cn: admins
gidnumber: 1000
memberuid: jspiga

The first stanza associates various objects and attributes with the “dc=contoso,dc=corp” DN, including a friendly name for
the organisation (via the o: object). The second and third stanzas create organisational units (OUs, similar to those encountered in Active Directory) which will help you to organise things within the directory in a more simple fashion.

The fourth stanza is responsible for adding a user account to the Users OU. The important lines to configure correctly in this stanza are cn: (The canonical name or full name of the user); sn: (The surname of the user); uid: (The Linux/Unix login name for the user); gidnumber: and uidnumber: (The group id and user id numbers you wish to reserve across Linux/Unix systems for the user). Finally, the userpassword: line contains the password for this user’s account. Passwords should be generated in exactly the same manner that you used to generate the rootdn password earlier.

The fifth stanza merely adds the new user to a group called admins.Save this file as ldap.ldif in your home directory and then exit from the text editor.

To import this ldif file into the directory, execute the following command:

ldapadd –x –D “cn=root,dc=contoso,dc=corp” –W –f ~/ldap.ldif

Note the argument to the –D switch — this should be the value assigned to the rootdn directive within the slapd.conf file. After you hit enter,  supply the rootdn password, and the objects should be added to the directory.To confirm that the data has been inserted correctly, run:

ldapsearch –x –b ‘dc=contoso,dc=corp’ ‘(objectclass=*)’

This should return a list of all objects that have been inserted into the directory for your organisation.

Resetting passwords

If a user’s password needs to be changed for some reason, the ldpasswd command can be used to reset passwords. It’s important to note that end users should avoid using this command themselves unless they are familiar with the hashing mechanisms that you’ve set up across your workplace (so far, we’ve only used SSHA hashes). To reset a password, use the following command:

ldappasswd –D “cn=root,dc=contoso,dc=corp” –x –W –S “cn=Jarrod Spiga,ou=users,dc=contoso,dc=corp”

After entering this command, you’ll be prompted to enter in the new password for the user twice and then the password for the rootdn account. If you don’t enter passwords in this order, the reset process will fail.

Configuring workstations

What we’ve done so far is set up the directory and added a user and a group to it. At this stage, our directory is useless unless we have the server and workstations authenticating against it. The following steps need to be configured across all workstations in your network.

Our first task is to ensure that the nss_ldap packages for your distribution are installed (Red Hat and Suse-derived distros call this package “nss_ldap”, while Debian derived distributions call it “libnss-ldap”). If you cannot obtain binary packages for nss_ldap, you can download the source. Next, edit the /etc/ldap.conf file and uncomment and edit the following directives:

• host: This needs to point to the IP address of the server running OpenLDAP (if you’re configuring the server itself, it’s safe to leave the value as 127.0.0.1).
• base: This needs to point to the base DN (eg. cn=contoso, cn=corp).
• rootbinddn: This needs to specify the DN that the system will use to bind to the directory in order to perform authentication lookups. It can be set to the rootdn (eg. cn=root, dc=contoso, dc=corp).
• nss_base_passwd & nss_base_shadow: These directives need to refer to the OU in the directory that all of your user accounts are created under (eg. ou=users,dc=contoso, dc=corp?one).
• nss_base_groups: This should refer to the OU in the directory where your groups are created (eg. ou=groups, dc=contoso, dc=corp).
  

Once you’ve saved your changes, create a file called /etc/ldap.secret where the password for the rootdn account is and configure the permissions on the file so that only the root user can read it.

The following commands should do the trick:

echo “password” > /etc/ldap.secret
chmod 600 /etc/ldap.secret


Next, edit the /etc/nsswitch.conf file and make each of the passwd, shadow and group directives as follows:

passwd:    files    ldap
shadow:    files    ldap
group:      files    ldap

Save your changes and restart the nscd daemon and you should be set. When you attempt to log on to a system with this configuration, the local account database is checked first (via the files argument), and if
the account is not found on the local system, the LDAP directory is then searched. Always keep the files directive before ldap — this guarantees that you’ll be able to log on to the system as the local root user in the event that something goes wrong or the directory is inaccessible.

Stubborn Windows users

All of this is fine assuming that all of the workstations in your organisation are running Linux. But this is rarely the case — there is always someone who just refuses to use Linux and ‘needs’ to use their Windows system for their day-to-day tasks. In cases like this, Samba can be configured to act as a Primary Domain Controller (PDC) that authenticates against the directory service. The basic configuration of Samba itself is fairly straightforward, and we’ll only be dealing with the authentication side of things in this article.

The first step is to import the LDAP schema extensions that Samba requires by copying the samba.schema file (found at /usr/share/doc/samba-<version>/LDAP/ under Red Hat-based systems or under examples/LDAP/ under the source distribution) to the /etc/openldap/schema directory.

Next, edit the/etc/openldap/slapd.conf file and add the following line towards the top of the configuration:

include         /etc/openldap/schema/samba.schema

Save and then restart the ldap daemon. Next, edit the /etc/samba/smb.conf file and change or add the following lines so that they correlate with your OpenLDAP instance:

passdb backend = ldapsam:ldap://127.0.0.1

ldap admin dn = uid=samba,ou=services,dc=contoso,dc=corp

ldap suffix = dc=contoso,dc=corp

ldap user suffix = ou=users

ldap group suffix = ou=groups

ldap idmap suffix = ou=idmap

ldap machine suffix = ou=computers

ldap replication sleep = 1000

ldap passwd sync = true

ldapsam:trusted = true

Save the changes to your Samba configuration and then create another couple of OUs within your directory in the same manner that you created OUs for your Users and Groups — one for “idmap” and the other for “computers”.

A new directory account should be set up for specific use by Samba — one that has slightly elevated permissions over a regular user in order to be able to create computer objects within the directory. Pop the following text into a samba.ldif file in root’s home directory and import the ldif in the same way that you did earlier, again generating the password using the slappasswd command:

dn: cn=samba,ou=services,dc=contoso,dc=corp

objectClass: top

objectClass: account

objectClass: posixAccount

cn: Samba Server

uid: samba

uidNumber: 3000

gidNumber: 3000

homeDirectory: /tmp
userpassword: {SSHA}iyIpTV02oprUtVWs4TmZnbT5TfGUxGQE


Once this account has been created, Samba needs to know what password it needs to use to bind to the directory. To do this, issue the command:

smbpasswd –w <password>

The samba account (as well as any administrator accounts) then needs to be configured with the required elevated privileges within OpenLDAP. In addition, NT password hashes should be hidden from regular users. To make both of these changes, open slapd.conf and add:

access to *

by dn=”cn=Jarrod Spiga,ou=users,dc=contoso,dc=corp” write

by dn=”cn=samba,ou=services,dc=contoso,dc=corp” write

by * read

access to attrs=sambaLMPassword,sambaNTPassword

by dn=”cn=samba,ou=services,dc=contoso,dc=corp” write

by * none

After restarting both Samba and OpenLDAP, you should be able to use Windows Explorer to connect to any share that you have set up on your Linux server using credentials that are stored in the directory
.