Simplify Administration with Directory Services

By on Wednesday, February 1st, 2012 in Technical | Related Software Packages: , , , , , , | Keywords: ,

A directory service stores information about users and other entities, such as clients and printers, in a database that maps values to names and vice versa. This data offers a centralized repository that you can use to simplify network security management. Directory services, properly implemented, lessen the possibility of chaos and disorder on a large network.

How does a directory service simplify an administrator’s job? Imagine a hundred-user network where people come and go, and you, the systems administrator, have to create and delete users not only for access to the operating system but on the many applications that also require authorization. This can become a time-consuming nightmare. One important use of directory services is storing usernames and passwords in a centralized location, relieving you of a significant burden.

I’ll focus here on OpenLDAP, one widely used directory service. Like that of any directory service, the OpenLDAP database is relatively small, and read and searched much more than it’s written. You can use LDAP in conjunction with DNS, email, or Samba servers, but our examples will focus on basic username/password management.

To install OpenLDAP on a CentOS server, run

yum install openldap-servers openldap-clients nss_ldap

slapd is the binary for the OpenLDAP server. I recommend you also install software for time synchronization (NTP), since accurate time is essential to authentication if you plan to use Kerberos for authentication services.

To see what an OpenLDAP entry looks like, type slapcat as root to get a look at the contents of the slapd database.

Once the software is installed, open /etc/openldap/ldap.conf and edit some basic settings for your clients. There are two commented lines, one starting with “BASE,” the other with “URI.” Uncomment them and replace the values below with your domain and server address:

BASE    dc=mydom,dc=ain
URI     ldap://ldap.mydom.ain
#You can use ldap://ldap.mydom.ain:portnumber if you need to change the default port, which is 389

Test the settings you altered with ldapsearch -x. If the command exits gracefully with no error messages, you can move on. But before creating slapd.conf, the file with the server settings, let’s take care of some essential terminology.

You have seen in the example before the use of what is known in the LDAP world as entries (the “dc=…” part). An entry is nothing but a pair of labels in the form “attribute=value.” For example, a list of employees in a company might take the same pair form: “CEO=John Doe,CFO=Jane Doe,CTO=Joe Hack” and so on. This format is called LDAP Data Interchange Format (LDIF). To implement a simple “telephone book” system with LDAP, a sample entry for one user might look like:

