Chapter 5. OpenLDAP Samples

5.2 Securing the Directory

5.1.1 Designing the DIT
5.1.2 Select the STRUCTURAL objectClass
5.1.3 slapd.conf File
5.1.4 LDIF File
5.1.5 Loading the LDIF
5.1.6 Adding New Entries using LDIF
5.1.7 Modifying Entries using LDIF
5.1.8 Just Fooling Around

5.2 Securing the Directory

5.2.1 Security Policy
5.2.2 Adding Groups
5.2.3 ACL slapd.conf Access Definitions
5.2.4 Testing the ACL

5.3 Expanded Hierarchy

5.3.1 Requirement
5.3.2 Implementation
5.3.3 LDIF
5.3.4 ACL slapd.conf Access Definitions
5.3.5 Testing the ACL

5.4 Creating & Adding Objects

5.4.1 Requirement
5.4.2 Implementation
5.4.3 Attribute Definitions
5.4.4 objectClass & Schema Definition
5.4.5 ACL slapd.conf Access Definitions
5.4.6 LDIF
5.4.7 Testing the Changes

5.5 Single Sign On
5.6 Referral and Replication

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.

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-of-the-member defines the member(s) of the group by their DN. (One or more member: dn-of-the-member attributes may be present.)
Observant (or still awake) readers will have noted that the entry for member: cn=William Smith,ou=people,dc=example,dc=com does not currently exist in our DIT. This is perfectly acceptable. No checks are made when adding the member attribute. In this case the only consequence will be that no current entry in our DIT will be a member of the itpeople group. Perhaps we forgot to add William Smith, or perhaps we'll add the entry later. Perhaps we made a mistake.

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 and the format in OLC (cn=config) format.

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

Note: The attributes carlicense and hometelephone do not appear in every entry of our currently created DIT and indeed homePostalAddress appears in no entry. This emphasises two points. First, the ACLs are expressions of our security policy and do not relate to the current contents of the DIT. Second, since all these attributes are part of the inetOrgPerson objectClass hierarchy (->organizationalPerson->Person) they could be added to any entry at any time in the future in which case the ACLs need to define our full access control policy from the beginning of our DIT creation.

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.

Step 3 - Expanded Hierarchy

Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.