Chapter 5. OpenLDAP Samples

5.2 Securing the Directory

5.2.1 Security Policy

We will now add some simple security to our directory using the access directive in slapd.conf.

We are going to build an Access Control Policy (ACP a.k.a. ACL) based on Corporate Policy (wow) which states:

The directory entry owner is able to see and update ALL the directory attributes including passwords.
Human Resources must be able to update ANY entry but must not be able to read or write the users password.
The Directory entries carlicence, homepostaddress and homephone must not be readable by anyone except human resources and the owner of the directory entry.
All users must authenticate (anonymous access is not allowed).
The IT department must be able to update or change the password entry on all directory entries.

Whatever your opinions of the above policy we are going to have to provide the access controls to implement it. The first thing we have do is to create two groups one for hrpeople and one for itpeople to enable us to assign group permissions. We will locate these groups using a groups branch under the DIT root. The diagram below shows our new structure.

DIT - with a groups branch added

5.2.2 Adding Groups

The following LDIF shows how we add the groups using the LDIF below.

version: 1

# create FIRST Level groups branch

dn: ou=groups,dc=example,dc=com
objectclass:organizationalunit
ou: groups
description: generic groups branch

# create the itpeople entry under groups

dn: cn=itpeople,ou=groups,dc=example,dc=com
objectclass: groupofnames
cn: itpeople
description: IT security group
member: cn=William Smith,ou=people,dc=example,dc=com

# create the hrpeople entry under groups

dn: cn=hrpeople,ou=groups,dc=example,dc=com
objectclass: groupofnames
cn: hrpeople
description: Human Resources group
member: cn=Robert Smith,ou=people,dc=example,dc=com

Get sample file as text (use save as in your browser).

Notes:

We use the objectclass groupOfNames to define the group.
member: dn defines the member(s) of the group by their DN.

Assuming we save the above LDIF as addgroups.ldif in our /tmp directory we load the LDIF file using ldapadd with a command like this (line below is split for HTML formatting reasons only and should be on a single line):

ldapadd -H ldap://ldaphost.example.com -x -D "cn=jimbob,dc=example,dc=com" 
 -f /tmp/addgroups.ldif -w dirtysecret

The ldaphost.example.com should be replaced with whatever hostname your LDAP directory is located on.

5.2.3 ACL - slapd.conf Access

We now need to translate our update policy into an Access Control List (ACL) using OpenLDAP's slapd.conf access to directives.

This describes how we implement the policy with some detail notes.

The sample below shows our original slapd.conf sample modified to include our Access Control Policy.

#
###### SAMPLE 2 - DIRECTORY with ACL ############
#
# NOTES: inetorgperson picks up attributes and objectclasses
#        from all three schemas
#
# NB: RH Linux schemas in /etc/openldap
#
include		/usr/local/etc/openldap/schema/core.schema
include		/usr/local/etc/openldap/schema/cosine.schema
include		/usr/local/etc/openldap/schema/inetorgperson.schema

# NO REFERRALS

# DON'T bother with ARGS file
# pidfle allows scripts for stopping slapd to work
pidfile /var/run/slapd.pid

# enable a lot of logging - we might need it
loglevel 	-1 

# NO dynamic backend modules

# NO TLS-enabled connections

#######################################################################
# bdb database definitions
# 
# replace example and com below with a suitable domain
# 
# If you don't have a domain you can leave it since example.com
# is reserved for experimentation or change them to My and inc
#######################################################################

database bdb
suffix "dc=example, dc=com"
# ACL1
access to attrs=userpassword
       by self       write
       by anonymous  auth
       by group.exact="cn=itpeople,ou=groups,dc=example,dc=com"
                     write
       by *          none
# ACL2
access to attrs=carlicense,homepostaladdress,homephone
       by self       write
       by group.exact="cn=hrpeople,ou=groups,dc=example,dc=com"
                     write
       by *          none
# ACL3
access to *
       by self       write
       by group.exact="cn=hrpeople,ou=groups,dc=example,dc=com"
                     write
       by users      read
       by *          none

# root or superuser
rootdn "cn=jimbob, dc=example, dc=com"
rootpw dirtysecret
# The database directory MUST exist prior to running slapd AND 
# change path as ncessary
directory	/var/db/openldap/example-com

# Indices to maintain for this directory
# required if searches will use 
# unique id so equality match only
index	uid	eq
# allows general searching on commonname, givenname and email
index	cn,gn,mail eq,sub
# allows multiple variants on surname searching
index sn eq,sub
# sub above includes subintial,subany,subfinal
# optimise department searches
index ou eq
# if searches will include objectClass uncomment following
# index objectClass eq
# shows use of default index parameter
index default eq,sub
# indices missing - uses default eq,sub
index telephonenumber

# other database parameters
# read more in slapd.conf reference section
cachesize 10000
checkpoint 128 15

Get sample file as text (use save as in your browser).

We now need to stop OpenLDAP and restart to pick up this new slapd.conf file. Use something like the following commands:

# stop and start OpenLDAP (slapd)
# on Linux/Redhat
/etc/rc.d/init.d/ldap restart

# on BSD
[bsd] /usr/local/etc/rc.d/slapd.sh stop
# then
[bsd] /usr/local/etc/rc.d/slapd.sh start

# confirm slapd is running
ps ax | grep slapd

5.2.4 Testing the ACL

We now need to test our newly established policy. To test the ACL use your LDAP Browser and:

Configure your LDAP browser to bind or authenticate using dn: cn=Robert Smith, ou=people, dc=example, dc=com with a userpassword of rJsmitH (case sensitive) and because this entry has hrpeople privileges it will see and be able to modify all entries including carlicense, homepostaladdress and homephone but not userpassword (except for his own entry).
Configure your LDAP browser to bind or authenticate using dn: cn=Sheri Smith, ou=people, dc=example, dc=com with a userpassword of sSmitH (case sensitive) and because this entry has itpeople privileges it will see and be able to modify the userpassword attribute of all entries but cannot see carlicense, homepostaladdress and homephone for any entry except her own.
Configure your LDAP browser to bind or authenticate using dn: cn=John Smith, ou=people, dc=example, dc=com with a userpassword of jSmitH (case sensitive) and because this entry has no privileges it cannot see carlicense, homepostaladdress, homephone and userpassword for any entry except his own (which he can also modify).
Configure your LDAP browser for anonymous access and confirm that access is denied.
Finally authenticate as our rootdn or superuser (defined in the slapd.conf as cn=jimbob,dc=example,dc=com, password dirtysecret) and confirm this overrides all our privileges and can see and modify everything.

Note: In all of the above tests you should be able to see with your LDAP Browser the groups branch and the hrpeople and itpeople entries. If you cannot then you may have set your Base DN (or Root DN) fields in the LDAP browser to ou=people,dc=example,dc=com, set this to dc=example,dc=com and you should now be able see (but not edit) the groups branch and its entries.