uid: jdoe
cn: John Doe
userPassword: {crypt}$!(*^*(&*!^*&^*&!^*%%465465143 # you generate this with slappaswd. and of course, the password will look way different.
loginShell: /bin/ksh
uidNumber: 1234
gidNumber: 1234
homeDirectory: /home/jdoe

A couple of other important attributes are distinguished name – a name that uniquely identifies an entry in the directory – and domain component – a “piece by piece” representation of a domain name. You’ve seen what a dc entry might look like; here’s a dn entry for our John Doe:

dn: uid=jdoe,ou=Programming,dc=mydom,dc=ain

What does this tell you about John Doe? Since ou stands for “organizational unit,” it means he’s a programmer. The dc part will help some other systems that might use OpenLDAP, such as a mail server that will know that the address of John Doe is jdoe@mydom.ain. When creating headers for new email messages, the mailserver can use the common name (cn) as needed, so the recipient of John’s messages will see “From: John Doe (jdoe@mydom.ain).”

Here’s a sample slapd.conf, heavily commented.

#######################################################################
# Global Directives:
include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/inetorgperson.schema

pidfile         /var/run/slapd/slapd.pid
argsfile        /var/run/slapd/slapd.args
loglevel        none
modulepath      /usr/lib/ldap
# I recommend you don't alter the above settings unless needed
moduleload      back_bdb # Berkeley DB backend
sizelimit 500
tool-threads 1
backend bdb # Berkeley DB

#######################################################################
# Specific Directives for database #1, of type bdb:
database        bdb
directory       "/var/lib/ldap"
dbconfig set_cachesize 0 2097152 0
dbconfig set_lk_max_objects 1500
dbconfig set_lk_max_locks 1500
dbconfig set_lk_max_lockers 1500
index           objectClass eq
lastmod         on
# Tweak if/as needed

suffix          "dc=mydom,dc=ain"

# Please change the password with the result of "slappasswd"
rootdn          "cn=admin,dc=mydom,dc=ain"
rootpw          {crypt}$!&*@JHM@%$GH@SA* # again, this is a dummy password

checkpoint      512 30

# Allow users to create private users
access to dn.one="ou=private,ou=addrbook,dc=mydom,dc=ain" attrs=userPassword
        by dn="cn=jdoe,ou=addrbook,dc=mydom,dc=ain" write
        by anonymous auth
        by self write
        by * none

# For user authentication and password change
access to attrs=userPassword
        by dn="cn=admin,dc=mydom,dc=ain" write
        by anonymous auth
        by self write
        by * none

# Grant users access to their private addressbooks
access to dn.regex="^.*cn=([^,]+),ou=private,ou=addrbook,dc=mydom,dc=ain$"
        by dn="cn=admin,dc=mydom,dc=ain" write
        by dn="cn=jdoe,ou=addrbook,dc=mydom,dc=ain" write
        by dn.exact,expand="cn=$1,ou=private,ou=addrbook,dc=mydom,dc=ain" write

# Grant the  user access to the whole addressbook
access to dn.subtree="ou=addrbook,dc=mydom,dc=ain"
        by dn="cn=admin,dc=mydom,dc=ain" write
        by dn="cn=jdoe,ou=addrbook,dc=mydom,dc=ain" write

# For direcory access
access to *
        by dn="cn=admin,dc=mydom,dc=ain" write

This small example should be enough to get you going.

Useful tools

OpenLDAP books and documentation, such as the manual on IBM’s site, have a tendency to be cryptic, but they become invaluable once you start grasping the basic concepts. Besides manual pages, here are a few tools you might use. ldapsearch allows users to do complex searches in the “address book” created with OpenLDAP. Some of the essential command-line flags of this utility are:

  • -h [host] – Search for entries on host
  • -A – Return only attribute names
  • -p [number] – Necessary when your OpenLDAP server doesn’t listen on the default port, 389
  • -b "base_entry" – Allows you to narrow down the search domain
  • So, for instance, the command below uses ldap.mydom.ain running on port 3986 as an LDAP server to search for John Doe in addrbook, making sure the search returns only attribute names:

    ldapsearch -h ldap.mydom.ain -A -p 3986 -b "ou=addrbook,o=MyDomain,cn=John Doe"
    

    Another useful tool, phpLDAPadmin, is a good way to administer an OpenLDAP server from a web interface, in the same vein as tools like phpMyAdmin for MySQL servers or phpPgAdmin for PostgreSQL administrators. The slapcat utility that comes with the server-side LDAP utilities (the package is openldap-servers on CentOS) displays the entire LDAP database, so after adding or removing entries, you can check whether the changes are there.

    Client Configuration

    The procedure for configuring clients to authenticate against an OpenLDAP server is shorter and easier. Install libnss-ldap on Debian systems or openldap-clients on CentOS. If using Debian, after answering the appropriate questions at package configuration time, all you have to do is edit /etc/nsswitch.conf so the authentication system knows that it should use LDAP by altering the entries so they read ldap as the first option. If you’re not working on a Debian system, edit /etc/ldap.conf and fill in the same information you entered in ldap.conf on the server before editing /etc/nsswitch.conf and all should be working.

    Using directory services can save you time and improve your efficiency. Depending on the size and complexity of your network, implementing directory services could be the most important administration improvement you make all year.

    See Open Source Trends for 2012

    Related posts:

    1. Using OpenLDAP for Remote Authentication
    2. Using Apache as a File Server with DAV and LDAP
    3. Instant Messaging in the Enterprise with Openfire
    4. Simple Xymon Monitors Hosts, Services, and Network
    5. Stop Using FTP! How to Transfer Files Securely

    Related Open-Source Packages

    CentOS: See all CentOS Articles » Get CentOS Support at OLEX »
    Mitkerberos: See all Mitkerberos Articles » Get Mitkerberos Support at OLEX »
    MySQL: See all MySQL Articles » Get MySQL Support at OLEX »
    OpenLDAP: See all OpenLDAP Articles » Get OpenLDAP Support at OLEX »
    Phpmyadmin: See all Phpmyadmin Articles » Get Phpmyadmin Support at OLEX »
    Phppgadmin: See all Phppgadmin Articles » Get Phppgadmin Support at OLEX »
    PostgreSQL: See all PostgreSQL Articles » Get PostgreSQL Support at OLEX »

    Rares Aioanei

    Rares Aioanei has been using Linux and BSD since 2003. He's a member of the Fedora quality assurance team and a contributor to various projects. When not at the computer, he enjoys reading and riding a bike.

    2 Responses to “Simplify Administration with Directory Services”

    1. Curtis says:

      Hey Rares,

      There is directory services project called freeipa that is impressive. It is an included package on Fedora 15+ and RHEL/CentOS 6.2 for server and client. I am happy that RedHat is putting together a turnkey solution for identity management that can (with the next version) share a trust relationship with MS AD.

      Enjoy,
      -C.

    Leave a Reply

    © 2012 OpenLogic, Inc. | Licensing | Privacy Policy | Terms of Use

    Bad Behavior has blocked 2283 access attempts in the last 7 days.