Copyright• The contents of this course and all its modules and related

materials, including handouts to audience members, are Copyright © 2008 Red Hat, Inc.

• No part of this publication may be stored in a retrieval system, transmitted or reproduced in any way, including, but not limited to, photocopy, photograph, magnetic, electronic or

• other record, without the prior written permission of Red Hat, Inc.• This instructional program, including all material provided herein,

is supplied without any guarantees from Red Hat, Inc. Red Hat, Inc. assumes no liability for damages or legal action arising from the use or misuse of contents or details contained herein.

• If you believe Red Hat training materials are being used, copied, or otherwise improperly distributed please email training@redhat.com or phone toll-free (USA) +1 866 626 2994 or+1 9197543700

Participant Introductions

Please Introduce yourself to the rest of the class

Red Hat Enterprise Linux

• Enterprise-targeted operating system

• Focused on mature open source technology

• 18-24 month release cycle

• Certified with leading OEM and ISV products

• Purchased with one year Red Hat Network subscription and support contract

• Support available for seven years after release

• Up to 24x7 coverage plans

Red Hat Enterprise Linux Variants

Server:

Red Hat Enterprise Linux Advanced Platform

Red Hat Enterprise Linux

Client:

Red Hat Enterprise Linux Desktop

with Workstation option

with Multi-OS option

with Workstation and Multi-OS options

Red Hat Network

A comprehensive software delivery, system management, and monitoring framework

Update Module: Provides software updates Included with all Red Hat Enterprise Linux subscriptions

Management Module: Extended capabilities for large deployments

Provisioning Module: Bare-metal installation, configuration management, and multi-state configuration rollback capabilities

Monitoring Module provides infrastructure health mon~Loring of network's, systems, applications, etc.

Other Red Hat Supported Software

Red Hat Application Stack

JBoss Enterprise Middleware Suite

Red Hat Directory Server

Red Hat Certificate System

Red Hat Global File System

The Fedora Project

Open source projects sponsored by Red Hat

Fedora distribution is focused on latest open source technology

Rapid four to six month release cycle

Available as free download from the Internet

EPEL provides add-on software for Red Hat Enterprise Linux

Open, community-supported proving grounds for technologies which may be

used in upcoming enterprise products

Red Hat does not provide formal

Objectives of RH423

• Develop skills required to manage and deploy directory services on Red Hat

Enterprise Linux systems

Gain a better understanding of PAM and user authentication on Red Hat

Enterprise Linux

Audience and Prerequisites

Audience: Senior Red Hat Linux and Red Hat Enterprise Linux system

administrators and other IT professionals who need to provide enterprise-wide

authentication or information services

Prerequisites: RHCE certification or comparable skills and knowledge

Classroom Network

example.com network (192 . 168 .0. 0/24)

serveri .example.com (192.l6e.o.254)

Main classroom server: Provides DHCF, DNS, routing and other services

stationx.example.com (192.168.0 .x)

Student systems

serverx-i-100.example.com (192. 168 .0 .x+ioo)

virtual server hosted on student stations

serverx-r200.example.com (192 .168 .0. X.i-200)

Secondary virtual server hosted on student stations

Notes on Internationalization

Red Hat Enterprise Linux supports nineteen languages

Default language can be selected:

During installation

With system-config-language

System->Administration-~Language

Alternate languages can be used on a per-command basis:

$ LANG=en_US.OTFS date

Language settings are stored in /etc/sysconfig

Introduction to Directory Services

Objectives

Upon completion of this unit, you should be able to:

Explain what a directory service is

Explain the history of LDAP and X500

Understand the LDAP information model

Read and write simple LDIF

Explore issues

What is a Directory?

A directory is a specialized database that normally stores small pieces of

information

Special-purpose directories are common:

A telephone book is a directory of names to telephone numbers

ONS is a directory of hostnames to IP addresses

NIS is a directory of system information; username to password file data, name

to e-mail alias, mount point to device, and so on

Ideal Directory Data

Small pieces of information will be stored

Potentially many small pieces of informationl

Data will be frequently read but rarely written

Individual entries are based on collections of attributes (phone number, address,

etc.)

Information will need to be searched for or looked up by multiple client users

Uses of a Directory

Look up e-mail addresses and contact information in mail clients and web

browsers

Manage and synchronize user authentication centrally from a network server

Centrally coordinate informational databases used by various network services

Store and search for arbitrary data

X.500 Directory Service

General-purpose directory service designed by ISO and CCITT starting in the

1980s

The Directory: a fully-connected global directory, information organized in a tree

Flexible information model

Intended for "white pages" telephone and X.400 e-mail directories, OSI

name service

DAP: clientlserver communication protocol

X.500 Problems

• X.500 (and DAP) is complex and resource hungry to implement

The standards process did not require test implementations to prove feasibility!

Early implementations were slow, buggy, and did not interoperate well

X.500 is tied to the OSI network model

The Internet is based on TCP/IP, not OSI

Deployment was therefore slow

Lightweight Directory Access Protocol

Originally for use by desktop computer clients

LDAP improves X.500 DAP in several ways:

Uses TOP transport in place of 051 networking

Simplifies protocol to nine basic operations

Uses a subset of X.500 message encoding rules

