mail us  |  mail this page

contact us
training  | 
tech stuff  | 

Chapter 5. OpenLDAP Samples

5.2 Securing the Directory

Contents

5.1 Simple 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:

  1. The directory entry owner is able to see and update ALL the directory attributes including passwords.

  2. Human Resources must be able to update ANY entry but must not be able to read or write the users password.

  3. The Directory entries carlicence, homepostaddress and homephone must not be readable by anyone except human resources and the owner of the directory entry.

  4. All users must authenticate (anonymous access is not allowed).

  5. 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

Up Arrow

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:

  1. We use the objectclass groupOfNames to define the group.

  2. member: dn defines the member(s) of the group by their DN.

  3. 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 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 just 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.

Up Arrow

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

Up Arrow

5.2.4 Testing the ACL

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

  1. 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).

  2. 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.

  3. 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).

  4. Configure your LDAP browser for anonymous access and confirm that access is denied.

  5. 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.

Up Arrow

Step 3 - Expanded Hierarchy

Go to Arrow



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.

Contents

tech info
guides home
intro
contents
1 objectives
big picture
2 concepts
3 ldap objects
quickstart
4 install ldap
5 samples
6 configuration
7 replica & refer
reference
8 ldif
9 protocol
10 ldap api
operations
11 howtos
12 trouble
13 performance
14 ldap tools
security
15 security
appendices
notes & info
ldap resources
rfc's & x.500
glossary
ldap objects
change log

Creative Commons License
This work is licensed under a Creative Commons License.

If you are happy it's OK - but your browser is giving a less than optimal experience on our site. You could, at no charge, upgrade to a W3C STANDARDS COMPLIANT browser such as Firefox

Search

web zytrax.com

Share

share page via facebook tweet this page

Page

email us Send to a friend feature print this page Decrease font size Increase font size Display full width page

Resources

Systems

FreeBSD
NetBSD
OpenBSD
DragonFlyBSD
Linux.org
Debian Linux

Software

LibreOffice
OpenOffice
Mozilla
GitHub
GNU-Free SW Foundation
get-dns

Organizations

Open Source Initiative
Creative Commons

Misc.

Ibiblio - Library
Open Book Project
Open Directory
Wikipedia

Site

CSS Technology SPF Record Conformant Domain
Copyright © 1994 - 2017 ZyTrax, Inc.
All rights reserved. Legal and Privacy
site by zytrax
Hosted by super.net.sg
web-master at zytrax
Page modified: October 21 2015.