Chapter 5. OpenLDAP Samples

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

This chapter sets out to explore the holy grail of Single Sign On (SSO) capabilities in *nix systems and networks using OpenLDAP. The following matrix looks at the potential scope of SSO and whether it is either possible or desirable to provide SSO:

Function	Account	How	OS	Notes
System	Unix	pam_ldap.so nss_ldap	Linux, FBSD5.x	Access to Server facilities via logon (local or remote). FreeBSD 4.x does not support pam/NSS for system logon and hence it is not possible to use SSO for this function.
mail	App	courier-native	Any	Access to email - local and virtual users
ftp	App	ProFTP mod_ldap	Any	Access to private (non-anonymous) ftp services
network	Unix	Samba3	Any	Access to network resources from Windows or OS desktops using either an NT or Samba (NT style) PDC. Requires Unix account.
web	App	Apache mod_ldap	Any	Access to Intranet or private web services for example WEBDAV

Notes:

Functional Requirement

We define the functional requirement for a single sign on (SSO) system which on its face may seem obvious but ...

Note: The OpenGroup consortium has an excellent introduction to this topic as part of its XSSO specification.

1. A single user password to control access to all features allowed for the user or group of users. This does not necessarily imply that a single user password will allow access to all services but that the LDAP location where one or more passwords may be stored is accessible via single password. The user sees single sign-on even if different passwords are fed to different applications or sub-systems.

2. A single location for administrators to control/define access to allowed features for each user or group of users.

3. The ability to create, modify or delete users and user access rights.

One day real soon now™.