Data elements are simple text strings

LDAP Directory Service

Initial ldapd daemon acted as a gateway

In 1995, UMich LDAP group realized over 99% of X.500 queries came through ldapci

A standalone LDAP daemon (slapd) replaced ldapd and the

X.500 service

Removed overhead of LOAP-to-DAP translation

Improved performance and reduced directory service complexity

LDAP Models

Information Model

How individual entries in the directory are structured

Naming Model

Where entries are stored in the hierarchical directory tree

Functional Model

What operations can be performed on the directory

Security Model

How directory information is protected from unauthorized access

Information Model

An entry stores information about an object of interest in the directory

The basic unit of information storage

Each entry is made up of attributes which describe

characteristics of the object

Each attribute in an entry has a type and takes one or more values

The unique distinguished name of an entry is based on one of its attributes

Directory Schema

The schema defines rules on what attributes can be used in which entries and

how their values are formatted and compared

Keeps directory data consistent and useful

Reduces redundant or inappropriate information stored in entries

Constraints on size and format help avoid bogus data values being assigned to

attributes

Directory Schema

attribute types: name/OlD tied to

attribute syntax- used by the attribute to define how its value should be

formatted

matching rules: used by the attribute to define how to compare two attributes

of the same type

object classes: name/OlD to attributes that

Represent a family of similar objects

Define what attributes must or may be inciuded in an entry

Directory Schema

Each item in the schema is assigned a unique object ID ("OlD") number

OlD arcs assigned on request by lANA

Better to use standard schema definitions than to invent a custom ones

Simplifies searches on the directory

Better interoperation with different software

Easier to maintain and understand

Standard Schema Definitions

Core LDAP schema is defined in RFCs 4519, 4517, and 4512

Updates of older definitions in RFC 2252 and RFC 2256

RFOs 2247, 2307, 2798, and 4524 provide commonly-used extensions

Servers come with pre-installed schema files

Vendors may provide non-standard schema extensions of their own

Example Attribute Definition

attributeTypes: ( 2.5.4.20 NANE telephonewumberlEQUALITY

telephoneNumberMatch

SUBSTR telephoneNumbersubstringsMatch

SYNTAX 1.3.6.1.4.1.1466 .115.12Th1.50{32})

2.54.20 istheOlDfortheattribute

SYNTAX OlD defined as TelephoneNumber

Valueshouldhaveaformlike +1 919 555 1212

Sample Attribute Syntaxes

Usually listed in schema by OlD, not name

TelephoneNumber: in E.123 format

DirectoryString: text stored as UTF-8

IA5String: text stored as ASCII

INTEGER: integer number as a digit string

OctetString: arbitrary binary data

CountryString: an ISO 3166 country code

Sample Matching Rules

Many different rules to test for equality

caseIgnorer.qatc~: case insensitive

caseExactyatch: case is significant

integerMatch: compare two numbers

octetStringMatch: compare byte-by-byte

Sorting and substring matching rules

Commonly Seen Attributes

d.n The unique DN identifying the entry

cn The entry1

s common name (full name)

sn The surname (last name) of a user uld Login name

c Two letter country code

o Name of an organization ou Name of an organizational unit mail Internet e-mail

address

Object Classes

An object class groups related information

Defines which attributes are mandatory and which are permitted in an entry

obj ectclass attributes specify which object classes an entry belongs to

There are different kinds of object classes

An entry trust have one structural object class

An entry may add one or more additional aux//iaty object classes

Example Object Class

objectClasses: C 2.5.6.6 NANE 'persont

SUP top STRUCTURAL

MUST ( sn $ an

MAY ( nserPassword $ telephoneNurnber $

seeAlso $ description

The person object class has OlD 2.5.6.6

It is a structural object class, and tap is its immediate superclass

It has two mandatory attributes, sn and cn, and four optional attributes

Derived Object Classes

An object class may be a subclass derived from another object class

The derived class inherits the required and optional attribute lists from its

superclass

The derived class may then add additional required and optional attributes

Example Object Class

objectclasses: ( 2.5.6.0 NAME ttop

AR STRACT

MUST ( objectelass

objectClasses: C 2.5.6.6 NAME person'

SUP top STRUCTURAL

MUST ( sn $ cn

MAY ( userPas sword $ telephoneNumber $

seeAlso $ description

Therefore person inherits a third required attribute from top,

obj ectclass

A special auxiliary object class in the core LDAPv3 schema

Entries which include this object class can include any attribute

This effectively disables schema checking for those entries Which can lead to a mess later on,...

Avoid using this object class in entries

A standard text-based format for describing directory entries

May be used to describe an existing directory or changes to be made to

an existing directory

An entry consists of a list of attributes, one attribute per line

dn, the entry's distinguished name, must be first

Entries are separated by blank lines

Attributes and values are colon separated

Two colons indicate that the value is base-64 encoded (can use openssl utility to

convert)

If a line starts with 4*, it is a comment

If a line starts with a single space, it is continued from the previous line

Sample Entry in LDIF Form

dn: uid=bjensen, ou=people,dc=example,dc=com

objectclass: topobjectclass: personobi ectclass: organizationalFersonobj ectclass: inetargPersOfl

cn: Barbara Jensen cn: Barb Jensen

Sn: Jensen

uld: bjensen

mail: bj ensem~examp1e .corn

telephoneNumber: +1 919 754 3700

postalAddress: Example, Tnc.$123 Main Street$Any Town, NC 12345$USA

title: Account Manager

Troubleshooting an LDIF Entry

Does the RDN match an attribute-value pair?

Is there exactly one structural class, not counting parent superclasses?

Do all mandatory attributes have a value?

Are there any attributes set which the object class or classes for this entry do

not allow?

Do any single-value attributes have multiple values?

Managing Directory Data

What attributes do your applications need?

Are they hard-wired to use a particular schema?

Do applications have conflicting needs?

Correct object class selection is important

Helps avoid poor quality or badly formatted data

An entry cannot change its structural object class after creation!

Managing Directory Data

Use standard schema definitions if possible

Auxiliary classes may help

Avoid storing identical or redundant data in multiple attributes

Otherwise, ensure the values stay synchronized

Plan for change

What attributes might you need in the future?

How will current data be kept up to date?

Developing a Data Policy

What data will and will not be stored in the directory service

Who has the ability to modify which entries

Who has the ability to access which entries

Legal considerations affecting the above

How exceptions may be made if needed

End of Unit 1

Questions and Answers

Summary

LDAP and X.500

Schemas, object classes, and attributes

LDIF

Management of directory data

Labi Directory Schema and LDIF

• Goal:

• To gain a better understanding of the directory infonnation model. Be able to

read and interpret schema files. Be able to check entries in LDIF form for

correctness.

• System Setup:

• Lab Setup:

• Situation

Unit 2

The LDAP Naming Model

Objectives

Upon completion of this unit, you should be able to:

Use the LDAP naming model

Use and construct LDAP distinguished names (DNs)

Interpret directory suffixes

Organize entries in the directory

Define a name space in LDIF

LDAP Naming Model

• The naming model defines how entries are organized and identified in the directory

• Every entry must have a unique name that may be referenced unambiguously

• The distinguished name or DN

•

• A well-designed name space is critical

• Easier retrieval and maintenance of data

• Easier to apply access control policies

The Directory Information Tree

• Directory entries are arranged in a hierarchy

• The directory information tree, or DIT

• Similar to a file system or DNS hierarchy

•

• Each entry has one parent entry

• An entry may have any number of children

• The DN of an entry specifies its position in the directory hierarchy

• uid=lee,ou=sales,dc=foo,dc=com

Distinguished Names

• The leftmost component of the DN is the relative distinguished name, or RDN

• The RDN must be• Selected from the attributes of the entry• • Unique among entries that share the same immediate parent entry• • Two entries may have the same RDN if they have different parent entries

(and therefore their full DNs are different)•

Escaped Characters

• Some characters must be escaped with a backslash (\) if they

• appear in a component of a cTh attribute

• Comma, pius, double quote, backslash, less-than, greater-than, or

semicolon

• # at the start of a component

• White space at the start or end of a component

• dn: o=Example\, Inc.,st=Delaware,c=us

The Directory Suffix

• The global LDAP name space IS distributed among multiple directory

partitions

• The suffix is the DN of the highest entry in the LDAP directory

• hierarchy which is stored in a directory partition

• The node below which your name space lives

• The DNs of all entries in that directory partition end with the suffix

Choosing a Suffix

• LDAP does not place restrictions on the suffix you may use or the

structure of your directory

• Your suffix should be unique in case your server ever needs to coexist

with others

• There are two standard approaches

• The X.500 naming model

• The Internet domain naming model

X.500 Suffixes

• X.500-style suffixes are geographically and organizationally based

• o=Example\, Inc. ,st=Delaware,c=US

•

• Useful if X.500(93) compatibility is needed

• In practice, it has proved hard to find and manage names using this

naming scheme

•

Internet Domain Suffixes

• The preferred method is to use components of the organizationts DNS

domain

• For example.com: dc=exarnple, dc=com

• Since we know the DNS domain is unique, then the LDAP suffix is also

unique

• Can simplify deployment and configuration

• Easier to manage in the long term

Structure of the Name Space

• After selecting the suffix, the structure of the directory name space

must be designed

• At one extreme is a flat name space containing all entries directly

under the suffix

• uid=j ce5dc=example, dc=com

•

• At the other is a deep name space dividing entries into fine categories

• uid=j ce, ou=sales, ou=raleigh, dc=foo r dc=corn

Flat Name Space

dc=exemnjg,dc=com

a• uid=scarter• I~mCa~I• ~zng• 'S• a.• uici=jbrown

• FU9

Brown• 'S • inS

uid=jvedder

Icn=Jetfvedderl Resources

Flat Name Space Issues

• Advantages

• Names do not need to change when job roles change or the organization changes

• Simple design avoids need to object categorization by directory administrators

•

• Disadvantages

• Hard to partition the directory later if needed

•

• May be hard to maintain unique DNs

•

Deep Name Space

• A• dc=ex I do—corn• lFMi~ l=North~gierica• ou=People• ou=Sales ou=Devel uid=joe uid=rnara• ou=People • ounSales• uld—jeanne• ounPeople• ou=Sales • uidnpete

Designing the Name Space

• There is no name space design that is ideal for all situations• May help to think about how you planned the DNS name space of hosts

and subdomains• • Try to keep the hierarchy fairly flat• Simpler management, good for small directories• Depth is useful for• Avoidance of naming collisions• • Dividing up directory management

One Compromise Name Space

• dc=exa dc-corn• i=Nort..~urica I=EuroDe• • • uidnpete• ou=Sales• Set the ou attribute on entries• Can still search based on ou• changing ou just affects one entry, not directory hierarchy

Designing the Name Space

• Place entries in subtrees based on the type of entry, not just by organizational structure or geography

• For example:• inetoryPerson entries under ounPeople• • Entries for groups under ou=Groups• • Entries for machines under ou=Hosts• • Can use in addition to other schemes•

Defining the Name Space

• The LDAP server will need to have your name space input in LDIF

format

• You will need an entry for your root node

• You will need entries for any nodes which act only as containers for

other entries

• Various object classes are useful

• domain, dcobject, country, locality, organization, organizationalunit

Planning the Directory

• A well-designed directory tree can make directory management much

simpler

• Additional references which may be useful:

• Red Hat Directory Administrator's Guide

• Understanding and Dep/oying LDAP Directory Services by Timothy

Howes, Mark Smith, and Gordon Good.

• Questions and Answers

• Summary

• DIT and distinguished names

• X.500 and "Internet" naming suffixes

• Designing the naming hierarchy

Unit 3

Red Hat Directory Server: Basic Configuration

Objectives

• Upon completion of this unit, you should be able to:

• Install Red Hat Directory Server software

• Perform initial configuration of the directory server

• Start and stop the directory service

• Control and view directory server log files

• Back up and restore directory data

• Implement basic performance tuning with indexes

Red Hat Directory Server

• Enterprise-targeted LDAP directory server

• Based on former Netscape Directory Server

• Designed to be scalable, highly available and reliabte, secure, and easy

to manage

•

• Provided using the same subscription and support model as Red Hat

Enterprise Linux

• Developed as open source software through the Fedora Directory

Server project

Components

• Red Hat Directory Server

• Red Hat Management Console

• Java GUI application to manage the directory service and directory data

•

• Red Hat Administration Server

• Web server that handles requests from console

•

• Search and manage the directory from the web

System Requirements

• On 32-bit and 64-bit x86 systems:

• Red Hat Enterprise Linux 5 Server, or Red Hat Enterprise Linux 4 AS or ES

•

• 500 MHz Intel Pentium Ill or faster

• Memory: 256 MB minimum, 1 GB recommended

•

• Disk: 300 MB minimum, 2 GB recommended for production (more for very large directories)

Installation Overview

• Install a version 1.5 Java® Runtime Environment (JRE)• Available from the RHEL Supplementary channel on Red Hat Network• • Install the redhat-ds RPM package• Available from the Red Hat Directory Server 8 channel on Red Hat Network• Set up basic configuration of the servers• setup-ds-admin.pl• Complete configuration of the servers and import your data• Red Hat Management Console or command-line tools•

Preparing for Installation

• Selection of user and group for ns-slapd

• Optional sysctl and ulimit tuning

• Increasing the number of open files/connections

• Adjusting the TOP keepalive timer

• Topology planning

• Location of the configuration directory

• Location of servers providing user directories

User and Configuration Directory

• The configuration directory is a special suffix shared by all

• Directory Servers in the organization

• o=NetscapeRoot

•

• Used to simplify centralized management of all Directory Server

installations

• The user directory is the suffix that contains your user and group

entries

Admin Server and Management

• All Directory Servers in the organizations topology share a

configuration directory

• o=NetscapeRoot on a particular server

• All servers in an administration domain share a user directory for

authentication

• A server group consists of all server instances sharing a computer, a

server root, and an Administration Server

•

Using setup-ds-admin.pI

• Interactive installation• Express: for evajuation uses only• Typical: sets up a basic installation (default)• Custom: better control of initial directory data• • Silent installation• setup-ds-adminpl -s-f setup-EiIe.inf• • Create a template from an interactive installation with the -k option

Using setup-ds-admin.pI

• For Directory Server instance• Identifier for the instance (hostname -s)• • Network pod and user/group to use• User directory suffix and Directory Manager ON• For Configuration Directory: configuration Administrator user and administration

domain• • For Administration Server instance• IP address, network port, and user to use•

Starling and Stopping Services

• Services can be configured to start at boot using chkconfig

• /etc/init - d/dirsrv controls the Directory Server

• /etc/init - d/dirsrv-admin controls the Administration Server

•

Using Red Hat Console

• redhat-idm-console

• Asks for a user entry, their password, and the URL of the

Administration Server being logged into

•

• Servers and Applications tab used to view the topology and start

management windows for server instances

• Users and Groups tab uses LDAP to find and manage user and group

directory entries

Red Hat Directory Server File Locations

• Red Hat Directory Server 8.0 conforms to the Filesystem• Hierarchy Standards• configuration files - /etc/dirsrv/slapd-instance• • Usefulscripts- /usr/lib/dirsrv/slapd-instance• • Databasefiles- /var/lib/dirsrv/slapd-instance• • Log files - /var/log/dirsrv/slapd-instance• • Lockfiles- /var/lock/dirsrv/slapd-instance

• The directory servers configuration is stored in the directory

• itself under cn=config

• This allows the configuration to be read and changed using LOAP

messages

•

• The /etc/dirsrv/slapd-instance/dse idif text file stores the current

cn=config entries

The schema Directory

• The directory1

s schema is defined in the server instances schema!

directory

• schema files are loaded in numerical and alphabetical order

•

• The schema can be extended by adding files

• The cn=schema entry can be used to read and extend the schema over

LDAP

• Updatesarewrittento 99user.ldif

The errors Log

• The nsslapd-errorlog-level attribute of the cn=config entry controls

what messages are written to errors

• Automatic log rotation is controlled through other attributes

• Log settings can also be adjusted through the server instance1

s

management window in Red Hat Console

The access Log

• access tracks detailed information about each client connection made

to the directory

• The nsslapd—accesslog-level attribute of cn~contig determines the

events logged

• The audit log can be enabled to record the LDIF of each change made

to the database

•

Administration Server File Locations

• The Administration Server also conforms to the Filesystem

• Hierarchy Standards

• configuration files - /et c/dirsrv/admin- serv

• Log files - /var/log/dirsrv/admin-serv

Backing up the Directory Data

• The database files can be backed up while the server instance is

• live

• From the Directory Server console using the Back Up Directory Server

task

• From the command line using db2bak

• Backup is stored in slapd-instance/bak

• The current dse . idif and schema must be backed up separately

Restoring the Directory Data

• If the server is live

• From the Directory Server Console using the Restore Directory Server task

•

• From shell prompt with bak2db.pl PerI script

•

• If the server is stopped

• From shell prompt with bak2db shell script

•

• The server must be stopped before schema/ and dse. idif are restored

Export Directory DB to LDIF

• The database files may be dumped as LDIF while the server is• live• From the Directory Server Console using the Export Databases task• From the command line using db2ldif• • Useful for backups and migrations• LDIF is portable, Berkeley DB format is not• • can modify directory data and re-import•

Import LDIF to Directory DB

• If the server is live

• From the Directory Server Console, use the Import Databases task to append to the DB

• From the Directory Server Console, reinitialize the database from the LOIF file

•

• From the command line, use ldif2db.pI to overwrite the database

•

• If the server is stopped, use ldif2db from the shell prompt to overwrite the DB

Indexes

• Database indexes speed up directory search and read performance

• Critical for good server performance

•

• The four most common types of indexes:

• pres presence of the attribute

approx approximate/phonetic match

sub substring match

eq exact match

Working With Indexes

• Indexes are easiest to create through the graphical Red Hat Console

tool

• Modifies settings under cn=config tree

•

• Indexes should be set based on what clients are searching for

• Watch for common searches in the access log for the server instance

• Run db2index after adding through LDIF

End of Unit 3

Questions and Answers

Summary

Basic Red Hat Directory Server configuration

Using Red Hat Console

Monitoring and tuning log files

Backing up and restoring directory data

Basic performance tuning with indexes

Unit 4

Searching and Modifying the LDAP Directory

Objectives

• Upon completion of this unit, you should be able to:

• Describe the LDAP Functional Model

• Use command-line OpenLDAP utilities

• Specify LDAP search filters

• Create, modify, and delete directory data

• Configure and use graphical LDAP address books

LDAP Functional Model

• Defines the basic operations that can be performed on the directory

• Nine operations divided into three groups

• Interrogate: search and compare

•

• Update: add, delete, modify, modify RDN

•

• Authenticate: bind, unbind, abandon

•

Command—Line Utilities

• There are two sources of readily available command-line tools

• on the system

• Included with the distribution as pad of the openidap-clients package

• Included with Red Hat Directory Server

•

• We will focus on the openidap-clients tools

• Commonly on Red Hat Enterprise Linux systems

• The Directory Server tools are very similar

OpenLDAP Client Utilities

• openidap-clients comes with a number of utilities for operating

• on the directory

• ldapsearch to search the directory

•

• ldapadd and ldapmodify use LDIF files to update the directory

•

• ldappasswd, ldapmodrdn, ldapdelete are single-purpose tools to update the directory

•

OpenLOAP Client Configuration

• Set up /etc/openldap/ldap . conf with local defaults for• your directory service• EASE followed by your directory suffix• • URT or HOST specifies your LDAP server• • Users may have a personal —I. ldaprc file• BTNDDN for the ON used to authenticate• See idap. cant (5) for more options

Common Options

• Useful options common to these utilities:

• -H uri Use server at url

• -x Use simple, not SASL binds

• -D dn Bind using dn

• -w Prompt for simple bind password

• -z Try to use StarITLS; - zz requires it; for LOAPS: -H ldaps://server

Idapsearch

• Used to search the directory data• Useful options include• -L Less verbose LOIF; upto -LLL• -b dn Base DN in tree to start search from• • -s scope Search scope: sub, one, or base• • Takes a search filter, and list of attributes to return (all in matched entries

is the default)• ldapsearch -x (uid=bnrns) mail

LDAP Search Filters

• Defined in RFC 2254• • Attribute and value to match in parentheses• Example: (uid=burns)• • Several operators are available• — Exact match• >= Greater than or equal to• • <= Less than or equal to• Approximate match

LDAP Search Filters

• A * is a wildcard, matches zero or more characters

• Logical operators may be used to construct complex searches

• NOT: (I(age>=21))

• AND: (&(sn=janes) (o=IBM))

• OR: (I (sn=laurel) (sn=hardy))

•

• Multiple levels of nesting allowed

LDAP Search Filters

• Types of filters for matching align with index types kept by the server:

• Equality (eq):

• Substring (sub):

• Approximate (approx):

• Presence (pres):

• (sn=j ensen)

• (sn=jens*)

• (sn'—=j enson) sn=*)

• (obj ectclass=*) is the default search filter used by ldapsearch if not specified

Search Filter Escapes

• Five characters must be escaped if they will be filter:• Character • (• )• The null byte• used in a search• Escape• \2A• '28• '29• \5C• \oo

The Root DSE

• Stores information about server capabilities• Directory partition (namingcontexts)• • Special extensions or controls add new features to LDAP, listed by their OlD numbers• Mechanisms available for SASL authentication• The sGhema used by this server• • Clients can test for availability gracefully• • Idapsearch -x -s base -b•

Other Directory Specific Entries

• Other special suffixes are not considered part of the global directory

by Directory Server but contain entries unique to each directory server instance

• cn=contig for the server configuration

• cn=monitor for current server activity

• cn= schema for the server's subsohema

Idapdelete

• Used to remove entries from the directory

• May specify entries to delete by

• List of ONs given as command-line arguments

•

• List of ONs passed from standard input

• File containing a list of ONs, specified with -f

•

• Can use -r to recursively delete a subtree

lciapmodrdn

• Simple tool to change the RDN of an entry

• ldapmodrdn dii newrdn

• Can not change the whole ON, just the RDN of the original ON

•

• The -r option also removes the value used for the old RDN from the

entry

•

ldappasswd

• Tool to change the userPassword attribute used to

• authenticate a directory user

• Uses LDAPv3 Password Modify extension

•

• Default server configuration stores changes as salted SHA-1 hashes

• Picks random new password by default

• Use -s to be prompted for a password

• New password is input before simple bind!

Idapadd

• Used to create new entries

• Reads LDIF from standard input or the file specified by the -f option

• If a listed entry does not exist, creates it with the specified attributes

and values

•

Iciapmodify

• Multi-purpose directory update tool

• Can add, delete, or replace attributes

• Can add or delete entries

• Can change the RDN of entries

•

• Updates are provided as a special type of LDIF file

• Read from standard input or specify with - f

•

LDIF Update Format

• changetype: add is used to add an entry• Idapacid acts like all entries have this line• changetype: deietedeletesaneiitry• • dn: utd=marks, ou=people , dc=example, dc=com changetype: add• objectclass: top

obj ectclass: account• uid: marks• • dn: uid=j ensen, ou=people, dc=example, dc=com changetype: delete

LDIF Update Format

• changetype:• modify changes attributes•

• Next line specifies add, delete, replace

• add: attribute• • attribute: newvalue• • replace: attribute attribute: newxralue• • delete: attribute removes all values of that attribute, or you can specify only particular values to delete

LDIF Update Example

• dn: uid=georqe, ou=people , dc=example, dc=com changetype: modify• delete: telephoneNumber• telephoneNurnber: +1 919 754 3700• • dn: uid=george, ou=people, dc=example , dc=com changetype: modify• replace: mail• mail: george@sales.example.com• • dn: uid=george, ou=people, dc=example, dc=com changetype: modify• add: title• title: Account Executive

Combined Attribute Updates

• Updates can be batched as a transaction:• • dn: uid=george,ou=people, dc=exarnple dc=com changetype: modify• delete: telephonewumber• telephoneNumber: +1 919 754 3700• • replace: mail• mail: georgeesales - example .com• • add: title• title: Account Executive

Schema Updates over LDAP

• The cn=schema entry contains the schema

• attributeTypes and objectelasses attributes each define an attribute or object class

•

• Can use lciapsearch to read the schema

• Can use ldapmodify to extend the schema

• Add attributes to the cn=schema entry

• Ads control which entries have write access

• On-line changes saved in s9user - idif

Directory Server CLI Differences

• The command-line utilities that come with Directory Server take

slightly different options than the ones provided by OpenLDAP

• In particular beware of -x, -z, -H, -wand -w

•

• The defaults from /etc/openldap/ldap .conf are not used by the

Directory Server utilities

• The Directory Server utilities may behave differently than the

OpenLDAP utilities

•

Red Hat Console

• Main windows Users and Groups tab• can search for directory entries• • Can make simple edits to existing entries• • Can add users, groups, and organizational units•

• Directory Console1

s Directory tab• Can browse navigation tree for entries• Have access to more advanced tools to add, edit, and manage entries•

Graphical Address Books

• Many graphical e-mail clients have built-in address books which can be

set up to query a LDAP directory service

• Evolution 2x

• File -> New -> Address Book

• Mozilla Thunderbird 1.5

• Edit -> Preferences -> Composition

The Dirty Secret

• In practice, address books are inconsistent in how they interpret

• attributes

• Applications do not always follow the standards

•

• Quirks and work-arounds are too common

•

• Vendors of address book clients are tempted to create custom schemas

• Often are not used by other software, can cause problematic redundancy in the directory

Practical Address Books

• Try to stick to attributes in inetOrgPerson

• Mozilla-based code conflicts with Evolution about where addresses are stored

• Mozilla-based code uses individual aftributes like street, I, st, and

• postalcode

• The other applications use postalAddress

•

• May need to store redundant data or adjust client applications (if possible)

•

Questions and Answers

Summary

OpenLDAP command-line client utilities

Search filter syntax

Updating the directory

Graphical LDAP client utilities

Objectives

• Upon completion of this unit, you should be able to:

• Explain LDAP authentication

• Protect directory server communication with TLS/SSL

• Design and use Access Control Instructions

Directory Server Security

• Provide clients with information they need

• Properly authenticate clients and set reasonable access controls

• Guarantee integrity and privacy

• Of sensitive data stored in the directory service

• Of communications between client and server

•

• Monitor and audit status of directory security

•

Authentication and Access Control

• Client users identify themselves to the system through the

authentication process

• Access control rules set authorization criteria that determine if the

authenticated user is authorized to access particular data

• Information about accesses may be logged, keeping an audit trail

User Authentication

Simple binds

Client sends ON of an entry and its password as cleartext, server compares to the entry's stored userPassword attribute

Anonymous bind sends null DN and password

May be protected with TLS encryption

SASL binds

Authentication and encryption methods are negotiated (GSSAPI, Digest-M05, etc.)

Transport Layer Security

• Protects integrity and privacy of TOP stream

• Server sends client a certificate containing

• Public key for client to use to talk to server

•

• A subject ON identifying the server

•

• A certificate authority issuer DN and signature to prove the certificate's validity to the client

• Messages encrypted by the public key can only be decrypted by the private key

TLS Configuration

• LDAP has two methods to use TLS (SSL)

• LOAPS connections to port 636/top (old method)

• StartTLS to protect connections to 389/top

•

• Your server's TLS certificate must

• Have a cn attribute set to the server's fully qualified domain name as the subjecVs RDN

•

• Be signed by a certificate authority trusted by directory server clients

Installing TLS Certificates

• Easiest to do in Red Hat Console

• Generate a server certificate signing request

• Save server CSR as a text file and send to CA

• Get server certificate from CA and install it

• Install certificate authorityts certificate

• Can also use certutil and other command-line tools to manage

certificates

• TLS files in /et.c/dirsrv/slapd-instance/ {cert8,key3,secmod} .db

Using cerlutil

• NSS certificate databases• Three related files, certS .db,key3 .db, and secmod.db• Certificates identified by a nickname• • Basic certutil usage• -d dir selects the database• -A -i certificate.crt -nnicknameirflportsacertificate into the• database• -L lists the contents of the database• -M -t flags, flags, flags -n nickname Modifies the uses for which the certificate wilt

be considered

Enabling TLS Security

• Again, easiest to do with Red Hat Console

• can set up server and client TLS authentication

• Can also install certificates and enable for Administration Server

• Can also be done through [DIF updates and command-line tools, but

harder

• Tutorial at Fedora Directory Server web site

Enabling Client TLS Security

• The OpenLDAP command-line utilities need to validate the servers

certificate

• Directives to set in —./ ldaprc or in /etc/openldap/ idap. conf

• TLS_CACERT or TLS_CACERTDTR point to the CA certificates to validate

the server's certificate

Access Control Instructions

• The LDAP protocol does not specify a standard way for servers to store

access control information

• Red Hat Directory Server uses the xi operational attribute to

• store Ads in entries

• Affects the entry and all its descendants

• If no AOl rule applies, access is denied by default

Access Control Instructions

• An entry inherits the ACIs of all its ancestor entries in the tree

• Effective rights are the union of all the ACIs; whether the ACI is on an

entry, its parent, or distant ancestor does not affect precedence

• If explicit deny rules and allow rules conflict with each other, the deny

rule always takes precedence

Anatomy of an ACI

• The target specifies which entries and attributes have access

controlled by this rule

• The permissions specify what rights are allowed or denied by this rule

• The bind ru/es specify who this rule applies to, under what conditions

• ACIs also have a name which is an arbitrary string to identify the

• ACI

Example Ads

• Basic format of an ACI value:

• (target) (version 3.0; ad "name"; permissions bind-

• rules;)

•

• Example granting global write access to members of a specific group entry

• (targetattr~I*t) (version 3.0; ad "Trust wheel"; allow (all) groupdn="cn=wheel,ou=Groups,dc=x, dc=org';)

•

Targets of an ACI

• A directory entry or subtree

• (target="ldap:///ou=People,dc=example, dc=corn')

•

• Attributes of an entry

• (targetattr=iluserpasswordri)

•

• Entries that contain attributes matching a LDAP search filter

• (targetfilter=" (postalcode=27606) ")

Permissions of an ACI

• Can allow or deny the following rights:• read Read directory data• write Add/modify/delete attributes• • add Add new entries• delete Delete existing entries• • search Search for an entry• compare Test entry's attribute for a value• selfwrite Can add/delete own DN to entry•

Bind Rules of an ACI

• The ACI can apply based on• The user entry used for authentication• Group membership of current user entry• • Time of day or day of week• • IF address or ONS host name of client• How authenticated (simple or SASL bind)• • Can also combine multiple criteria•

User Bind Rules

• Bind as a particular entry (wildcards okay)• userdn=ildap:///uid=*,dc=x,dc=Orgl';• • Anonymous access• userdn="ldap: ///anyone It;

All authenticated users userdn=t1dap:///a1I~I;

• • Authenticated as the targeted entry itself• userdn=Itldap:///self II;• •

Groups

• Entries can be assigned to a group, and access granted to all members of the group• groupdn=Itldap: ///cn=admins,ou=Groups,dc=example,dc=comlt;• • The two most basic kinds of groups:• Static groups (groupofunig-ueNames structural class)• The DN of each member is listed as an attribute of the group• • Dynamic groups (groupofuRLa auxilliary class)• Objects which match a search filter are members of the group• • A group may be static for some members and dynamic for others

Other Bind Rules

• Can test based on IP address• jp = 1t1921680*H.• • • Can test based on DNS name service• dns = tl* example corn'~• • Can test based on bind method used• authmethod = Itsimplelt;• • authrnethod = tIsasl GSS-API'

Ads and Red Hat Console

• In Directory Console, select the Directory tab, right-click the entry in

the navigation tree and select Set Access Permissions...

• The New... button in the Manage Access Control window opens a GUI

editor, can directly edit LDIF text with Edit Manually

• Show Inherited Ads checkbox displays ACIs inherited from entries

higher in the directory tree

•

Default Ads

• After setup-ds-admin.pl, a small number of ACIs are set

• Anonymous read/search/compare is allowed on the entire user

directory suffix

• Users can modify the values of a short list of attributes in their own

entries

• Three groups and a user are granted all rights

• In addition, the Directory Manager entry, or "root DN", always is

granted all rights

Get Effective Rights

• Can use a special .LDAP control to determine what rights a user has on a given entry

• currently only supported by the Directory Server version of ldapsearch, not OpenLDAP

• can also use Red Hat console

• Two types of results

• Rights on the entry

• Rights on each attribute type in the entry

•

Tips on ACI Design

• Minimize the number of ACIs

• Try to keep the ACIs grouped on common entries at the suffix root and

major branches

• Avoid using explicit deny rules

• Keep the list of attributes short

• Be careful using search filter based ACIs

• Give each AOl a short, informative name

• Questions and Answers

• Summary

• LOAF authentication methods

• configuring and using TLS/SSL

• Understanding and selling Access control Instructions

Unit 6

Linux User Authentication with NSS and PAM

Objectives

• Upon completion of this unit, you should be able to:

• Understand user authentication and authorization

• Explain standard UNIX authentication

• Configure 111w and Name Service Switch (NSS)

• Configure Pluggable Authentication Modules (PAM)

Authentication and Authorization

• Authentication determines whether a client claiming to be a user really

is that user

• For instance, a person logging in with a correct username and password is

authenticated

• Authorization determines whether or not a user is granted access to a

service

• Even if you correctly authenticate, you may be denied access due to other

restrictions (service configuration, /etc/securetty, etc.)

•

Users and Groups

• Every user account has a unique UID

• Every group account has a unique GID

• Every process has a persona

• A UID, primary GID, any supplementary GIDs

• SELinux identity:role:domain context

• Determines what resources the process is authorized to access

•

Standard C Library

• Provides standard APIs for system functions

• GNU libo is used by almost every program in the standard distribution

• Implements APIs in user space or as one or more kernel system calls

•

• Name service, memory handling, I/O, sockets, signals, process control, etc.

•

• Processes get information about users and groups through C library functions

Simple UNIX Authentication

• User provides username and password

• Application uses getpwnam() C library function to look up stored

information for the provided username

• Application hashes the provided password and compares it to the

stored password hash

• If the hashes match, the user is authenticated

•

CLibraryNameServices

• getpwnam() and other C library functions use the I/bc name service to

map a name to information

• Originally, local files like /etc/passwd and /etc/hosts were the only

name service

• To add each new name service (DNS, NIS, and so on) originally

required rewriting Iibc

•

Name Service Switch

• NSS allows new name services to be added as modules without

rewriting I/bc

• To support a new name service, install a new Il/b! Iibnss_service so file

• The order in which name services are checked by library functions is

controlled by /etc/nsswitch.conf

let c/nss witch. conf

• First item on each line is a administrative database of names needed by Iibc

• aliases, ethers, group, hosts, netgroup, networks, passwd, protocols, rpc, services, shadow

• Remainder of line is a list of name services to query which

• contain the relevant information

• Services are checked in the order listed

• pass wd: files n/s Idap

•

Name Service Lookup Results

• Four results are possible when looking up an entry in a particular

• name service

• SUCCESS service ok, found name

• NOTFOUND service ok, name not found

• UNA VAIL service not available

• TRYAGAIN temporary service failure

• By default, return on the first SUCCESS, otherwise continue