User Tools

Site Tools


wiki:certification:lpic301

LPIC 301 Core

In this document you find information for the different objectives from the LPIC 301 exam. Before using this document you should check on the LPI site if the objectives are still the same. This document is provided as an aid in studying and is in noway a guaranty for passing the exam. Try to gain some practical knowledge (go configure a LDAP server) and really understand the concepts how things work, that should help.

Topic 301: Concepts, Architecture and Design

301.1 LDAP Concepts and Architecture (weight: 3)

Description: Candidates should be familiar with LDAP and X.500 concepts

Key Knowledge Areas

  • LDAP and X.500 technical specification
  • Attribute definitions
  • Directory namespaces
  • Distinguished names
  • LDAP Data Interchange Format
  • Meta-directories
  • Changetype operations

The following is a partial list of the used files, terms and utilities:

  • LDIF
  • Meta-directory
  • changetype
  • X.500
  • /var/lib/ldap/*

LDIF

The LDAP Data Interchange Format (LDIF) is a standard data interchange format for representing LDAP directory content as well as directory update (Add, Modify, Delete, Rename) requests. LDAP is an acronym for “Lightweight Directory Access Protocol”. It conveys directory content as a set of records, one record for each object (or entry). It represents update requests as a set of records, one record for each update request. In both cases, the data is presented in a plain text form.

Example LDIF

dn: CN=John Smith,OU=Legal,DC=example,DC=com
changetype: modify
replace:employeeID
employeeID: 1234
-
replace:employeeNumber
employeeNumber: 98722
-
replace: extensionAttribute6
extensionAttribute6: JSmith98
-

dn: CN=Jane Smith,OU=Accounting,DC=example,DC=com
changetype: modify
replace:employeeID
employeeID: 5678
-
replace:employeeNumber
employeeNumber: 76543
-
replace: extensionAttribute6
extensionAttribute6: JSmith14
-

Source Wikipedia

Metadirectory

A metadirectory system provides for the flow of data between one or more directory services and databases, in order to maintain synchronization of that data, and is an important part of identity management systems. The data being synchronized typically are collections of entries that contain user profiles and potentially authentication or policy information. Most metadirectory deployments synchronize data into at least one LDAP-based directory server, to ensure that LDAP-based applications such as single sign-on and portal servers have access to recent data, even if the data is mastered in a non-LDAP data source.

Metadirectory products support filtering and transformation of data in transit.

Metadirectory : SysAdmins only manages OpenLDAP tree, then any changes be propagated automatically to other Directory Services (DS). Users still authenticate to each DS.
Source : http://www.harrysufehmi.com/phpwiki/index.php/OpenLDAPinteroperability

changetype

This can be used in a LDIF

changetype: type

The changetype directive immediately follows a dn: directive and defines the operation to be performed on the entry.

type may take one of the following values:

When the add type is used then subsequent directives will add (create) the entry. If the entry already exists then the changetype: modify form must always be used. add is assumed (defaulted) if no changetype directive is present and the LDIF is being processed using ldapadd.

Examples:

dn: cn=Robert Smith,ou=people,dc=example,dc=com
# adds entry of dn above 
changetype: add
objectclass: inetorgperson
cn: Robert Smith
...
dn: cn=Robert Smith,ou=people,dc=example,dc=com
# delete entry pointed to by dn above 
changetype: delete
dn: cn=Robert Smith,ou=people,dc=example,dc=com
# modifies entry pointed to by dn above 
changetype: modify
# single operation
add: telephonenumber
telephonenumber: 555

More examples

X.500

X.500 is a series of computer networking standards covering electronic directory services.

The primary concept of X.500 is that there is a single Directory Information Tree (DIT), a hierarchical organization of entries which is distributed across one or more servers. An entry consists of a set of attributes, each attribute with one or more values. Each entry has a unique Distinguished name, formed by combining its a Relative distinguished name (RDN), one or more attributes of the entry itself, and the RDNs of each of the superior entries up to the root of the DIT. As LDAP implements a very similar data model to that of X.500, there is further description of the data model in the article on LDAP.

Technically, LDAP is a directory access protocol to an X.500 directory service, the OSI directory service. Initially, LDAP clients accessed gateways to the X.500 directory service. This gateway ran LDAP between the client and gateway and X.500's Directory Access Protocol (DAP) between the gateway and the X.500 server. DAP is a heavyweight protocol that operates over a full OSI protocol stack and requires a significant amount of computing resources. LDAP is designed to operate over TCP/IP and provides most of the functionality of DAP at a much lower cost.

While LDAP is still used to access X.500 directory service via gateways, LDAP is now more commonly directly implemented in X.500 servers.

The stand-alone LDAP daemon, or slapd(8), can be viewed as a lightweight X.500 directory server. That is, it does not implement the X.500's DAP nor does it support the complete X.500 models.

/var/lib/ldap/*

  • Contains database files
  • Contains indexes

:?:FIXME:?:

301.2 Directory Design (weight: 2)

Description: Candidates should be able to design an implement an LDAP directory, while planning an appropriate Directory Information Tree to avoid redundancy. Candidates should have an understanding of the types of data which are appropriate for storage in an LDAP directory

Key Knowledge Areas

  • Define LDAP directory content
  • Organize directory
  • Planning appropriate Directory Information Trees

The following is a partial list of the used files, terms and utilities:

  • Class of Service
  • Directory Information Tree
  • Distinguished name
  • Container

Class of Service

Class of Service (CoS) – a virtual attribute service - some attribute values may not be stored with the entry itself - instead, they are generated by CoS logic as the entry is sent to the client application

Each CoS specification is comprised of the following two types of entry

  • CoS Definition Entry - The CoS definition entry identifies the type of CoS you are using - it is stored as an LDAP subentry below the branch at which it is effective
  • CoS Template Entry – this entry contains a list of the shared attribute values - changes to the template entry attribute values are automatically applied to all the entries sharing the attribute - single CoS might have more than one template entry associated with it


Class of Service Types

  • CoS Pointer - identifies the template entry associated with this CoS definition using the template entry’s DN value
  • CoS Indirect - identifies the template entry using the value of one of the target entry’s attributes e.g. an indirect CoS might specify the manager attribute of a target entry - the value of the manager attribute is then used to identify the template entry - the target entry’s attribute must be single-valued and contain a DN
  • CoS Classic - identifies the template entry using both the template entry’s DN and the value of one of the target entry’s attributes

Source: Fedora Directory Project

Directory Information Tree

A Directory Information Tree (DIT) is data represented in a hierarchical tree-like structure consisting of the Distinguished names (DNs) of the directory entries.

Both the X.500 protocols and the Lightweight Directory Access Protocol (LDAP) use the DIT as their fundamental data structure.

Typically, an X.500 or LDAP deployment for a single organization will have a DIT which consists of two parts:

  • a top level name structure for the name of the organization itself
  • a representation of the data model structure within the organization
Top level naming in a DIT

The top levels of a DIT frequently represent political and geographic divisions. The original assumption of X.500 was that all directory servers would be interconnected to form a single, global namespace. The entries at the top level of the DIT corresponded to countries, identified by their ISO 3166 two letter country code. The entries subordinate to a country's entry would correspond to states or provinces, and national organizations. The naming system for a particular country was determined by that country's national standards body or telecommunications provider.

Organizational structure in a DIT

There are numerous techniques for modeling the elements of an organization represented in the directory (e.g, people, roles, or devices) in a DIT. The determining factors include:

  • requirements of the applications which will be searching and updating the directory
  • the requirement to provide a unique name for each entry
  • the desire for stability of the directory structure
  • the desire for human-readability of the Distinguished names of entries in the directory

Source: Wikipedia

Distinguished name

Each entry has a unique identifier: its Distinguished Name (DN). This consists of its Relative Distinguished Name (RDN) constructed from some attribute(s) in the entry, followed by the parent entry's DN. Think of the DN as a full filename and the RDN as a relative filename in a folder.

What's in a name? The DN of an LDAP entry

All entries stored in an LDAP directory have a unique “Distinguished Name,” or DN. The DN for each LDAP entry is composed of two parts: the Relative Distinguished Name (RDN) and the location within the LDAP directory where the record resides.

The RDN is the portion of your DN that is not related to the directory tree structure. Most items that you'll store in an LDAP directory will have a name, and the name is frequently stored in the cn (Common Name) attribute. Since nearly everything has a name, most objects you'll store in LDAP will use their cn value as the basis for their RDN. If I'm storing a record for my favorite oatmeal recipe, I'll be using cn=Oatmeal Deluxe as the RDN of my entry.

My directory's base DN is dc=foobar,dc=com I'm storing all the LDAP records for my recipes in ou=recipes The RDN of my LDAP record is cn=Oatmeal Deluxe Given all this, what's the full DN of the LDAP record for this oatmeal recipe? Remember, it reads backwards - just like a host name in DNS. cn=Oatmeal Deluxe,ou=recipes,dc=foobar,dc=com

People are always more trouble than inanimate objects Now it's time to tackle the DN of a company employee. For user accounts, you'll typically see a DN based either on the cn or on the uid (User ID). For example, the DN for FooBar's employee Fran Smith (login name: fsmith) might look like either of these two formats:

uid=fsmith,ou=employees,dc=foobar,dc=com (login-based) LDAP (and X.500) use uid to mean “User ID”, not to be confused with the UNIX uid number. Most companies try to give everyone a unique login name, so this approach makes good sense for storing information about employees. You don't have to worry about what you'll do when you hire the next Fran Smith, and if Fran changes her name (marriage? divorce? religious experience?), you won't have to change the DN of the LDAP entry.

cn=Fran Smith,ou=employees,dc=foobar,dc=com (name-based) Here we see the Common Name (CN) entry used. In the case of an LDAP record for a person, think of the common name as their full name. One can easily see the downside to this approach: if the name changes, the LDAP record has to “move” from one DN to another. As indicated above, you want to avoid changing the DN of an entry whenever possible.

Source: ldapman.org

Container

a container is a class, a data structure, or an abstract data type (ADT) whose instances are collections of other objects. They are used to store objects in an organized way following specific access rules.

301.3 Schemas (weight: 3)

Description: Candidates should be familiar with schema concepts, and the base schema files included with an OpenLDAP installation

Key Knowledge Areas

  • LDAP schema concepts
  • Create and modify schemas
  • Attribute and object class syntax

The following is a partial list of the used files, terms and utilities:

  • Distributes schema
  • Extended schema
  • Object Identifiers
  • /etc/ldap/schema/*
  • Object class
  • Attribute
  • include directive

Distribute schema

The contents of the entries in a subtree are governed by a schema.

The schema defines the attribute types that directory entries can contain. An attribute definition includes a syntax, and most non-binary values in LDAPv3 use UTF-8 string syntax. For example, a “mail” attribute might contain the value “user@example.com”. A “jpegPhoto” attribute would contain photograph(s) in binary JPEG/JFIF format. A “member” attribute contains DNs of other directory entries. Attribute definitions also specify whether the attribute is single-valued or multi-valued, how to search/compare the attribute (e.g. case-sensitive vs. case-insensitive and whether substring matching is supported), etc.

The schema defines object classes. Each entry must have an objectClass attribute, containing named classes defined in the schema. The schema definition of the classes of an entry defines what kind of object the entry may represent - e.g. a person, organization or domain. The object class definitions also list which attributes the entry MAY and MUST contain. For example, an entry representing a person might belong to the classes “top” and “person”. Membership in the “person” class would require the entry to contain the “sn” and “cn” attributes, and allow the entry also to contain “userPassword”, “telephoneNumber”, and other attributes. Since entries may belong to multiple classes, each entry has a complex of optional and mandatory attribute sets formed from the union of the object classes it represents. ObjectClasses can be inherited, and a single entry can have multiple objectClasses to define the available and required attributes of the entry itself. A parallel to the schema of an objectClass is a class definition and an instance in Object-oriented programming, representing LDAP objectClass and LDAP entry, respectively.

The schema also includes various other information controlling directory entries.

Most schema elements have a name and a globally unique Object identifier (OID).

Directory servers may publish the directory schema controlling an entry at a base DN given by the entry's subschemaSubentry operational attribute. (An operational attribute describes operation of the directory rather than user information and is only returned from a search when it is explicitly requested.)

Server administrators can define their own schemas in addition to the standard ones. A schema for representing individual people within organizations is termed a white pages schema.

Extended schema

Extended schema's are defined in the same way as normal (structural) schema's with the key difference that they can not be used on its own. They can only used as an extension of the normal (structural) schemas. Extended schema's are also called auxiliary schema's

Object Identifiers

An object identifier or OID is an identifier used to name an object (compare URN). Structurally, an OID consists of a node in a hierarchically-assigned namespace, formally defined using the ITU-T's ASN.1 standard. Successive numbers of the nodes, starting at the root of the tree, identify each node in the tree. Designers set up new nodes by registering them under the node's registration authority. Within LDAP schemas, each object class and each attribute type has an unique OID

/etc/ldap/schema/*

/etc/ldap/schema is the location were the files containing the different schema's (structural and auxiliary) are normally stored.

Object class

An object class is a container holding one or multiple attributes. Each object class definition has an unique OID. The definition describes which attributes are required or optional. An object class can inherent its definition from other Object classes and augment it with its own attributes.

Attribute

An attribute definition describes the type, syntax, length and some additional properties of the data that can be entered for an attribute.

include directive

In slapd.conf the include directive is used to tell OpenLDAP's slapd which schema file should be loaded at startup time.

Topic 302: Installation and Development

302.1 Compiling and Installing OpenLDAP (weight: 3)

Description: Candidates should be able to compile and install OpenLDAP from source and from packages

Key Knowledge Areas

  • Compile and configure OpenLDAP from source
  • Knowledge of OpenLDAP backend databases
  • Manage OpenLDAP daemons
  • Troubleshoot errors during installation

The following is a partial list of the used files, terms and utilities:

  • make
  • gpg
  • rpm
  • dpkg
  • bdb
  • slapd
  • slurpd

make

make is a utility for automatically building large applications. Files specifying instructions for make are called Makefiles. make is an expert system which tracks which files have changed since the last time the project was built and invokes the compiler on only those source code files and their dependencies.

make is most commonly used in C/C++ projects, but in principle it can be used with almost any software project.

gpg

The GNU Privacy Guard (GnuPG or GPG) is a free software replacement for the PGP suite of cryptographic software. GnuPG allows to encrypt and sign your data and communication, features a versatile key managment system as well as access modules for all kind of public key directories. GnuPG, also known as GPG, is a command line tool with features for easy integration with other applications.

Command Examples :?:

RPM

RPM Package Manager (originally Red Hat Package Manager, abbreviated RPM) is a package management system. The name RPM refers to two things: a software package file format, and a free software tool which installs, updates, uninstalls, verifies and queries software packaged in this format. RPM was intended primarily for Linux distributions; the file format RPM is the baseline package format of the Linux Standard Base.

Command examples

Install package:
$ rpm -vih package.rpm
List all installed package
$ rpm -qa
Information about an installed package
$ rpm -qi package
Information about rpm file
$ rpm -qip package.rpm
Remove installed package
$ rpm -ve package
Upgrade package
$ rpm -vUh package.rpm
List all file in package
$ rpm -ql package
Display which package owns a file
$ rpm -qf /path/to/file

For more commands see the manual page of rpm (man rpm)

dpkg

dpkg (short for Debian package) is the base of the Debian package management system. It was created by Ian Jackson in 1993. dpkg is similar to RPM, as it is used to install, remove, and provide information about .deb packages.

dpkg itself is a low level tool; higher level tools, such as APT, are used to fetch packages from remote locations or deal with complex package relations. End users are encouraged to use tools like aptitude or synaptic, having a more sophisticated way of dealing with package relationships and a friendlier interface.

Command Examples FIXME

bdb

(BDB) is a high-performance, embedded database library with bindings in C, C++, Java, Perl, Python, Ruby, Tcl, Smalltalk and many other programming languages. BDB stores arbitrary key/data pairs as byte arrays, and supports multiple data items for a single key. BDB can support thousands of simultaneous threads of control or concurrent processes manipulating databases as large as 256 terabytes, on a wide variety of systems including most UNIX-like and Windows systems as well as real-time operating systems.

BDB can be used as backend for slapd

Command Examples :?:

slapd

Stand-alone LDAP Daemon.

Commandline options explained later in this document

slurpd

Standalone LDAP Update Replication Daemon.

-d debug-levelTurn on debugging as defined by debug-level. If this option is specified, even with a zero argument, slurpd will not fork or disassociate from the invoking terminal. Some general operation and status messages are printed for any value of debug-level. debug-level is taken as a bit string, with each bit corresponding to a different kind of debugging information. See <ldap.h> for details.
-f slapd-config-fileSpecifies the slapd configuration file. The default is /etc/openldap/slapd.conf.
-r slapd-replog-fileSpecifies the name of the slapd replication logfile. Normally, the name of the replication log file is read from the slapd configuration file. The file should be located in a directory with limited read/write/execute access. The -r option allows you to override this. In conjunction with the -o option, you can process a replication log file in a “one-shot” mode. For example, if slurpd has encountered errors in processing a replication log, you can run it in one-shot mode and give the rejection file name as the argument to the -r option, once you've resolved the problem which caused the replication to fail.
-oRun in “one-shot” mode. Normally, slurpd processes the replog file and then watches for more replication entries to be appended. In one-shot mode, slurpd processes a replication log and exits.
-t temp-dirslurpd copies the replication log to a working directory before processing it. The directory permissions should limit read/write/execute access as temporary files may contain sensitive information. This option allows you to specify the location of these temporary files. The default is /var/openldap-slurp.

302.2 Developing for LDAP with Perl/C++ (weight: 1)

Description: Candidates should be able to write basic Perl scripts to interact with an LDAP directory

Key Knowledge Areas

  • Syntax of Perl's Net::LDAP module
  • Write Perl scripts to bind, search, and modify directories

The following is a partial list of the used files, terms and utilities:

  • Net::LDAP
  • Perl
  • C++

Syntax of Perl's Net::LDAP module

Write Perl scripts to bind, search, and modify directories

#!/usr/bin/perl
 
use Net::LDAP;
 
# Create object and open a connection to the ldap server 
$ldap = Net::LDAP->new( 'ldap.bigfoot.com' ) or die "$@";
 
# Anonymous bind (start session)
$mesg = $ldap->bind;
# or bind using dn and password
$mesg = $ldap->bind( 'cn=root, o=University of Michigan, c=us',
                     password => 'secret'
                   );
 
# Perform search
$mesg = $ldap->search( 
                        base   => "c=US",
                        filter => "(&(sn=Barr) (o=Texas Instruments))"
                     );
 
# Check for errors
$mesg->code && die $mesg->error;
 
# Print result
foreach $entry ($mesg->entries) { $entry->dump; }
 
# Modify entry
$dn = "uid=joe,o=University of Michigan, c=us";
$mesg = $ldap->modify( $dn,
	changes => [
		add     => [ sn => 'User' ],                    # Add sn=User
		delete  => [ faxNumber => []],                  # Delete all fax numbers
		delete  => [ telephoneNumber => ['911']],       # delete phone number 911
		replace => [ email => 'test@pisoftware.com']    # change email address
	]
);
 
# Check for errors
$mesg->code && die $mesg->error;
 
# End session
$mesg = $ldap->unbind;

Net::LDAP

Net::LDAP is a collection of modules that implements a LDAP services API for Perl programs. The module may be used to search directories or perform maintenance functions such as adding, deleting or modifying entries.

Perl

Perl is a dynamic programming language created by Larry Wall and first released in 1987. Perl borrows features from a variety of other languages including C, shell scripting (sh), AWK, sed and Lisp.

Structurally, Perl is based on the brace-delimited block style of AWK and C, and was widely adopted for its strengths in string processing and lack of the arbitrary limitations of many scripting languages at the time.

C++

C++ (pronounced “see plus plus”, IPA: /siː plʌs plʌs/) is a general-purpose programming language with high-level and low-level capabilities. It is a statically typed, free-form, multi-paradigm, usually compiled language supporting procedural programming, data abstraction, object-oriented programming, and generic programming.

C++ is regarded as a mid-level language. This indicates that C++ comprises a combination of both high-level and low-level language features.

Topic 303: Configuration

303.2 Access Control Lists in LDAP (weight: 2)

Description: Candidates should be able to plan and implement access control lists

Key Knowledge Areas

  • Plan LDAP access control lists
  • Grant and revoke LDAP access permissions
  • Access control syntax

The following is a partial list of the used files, terms and utilities:

  • ACL
  • slapd.conf
  • anonymous
  • users
  • self
  • none
  • auth
  • compare
  • search
  • read
  • write

ACL

Access Control List is a list of permissions attached to an object. The list specifies who or what is allowed to access the object and what operations are allowed to be performed on the object. In a typical ACL, each entry in the list specifies a subject and an operation: for example, the entry (Alice, delete) on the ACL for file XYZ gives Alice permission to delete file XYZ.

OpenLDAP ACL

# ACL1
access to attr=userpassword
       by self       write
       by anonymous  auth
       by group.exact="cn=itpeople,ou=groups,dc=example,dc=com"
                     write
       by *          none
# ACL2
access to attr=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

The first acl allows the following:

  • Owner of the object may modify the attribute userpassword (so he may set his own password).
  • An anonymous user may perform authentications against the directory.
  • Users in the group defined in the object cn=itpeople,ou=groups,dc=example,dc=com may modify the attribute userpassword.
  • All other actions are not allow.

The seccond acl allow the following:

  • Owner of the object may modify the attributes carlicense,homepostaladdress,homephone
  • Users in the group defined in the object cn=hrpeople,ou=groups,dc=example,dc=com may modify the attributes carlicense,homepostaladdress,homephone
  • All other actions are not allow.

The third acl allow the following:

  • Owner of the object may write data to it.
  • Users in the group defined in the object cn=hrpeople,ou=groups,dc=example,dc=com may modify everything
  • Authenticated users may read everything
  • All other actions are not allow.

slapd.conf

The ACL's for OpenLDAP are defined in the slapd.conf file.

anonymous

Anonymous describes directory access when the user is connected without authenticating himself.

users

Everyone who has authenticated himself with the Directory server.

self

Every entry in the directory has an owner. When using self in an acl you can for example limit the users access to objects which are owned by the user.

none

None means no access or no permission.

auth

Controls if a user may authenticate with the Directory Server

compare

Controls if a user may execute a compare.

Controls if a user may perform a search in the whole or specified dn.

read

Controls if a user may read information from the Directory.

write

Controls if a user may write data to the Directory

:?:FIXME Have users also read access when granted write access:?:

303.3 LDAP Replication (weight: 5)

Description: Candidates should be familiar with the various replication strategies available with OpenLDAP

Key Knowledge Areas

  • Replication concepts
  • Configure OpenLDAP ? replication
  • Execute and manage slurpd
  • Analyze replication log files
  • Understand replica hubs
  • LDAP referrals
  • LDAP sync replication

The following is a partial list of the used files, terms and utilities:

  • slurpd
  • slapd.conf
  • master / slave server
  • consumer
  • replica hub
  • one-shot mode
  • referral
  • syncrepl
  • pull-based / push-based synchronization
  • refreshOnly and refreshAndPersist
  • replog

Replication concepts

Replication is the technique of duplicating data between multiple directories for performance, scalability and redundancy. It is a way to bring multiple geographic areas together into one enterprise directory. These multiple copies are kept in sync with one or more main directory server called Supplier or what most call a master or writable server and one or more Consumers or what most call replica or read only servers. Through replication, a change made to one directory is propagated to one or more additional directories. In effect, a change to one directory shows up on multiple different directories. Replication provides a directory user with two main advantages:

  Reliability: 
  The consumers act as backup copies of the suppliers and data can
  be restored from the consumer in case all data is lost from the supplier due to
  some catastrophic failure. With multiple masters you will also have a writable
  backup to take over if the first master goes down.
  Performance: 
  Client search requests can be distributed across the
  Consumers instead of the single Supplier, thereby reducing the response
  time of the Supplier and hence increasing performance. With multiple master
  you will also be able to distribute applications to different masters to offload
  the writable work on having only one master.

slurpd

Slurpd provides the capability for a master slapd to propagate changes to slave slapd instances, implementing the master/slave replication scheme. Slurpd runs on the same host as the master slapd instance.

slapd.conf

portion of the slapd.conf of master server

replica      host=slave.hostname:389
             suffix="dc=example,dc=com"
             binddn="cn=replicator,dc=example,dc=com"
             credentials=replicationpassword
             bindmethod=simple
             tls=yes

portion of the slapd.conf of slave server

## -- slave slapd --
## Define the DN that will be used by the master slurpd to replicate data. Normally,
## this is the rootdn of the slave server or, at the minimum, a DN that is allowed
## write access to all entries via an ACL.
updatedn     "cn=replicator,dc=example,dc=com"


## -- slave slapd --
## Specify the LDAP URL of the master server, which can accept update requests.
updateref     ldap://master.ldapserver

master / slave server

One directory server (master) has the writable dataset. One or more directory servers (slave) have read-only copies of the data. Through the process of replication the updates are distributed from the master directory server to the slave directory servers. When a client attempts to update by using on of the slave servers it is referred to the master server.

consumer

Consumer server: A server (slave) which receives changes through replication from another (supplier) server (master).

replica hub

  • Master replicates to hub which replays updates to futher servers
  • Helps balance very heavy loads - master can be used for all writes, and pass off all replication to hub
  • Can replicate out to local hubs in geographically disperse topologies - reduces cost
  • Increase performance - put all reads on “bottom” servers

one-shot mode

It is possible to use slurpd to process a rejection log with its “one-shot mode.” In normal operation, slurpd watches for more replication records to be appended to the replication log file. In one-shot mode, by contrast, slurpd processes a single log file and exits. Slurpd ignores ERROR lines at the beginning of replication log entries, so it's not necessary to edit them out before feeding it the rejection log.

To use one-shot mode, specify the name of the rejection log on the command line as the argument to the -r flag, and specify one-shot mode with the -o flag. For example, to process the rejection log file /usr/local/var/openldap/replog.slave.example.com:389 and exit, use the command

slurpd -r /usr/tmp/replog.slave.example.com:389 -o

referral

Referral means telling the client to re-ask it's question somewhere else. For example (using replication):

  1. Client sends modification to replica
  2. Replica returns referral of master to client
  3. Client resubmits modification to master
  4. Master returns results to client
  5. Master updates replica with change

syncrepl

The LDAP Sync replication engine, syncrepl for short, is a consumer-side replication engine that enables the consumer LDAP server to maintain a shadow copy of a DIT fragment. A syncrepl engine resides at the consumer-side as one of the slapd (8) threads. It creates and maintains a consumer replica by connecting to the replication provider to perform the initial DIT content load followed either by periodic content polling or by timely updates upon content changes. Syncrepl provides a stateful replication which supports both the pull-based and the push-based synchronizations and does not mandate the use of the history store.

Configuring:

Set up the provider slapd

There is no special slapd.conf (5) directive for the provider syncrepl server except for the session log directive. Because the LDAP Sync search is subject to access control, proper access control privileges should be set up for the replicated content.

When creating a provider database from the LDIF file using slapadd (8), contextCSN and the syncProviderSubentry entry must be created. slapadd -p -w will create a new contextCSN from the entryCSNs of the added entries. It is also possible to create the syncProviderSubentry with an appropriate contextCSN value by directly including it in the ldif file. slapadd -p will preserve the provider's contextCSN or will change it to the consumer's contextCSN if it is to promote a replica to the provider's content. The syncProviderSubentry can be included in the ldif output when slapcat (8) is given the -m flag; the syncConsumerSubentry can be retrieved by the -k flag of slapcat (8).

The session log is configured by

      sessionlog <sid> <limit>

directive, where <sid> is the ID of the per-scope session log in the provider server and <limit> is the maximum number of session log entries the session log store can record. <sid> is an integer no longer than 3 decimal digits. If the consumer server sends a synchronization cookie containing sid=<sid> where <sid> matches the session log ID specified in the directive, the LDAP Sync search is to utilize the session log store.

Set up the consumer slapd

The syncrepl replication is specified in the database section of slapd.conf (5) for the replica context. The syncrepl engine is backend independent and the directive can be defined with any database type.

      syncrepl rid=123
              provider=ldap://provider.example.com:389
              type=refreshOnly
              interval=01:00:00:00
              searchbase="dc=example,dc=com"
              filter="(objectClass=organizationalPerson)"
              scope=sub
              attrs="cn,sn,ou,telephoneNumber,title,l"
              schemachecking=off
              updatedn="cn=replica,dc=example,dc=com"
              bindmethod=simple
              binddn="cn=syncuser,dc=example,dc=com"
              credentials=secret

In this example, the consumer will connect to the provider slapd at port 389 of ldap://provider.example.com to perform a polling (refreshOnly) mode of synchronization once a day. It will bind as cn=syncuser,dc=example,dc=com using simple authentication with password “secret”. Note that the access control privilege of cn=syncuser,dc=example,dc=com should be set appropriately in the provider to retrieve the desired replication content. The consumer will write to its database with the privilege of the cn=replica,dc=example,dc=com entry as specified in the updatedn= directive. The updatedn entry should have write permission to the replica content.

The synchronization search in the above example will search for the entries whose objectClass is organizationalPerson in the entire subtree rooted at dc=example,dc=com. The requested attributes are cn, sn, ou, telephoneNumber, title, and l. The schema checking is turned off, so that the consumer slapd (8) will not enforce entry schema checking when it process updates from the provider slapd (8).

pull-based / push-based synchronization

Pull-based synchronization, a slave server periodically retrieves the updates from the master directory server. Syncrepl in refreshOnly mode is an example of pull-based synchronization. Push-based synchronization, the master server send the update to slave servers when they are received. Slurpd is an example of push-based synchronization.

refreshOnly and refreshAndPersist

In its basic refreshOnly mode synchronization, the provider uses a pull-based synchronization where the consumer servers need not be tracked and no history information is maintained. The information required for the provider to process periodic polling requests is contained in the synchronization cookie of the request itself. To optimize the pull-based synchronization, syncrepl utilizes the present phase of the LDAP Sync protocol as well as its delete phase, instead of falling back on frequent full reloads. To further optimize the pull-based synchronization, the provider can maintain a per-scope session log as the history store. In its refreshAndPersist mode of synchronization, the provider uses a push-based synchronization. The provider keeps track of the consumer servers that have requested the persistent search and sends them necessary updates as the provider replication content gets modified.

replog

The file slapd.replog is produced by the stand-alone LDAP daemon, slapd(8), when changes are made to its local database that are to be propagated to one or more replica slapds. The file consists of zero or more records, each one corresponding to a change, addition, or deletion from the slapd database. The file is meant to be read and processed by slurpd(8), the stand-alone LDAP update replication daemon. The records are separated by a blank line. Each record has the following format.

303.4 Securing the Directory (weight: 4)

Description: Candidates should be able to configure encrypted access to the LDAP directory, and restrict access at the firewall level

Key Knowledge Areas

  • Securing the directory with SSL and TLS
  • Firewall considerations
  • Unauthenticated access methods
  • User / password authentication methods
  • Maintanence of SASL user DB
  • Client / server certificates

The following is a partial list of the used files, terms and utilities:

  • SSL / TLS
  • Security Strength Factors (SSF)
  • SASL
  • proxy authorization
  • StartTLS
  • slapd.conf
  • iptables

SSL / TLS

Transport Layer Security (TLS) is the standard name for the Secure Socket Layer (SSL). The terms (unless qualified with specific version numbers) are generally interchangable.

server - slapd.conf:

# Sample security restrictions
#
# Disallow clear text exchange of passwords
# disallow bind_simple_unprotected
#
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64 

# CA signed certificate and server cert entries:

TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCACertificateFile /usr/var/openldap-data/cacert.pem
TLSCertificateFile /usr/var/openldap-data/servercrt.pem
TLSCertificateKeyFile /usr/var/openldap-data/serverkey.pem

# Use the following if client authentication is required
TLSVerifyClient demand
# ... or not desired at all
#TLSVerifyClient never

Start server:

% /usr/libexec/slapd -h "ldap:/// ldaps:///"

client - ldap.conf

#
# Global LDAP settings
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.
HOST myserver.com
PORT 636

TLS_CACERT /etc/ssl/certs/cacert.pem
TLS_REQCERT demand 

Security Strength Factors (SSF)

OpenLDAP has multiple SSFs. For each session, there is one for SASL, one for TLS, etc., and an overall session SSF (the greatest SSF of any particular layer).

From slapd.conf(5):

an integer approximate to effective key length used for encryption. 
   0 (zero) implies no protection,
   1 implies integrity protection only,
   56 allows DES or other weak ciphers,
   112 allows triple DES and other strong ciphers,
   128 allows RC4, Blowfish and other modern strong ciphers.

SASL

OpenLDAP clients and servers are capable of authenticating via the Simple Authentication and Security Layer (SASL) framework, which is detailed in RFC2222. This chapter describes how to make use of SASL in OpenLDAP.

There are several industry standard authentication mechanisms that can be used with SASL, including GSSAPI for Kerberos V, DIGEST-MD5, and PLAIN and EXTERNAL for use with Transport Layer Security (TLS).

SASL offers many different authentication mechanisms. This section briefly outlines security considerations.

Some mechanisms, such as PLAIN and LOGIN, offer no greater security over LDAP simple authentication. Like LDAP simple authentication, such mechanisms should not be used unless you have adequate security protections in place. It is recommended that these mechanisms be used only in conjunction with Transport Layer Security (TLS). Use of PLAIN and LOGIN are not discussed further in this document.

The DIGEST-MD5 mechanism is the mandatory-to-implement authentication mechanism for LDAPv3. Though DIGEST-MD5 is not a strong authentication mechanism in comparison with trusted third party authentication systems (such as Kerberos or public key systems), it does offer significant protections against a number of attacks. Unlike the CRAM-MD5 mechanism, it prevents chosen plaintext attacks. DIGEST-MD5 is favored over the use of plaintext password mechanisms. The CRAM-MD5 mechanism is deprecated in favor of DIGEST-MD5.

The GSSAPI mechanism utilizes Kerberos V to provide secure authentication services. The KERBEROS_V4 mechanism is available for those using Kerberos IV. Kerberos is viewed as a secure, distributed authentication system suitable for both small and large enterprises.

The EXTERNAL mechanism utilizes authentication services provided by lower level network services such as TLS (TLS). When used in conjunction with TLS X.509-based public key technology, EXTERNAL offers strong authentication.

There are other strong authentication mechanisms to choose from, including OTP (one time passwords) and SRP (secure remote passwords). These mechanisms are not discussed in this document.

Source: OpenLDAP Administrators Guide

proxy authorization

The SASL offers a feature known as proxy authorization, which allows an authenticated user to request that they act on the behalf of another user. This step occurs after the user has obtained an authentication DN, and involves sending an authorization identity to the server. The server will then make a decision on whether or not to allow the authorization to occur. If it is allowed, the user's LDAP connection is switched to have a binding DN derived from the authorization identity, and the LDAP session proceeds with the access of the new authorization DN.

For example, users may be directed to a web page to make changes to their personal information in their LDAP entry. The users authenticate to the web server to establish their identity, but the web server CGI cannot authenticate to the LDAP server as that user to make changes for them. Instead, the web server authenticates itself to the LDAP server as a service identity, say,

      cn=WebUpdate,dc=example,dc=com

and then it will SASL authorize to the DN of the user. Once so authorized, the CGI makes changes to the LDAP entry of the user, and as far as the slapd server can tell for its ACLs, it is the user themself on the other end of the connection. The user could have connected to the LDAP server directly and authenticated as themself, but that would require the user to have more knowledge of LDAP clients, knowledge which the web page provides in an easier format.

The decision to allow an authorization to proceed depends on the rules and policies of the site where LDAP is running, and thus cannot be made by SASL alone. The SASL library leaves it up to the server to make the decision. The LDAP administrator sets the guidelines of who can authorize to what identity by adding information into the LDAP database entries. By default, the authorization features are disabled, and must be explicitly configured by the LDAP administrator before use.

Once slapd has the authorization DN, the actual approval process begins. There are two attributes that the LDAP administrator can put into LDAP entries to allow authorization:

      authzTo
      authzFrom

Both can be multivalued. The authzTo attribute is a source rule, and it is placed into the entry associated with the authentication DN to tell what authorization DNs the authenticated DN is allowed to assume. The second attribute is a destination rule, and it is placed into the entry associated with the requested authorization DN to tell which authenticated DNs may assume it.

The choice of which authorization policy attribute to use is up to the administrator. Source rules are checked first in the person's authentication DN entry, and if none of the authzTo rules specify the authorization is permitted, the authzFrom rules in the authorization DN entry are then checked. If neither case specifies that the request be honored, the request is denied. Since the default behaviour is to deny authorization requests, rules only specify that a request be allowed; there are no negative rules telling what authorizations to deny.

The value(s) in the two attributes are of the same form as the output of the replacement pattern of a authz-regexp directive: either a DN or an LDAP URL. For example, if a authzTo value is a DN, that DN is one the authenticated user can authorize to. On the other hand, if the authzTo value is an LDAP URL, the URL is used as an internal search of the LDAP database, and the authenticated user can become ANY DN returned by the search. If an LDAP entry looked like:

      dn: cn=WebUpdate,dc=example,dc=com
      authzTo: ldap:///dc=example,dc=com??sub?(objectclass=person)

then any user who authenticated as cn=WebUpdate,dc=example,dc=com could authorize to any other LDAP entry under the search base dc=example,dc=com which has an objectClass of Person.

StartTLS

StartTLS is the name of the standard LDAP operation for initiating TLS/SSL. TLS/SSL is initiated upon successful completion of this LDAP operation. No alternative port is necessary. It is sometimes referred to as the TLS upgrade operation, as it upgrades a normal LDAP connection to one protected by TLS/SSL.

ldaps: and LDAPS refers to “LDAP over TLS/SSL” or “LDAP Secured”. TLS/SSL is initated upon connection to an alternative port (normally 636). Though the LDAPS port (636) is registered for this use, the particulars of the TLS/SSL initiation mechanism are not standardized. Once initiated, there is no difference between ldaps: and StartTLS. They share the same configuration options (excepting ldaps: requires configuration of a separate listener, see slapd(8)'s -h option) and result in like security services being established. === iptables === * ldap: + StartTLS should be directed to a normal LDAP port (normally 389), not the ldaps: port. * ldaps: should be directed to an LDAPS port (normally 636), not the LDAP port.

303.5 LDAP Server Performance Tuning (weight: 2)

Description: Candidates should be capable of measuring the performance of an LDAP server, and tuning configuration directives

Key Knowledge Areas

  • Measure LDAP performance
  • Tune software configuration to increase performance
  • Understand indexes

The following is a partial list of the used files, terms and utilities:

  • index
  • slapd.conf
  • DB_CONFIG

index

Each index requires time to maintain and uses additional memory.
General rule:

  • index attributes you frequently search for.
  • don't go overboard with indexes. Unused indexes must be maintained and hence can only slow things down.


The index directive is only effective on initial load of the directory (using ldapadd). If indexes are subsequently changed the directory needs to be re-indexed using slapindex (caution: must stop slapd first).

Format:

index attrlist | default indices

# indices = [pres [,approx] [,eq] [,sub] [,special]]

The index directive defines what indexes will be maintained by OpenLDAP. Any number of index parameters may be included. If an attribute does not appear in an index directive it can still be used in a search filter - but if it occurs frequently it will hurt performance - once in a lifetime is not too bad!

attrlist may be either a single attribute or a comma separated list.

The optional parameter default stores the supplied indices and uses them on any subsequent index parameter that does does not have an indices entry. The default value must be defined before any index which does not have a indices value. A subsequent default will be used for index parameters following the new default.

pres should be used if use searches of the form 'objectclass=person' or 'attribute=mail' will be used.

approx MUST be used if use searches of the form 'sn~=person' (a 'sounds-alike' search) will be used.

eq should be used if searches of the form 'sn=smith' will be used i.e no wildcards are included (uses the EQUALITY rule only).

sub should be used if use searches of the form 'sn=sm*' i.e wildcards are included (uses the SUBSTR rule). This rule may be enhanced by a using subinitial (optimised for 'sn=s*'), subany (optimised for 'sn=*n*') or subfinal (optimised for 'sn=*th'). One or more sub parameters may be included.

special may be either nolang or nosubtypes which are related to subtypes.

Careful attention to what indexes are maintained based on the application requirements will significantly affect directory read performance - conversely there is no point in indexing a field if no searches ever it. If all the searches use EQUALITY rules only then there is no point in indexing for sub since the more indexes maintained the more memory is consumed and the bigger the hit on a write or modify operation to the directory.

Examples:

index default pres,eq
index cn,sn,uid
# simple use of the default value
# defines presence and equality indexes for 
# attributes cn, sn and uid
# exactly the same as the three index directives below
index cn pres,eq
index sn pres,eq
index uid pres,eq

index cn eq,sub,subinitial
# creates indexes for attribute cn (commonname)
# EQUALITY, SUBSTR searches and further optimises
# for sc=a* type searches

index sn eq,approx,sub
# creates indexes for sn (surname) on
# EQUALITY and SUBSTR searches
# NOTE: The approx index is a waste of time because
#       there is no ORDERING rule for sn approx is present
#       only to illustrate the parameter exists

index mail pres,eq,sub
# creates indexes for attribute mail on
# presence, EQUALITY and SUBSTR

index objectclass eq
# optimises searches of form objectclass=person

slapd.conf

cachesize

Format:

cachesize integer

The cachesize directive defines the number of entries that the LDAP backend will maintain in memory. Do not confuse this directive with the BDB set_cachesize directive - they control different behaviours.

For maximum performance this figure should be as high as practical or as close as practical to the number of records maintained in the directory. The default is 1000. Examples:

cachesize 10000
# LDAP maintains 10,000 entries in memory 

dbnosync

Format:

dbnosync

The dbnosync directive specifies that the database does NOT need to be updated immediately with any in-memory records. This option will increase performance on writes but has the disadvantage that if there is a system failure before the disk and memory are re-synchronised then data may be lost. The memory and disk are re-synchronised using the checkpoint directive. The default (no parameter present) is that disk updates are done immediately. Examples:

dbnosync
# updates are allowed to remain pending 

dirtyread

Format:

dirtyread

The dirtyread directive allows OpenLDAP to return in-memory data that may not yet have been written to disc. If the subsequent write operation fails this data will be discarded. The user may have received a result that incorrectly reflects the final state of the directory.

Specifying this option may speed up directory performance at the risk of some inconsistency. The default (parameter not present) is not to return in-memory data that has not yet been written to disc. Examples:

dirtyread
# user MAY receive a result that is inconsistent
# with the final state of the directory

FIXME Other important options?

DB_CONFIG

Wherer to use a DB_CONFIG file is simple - if you care about performance use it. If you don't care - forget it. BUT if you elect not to use a DB_CONFIG you MUST use a checkpoint directive. Increasingly the OpenLDAP advice seems to be to use DB_CONFIG rather that pass parameters through via slapd.conf.

The DB_CONFIG file is located as defined in the directory directive. The directives used in this file are fully, if not clearly, explained in the BDB Manual. You can replace the checkpoint, lockdetect, dbnosync directives with the equivalent directives in the DB_CONFIG file as well as add additional tuning directives as required.

Example DB_CONFIG file:

# replaces lockdetect directive
set_lk_detect DB_LOCK_EXPIRE
# OR set lk_detect DB_LOCK_DEFAULT

# uncomment if dbnosync required
# set_flags DB_TXN_NOSYNC
# multiple set_flags directives allowed

# sets max log size = 5M (BDB default=10M)
set_lg_max 5242880

set_cachesize 0 5242880 1
# sets a database cache of 5M and 
# allows fragmentation
# does NOT replace slapd.conf cachesize 
# this is a database parameter

txn_checkpoint 128 15 0
# replaces checkpoint in slap.conf
# writes checkpoint if 128K written or every 15 mins
# 0 = no writes - no update 

More information

303.6 OpenLDAP Daemon Configuration (weight: 2)

Description: Candidates should have knowledge of the common slapd.conf configuration directives, and be familiar with the basic slapd command line options

Key Knowledge Areas

  • slapd.conf configuration directives
  • slapd.conf database definitions
  • slapd and its command line options
  • Analyze slapd log files

The following is a partial list of the used files, terms and utilities:

  • slapd.conf
  • slapd
  • /var/lib/ldap/*
  • loglevel

slapd.conf

Example of an basic slapd.conf file:

#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include         /etc/openldap/schema/core.schema

# Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral       ldap://root.openldap.org

pidfile         /var/run/slapd.pid
argsfile        /var/run/slapd.args

# Load dynamic backend modules:
# modulepath    /usr/libexec/openldap
# moduleload    back_bdb.la
# moduleload    back_ldap.la
# moduleload    back_ldbm.la
# moduleload    back_passwd.la
# moduleload    back_shell.la

# Sample security restrictions
#       Require integrity protection (prevent hijacking)
#       Require 112-bit (3DES or better) encryption for updates
#       Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64

# Sample access control policy:
#       Root DSE: allow anyone to read it
#       Subschema (sub)entry DSE: allow anyone to read it
#       Other DSEs:
#               Allow self write access
#               Allow authenticated users read access
#               Allow anonymous users to authenticate
#       Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
#       by self write
#       by users read
#       by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn.  (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!

#######################################################################
# BDB database definitions
#######################################################################

database        bdb
suffix          "dc=my-domain,dc=com"
rootdn          "cn=Manager,dc=my-domain,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoid.  See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw          secret
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory       /var/openldap-data
# Indices to maintain
index   objectClass     eq

slapd

-T {a:c:d:i:p:t:acl:auth} Run in Tool mode. The additional argument selects whether to run as slapadd, slapcat, slapdn, slapindex, slappasswd, or slaptest (slapacl and slapauth need the entire “acl” and “auth” option value to be spelled out, as “a” is reserved to slapadd). This option should be the first option specified when it is used; any remaining options will be interpreted by the corresponding slap tool program, according to the respective man pages. Note that these tool programs will usually be symbolic links to slapd. This option is provided for situations where symbolic links are not provided or not usable.
-d debug-level Turn on debugging as defined by debug-level. If this option is specified, even with a zero argument, slapd will not fork or disassociate from the invoking terminal. Some general operation and status messages are printed for any value of debug-level. debug-level is taken as a bit string, with each bit corresponding to a different kind of debugging information. See <ldap_log.h> for details. Remember that if you turn on packet logging, packets containing bind passwords will be output, so if you redirect the log to a logfile, that file should be read-protected.
-s syslog-level This option tells slapd at what level debugging statements should be logged to the syslog(8) facility.
-n service-name Specifies the service name for logging and other purposes. Defaults to basename of argv[0], i.e.: “slapd”.
-l syslog-local-user Selects the local user of the syslog(8) facility. Value can be LOCAL0, through LOCAL7, as well as USER and DAEMON. The default is LOCAL4. However, this option is only permitted on systems that support local users with the syslog(8) facility.
-f slapd-config-file Specifies the slapd configuration file. The default is /etc/openldap/slapd.conf.
-F slapd-config-directory Specifies the slapd configuration directory. The default is /etc/openldap/slapd.d. If both -f and -F are specified, the config file will be read and converted to config directory format and written to the specified directory. If neither option is specified, slapd will attempt to read the default config directory before trying to use the default config file. If a valid config directory exists then the default config file is ignored. All of the slap tools that use the config options observe this same behavior.
-h URLlistslapd will by default serve ldap:/// (LDAP over TCP on all interfaces on default LDAP port). That is, it will bind using INADDR_ANY and port 389. The -h option may be used to specify LDAP (and other scheme) URLs to serve. For example, if slapd is given -h “ldap://127.0.0.1:9009/ ldaps:/ ldapi:/”, it will listen on 127.0.0.1:9009 for LDAP, 0.0.0.0:636 for LDAP over TLS, and LDAP over IPC (Unix domain sockets). Host 0.0.0.0 represents INADDR_ANY (any interface). A space separated list of URLs is expected. The URLs should be of the LDAP, LDAPS, or LDAPI schemes, and generally without a DN or other optional parameters (excepting as discussed below). Support for the latter two schemes depends on selected configuration options. Hosts may be specified by name or IPv4 and IPv6 address formats. Ports, if specified, must be numeric. The default ldap: port is 389 and the default ldaps: port is 636. The listener permissions are indicated by “x-mod=-rwxrwxrwx”, “x-mod=0777” or “x-mod=777”, where any of the “rwx” can be “-” to suppress the related permission, while any of the “7” can be any legal octal digit, according to chmod(1). The listeners can take advantage of the “x-mod” extension to apply rough limitations to operations, e.g. allow read operations (“r”, which applies to search and compare), write operations (“w”, which applies to add, delete, modify and modrdn), and execute operations (“x”, which means bind is required). “User” permissions apply to authenticated users, while “other” apply to anonymous users; “group” permissions are ignored. For example, “ldap:///????x-mod=-rw——-” means that read and write is only allowed for authenticated connections, and bind is required for all operations. This feature is experimental, and requires to be manually enabled at configure time.
-r directory Specifies a directory to become the root directory. slapd will change the current working directory to this directory and then chroot(2) to this directory. This is done after opening listeners but before reading any configuration file or initializing any backend. When used as a security mechanism, it should be used in conjunction with -u and -g options.
-u user slapd will run slapd with the specified user name or id, and that user's supplementary group access list as set with initgroups(3). The group ID is also changed to this user's gid, unless the -g option is used to override. Note when used with -r , slapd will use the user database in the change root environment. Note that on some systems, running as a non-privileged user will prevent passwd back-ends from accessing the encrypted passwords. Note also that any shell back-ends will run as the specified non-privileged user.
-g group slapd will run with the specified group name or id. Note when used with -r, slapd will use the group database in the change root environment.
-c cookie This option provides a cookie for the syncrepl replication consumer. The cookie is a comma separated list of name=value pairs. Currently supported syncrepl cookie fields are rid and csn. rid identifies a replication thread within the consumer server and is used to find the syncrepl specification in slapd.conf(5) having the matching replication identifier in its definition. The rid must be provided in order for any other specified values to be used. csn is the commit sequence number received by a previous synchronization and represents the state of the consumer replica content which the syncrepl engine will synchronize to the current provider content.

/var/lib/ldap/*

The database directory, contains data files from ldap directory. This location is configured using the directory directive in the slapd.conf file.

loglevel

Directive in the slapd.conf file.

Level Description
-1    enable all debugging
0     no debugging
1     trace function calls
2     debug packet handling
4     heavy trace debugging
8     connection management
16    print out packets sent and received
32    search filter processing
64    configuration file processing
128   access control list processing
256   stats log connections/operations/results
512   stats log entries sent
1024  print communication with shell back-ends
2048  print entry parsing debugging

Topic 304: Usage

304.1 Searching the Directory (weight: 2)

Description: Candidates should be able to use advanced options for searching the LDAP directory

Key Knowledge Areas

  • Use OpenLDAP search tools with basic options
  • Use OpenLDAP search tools with advanced options
  • Optimize LDAP search queries
  • Knowledge of search filters and their syntax

The following is a partial list of the used files, terms and utilities:

  • ldapsearch
  • index
  • search filter syntax
  • slapd.conf

ldapsearch

Basic:

ldapsearch -L -D 'cn=foo,dc=bar,dc=com' 'objectclass=posixAccount'

Bind as cn=foo,dc=bar,dc=com, output in ldif format, return all records with where objectclass is posixAccount.

Advanced:

ldapsearch -h 10.63.3.200 -p 1389
-D "cn=James Bond,ou=people, dc=mycompany,dc=com" 
-w drymartini -b "ou=products,dc=mycompany,dc=com"
-s one -z 100 "(&(graphicsCard=*force*)(cpu=486))"
did cost price cpu graphicsCard memorySize

will bind as “cn=James Bond…” to the LDAP server in host 10.63.3.200 listening on port 1389 and then search in the level below “ou=products…” for a maximum of 100 entries whose graphicsCard attribute contains the string “force” and cpu is 486, and will retrieve the values of the did, cost, price, cpu, graphicsCard and memorySize attributes.

index

FIXME For faster search results, filter on the indexed attributes and methode combinations. For example with the following index

index   objectClass     eq

(objectClass=person) will give you a faster result then (objectClass=*per*), this is because the attribute objectClass is index on equality and not substring.

search filter syntax

Operators

  • & = and
  • | = or
  • ! = not
  • ~= = approx equal
  • >= = greater than or equal
  • ⇐ = less than or equal
  • * = any

Examples

  • (objectclass=posixAccount)

all entries with objectclass posixAccount

  • (cn=Mickey M*)

all entries where common name (cn) starts with “Mickey M”

  • (|(uid=fred)(uid=bill))

all entries with uid fred or bill

  • (&(|(uid=jack)(uid=jill))(objectclass=posixAccount))

all entries with uid jack or jill and has objectclass posixAccount

304.2 LDAP Command Line Tools (weight: 4)

Description: Candidates should be familiar with the OpenLDAP command line tools

Key Knowledge Areas

  • Use the ldap* tools to access and modify the directory
  • Use the slap* tools to access and modify the directory

The following is a partial list of the used files, terms and utilities:

  • ldap.conf
  • ldapsearch
  • ldapadd
  • ldapmodify
  • ldapdelete
  • ldapmodrdn
  • slapindex
  • slapadd
  • slapcat

ldap.conf

#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

#BASE   dc=example, dc=com
#URI    ldap://ldap.example.com ldap://ldap-master.example.com:666

#SIZELIMIT      12
#TIMELIMIT      15
#DEREF          never

ldapsearch

Ldapsearch opens a connection to an LDAP server, binds and performs a search starting at searchbase, with a defined scope of all entries that satisfy a filter. If any entries are found, a list of specified attributes are returned.

ldapsearch  [-n]  [-u]  [-v]  [-k]  [-K]  [-t]
            [-A] [-L[L[L]]] [-M[M]]  [-d debuglevel] [-f file]
            [-D binddn] [-W]  [-w passwd]  [-y passwdfile]
            [-H ldapuri]   [-h ldaphost]   [-p ldapport]
            [-P 2|3]  [-b searchbase]  [-s base|one|sub]
            [-a never|always|search|find]  [-l timelimit]
            [-z sizelimit] [-O security-properties]  [-I]
            [-Q]  [-U authcid]  [-R realm] [-x] [-X authzid]
            [-Y mech] [-Z[Z]] filter [attrs...]
  • -h ldaphost

Specifies an alternate host on which LDAP server is running

  • -p ldapport

Specifies the TCP port where LDAP server is listening

  • -D binddn

Binddn is the distinguished name used to bind to LDAP server

  • -w passwd

Use passwd as the password for simple authentication

  • -b searchbase

Set searchbase as the starting point for the search

  • -s scope (base | one | sub)

Specify to limit the search to look in the base object, one-level, or the whole subtree.

  • -f file

Reads a series of lines from file performing a search for each line. The filter given in the command line is treated as a pattern where %s is replaced with a line from file. If file is � then the lines are read from standard input.

  • -z sizelimit

Retrieve at most sizelimit entries as results from the search

  • filter

RFC 2254 search filter string representation with the condition(s) to be satisfied by the entries

  • attrs

List of attributes to be retrieved in the search, if * or omitted all attributes are returned

ldapadd

Ldapadd opens a connection to an LDAP server, binds and adds entries. The entries information is read from standard input or from a file. Ldapadd is implemented as a hard link to ldapmodify with the -a flag turned on.

ldapadd [-c] [-S file] [-n]  [-v]  [-k] [-K] [-M[M]]
        [-d debuglevel] [-D binddn]  [-W]  [-w passwd]
        [-y passwdfile]  [-h ldaphost] [-p ldap-port]
        [-P 2|3]  [-O security-properties]  [-I]  [-Q]
        [-U authcid] [-R realm] [-x] [-X authzid]
        [-Y mech] [-Z[Z]] [-f file]
  • -c

Continuous operation mode. If an error is found when an entry is being added, it is reported, but ldapadd will continue with adds.

  • -h ldaphost

Specifies and alternate host on which LDAP server is running

  • -p ldapport

Specifies the TCP port where LDAP server is listening

  • -D binddn

Binddn is the distinguished name used to bind to LDAP server

  • -w passwd

Use passwd as the password for simple authentication

  • -f file

Read the entries to add from file.

ldapmodify

Ldapmodify opens a connection to an LDAP server, binds and modifies entries with information read from a file (-f option) or from the standard input.

ldapmodify  [-a]  [-c]  [-S file] [-n] [-v] [-k]
            [-K] [-M[M]] [-d debuglevel] [-D binddn]
            [-W] [-w passwd] [-y passwdfile] [-H ldapuri]
            [-h ldaphost] [-p ldapport] [-P 2|3]
            [-O security-properties] [-I] [-Q]
            [-U authcid] [-R realm] [-x]
            [-X authzid] [-Y mech] [-Z[Z]] [-f file]
  • -c

Continuous operation mode. If an error is found when an entry is being modified, it is reported, but ldapmodify will continue.

  • -h ldaphost

Specifies an alternate host on which the LDAP server is running

  • -p ldapport

Specifies the TCP port where LDAP server is listening

  • -D binddn

Binddn is the distinguished name used to bind to the LDAP server

  • -w passwd

Use passwd as the password for simple authentication

  • -f file

Read the modification information from file.

ldapdelete

Ldapdelete opens a connection to an LDAP server, binds and deletes one or more entries. The DNs of the entries to be deleted are passed as arguments or read from a file (with -f option). Without dn arguments or -f options, ldapdelete will read them from the standard input.

ldapdelete  [-n]  [-v] [-k] [-K] [-c] [-M[M]]
            [-d debuglevel] [-f file] [-D binddn]
            [-W] [-w passwd] [-y passwdfile]
            [-H ldapuri] [-h ldaphost] [-P 2|3]
            [-p ldapport] [-O security-properties]
            [-U authcid] [-R realm] [-x] [-I] [-Q]
            [-X authzid] [-Y mech] [-Z[Z]] [dn]
  • -c

Continuous operation mode. If an error is found when an entry is being deleted, it is reported, but ldapdelete will continue reading dns. The default is to exit after reporting an error.

  • -h ldaphost

Specifies and alternate host on which LDAP server is running

  • -p ldapport

Specifies the TCP port where LDAP server is listening

  • -D binddn

Binddn is the distinguished name used to bind to LDAP server

  • -w passwd

Use passwd as the password for simple authentication

  • -f file

Read the entries to delete from file.

  • dn

Distinguished name of the entry to be deleted.

ldapmodrdn

Ldapmodrdn opens a connection to an LDAP server, binds and modifies the rdn of entries. The entry information is read from standard input, from a file (with -f option) or from the command-line pair dn rdn

ldapmodrdn  [-r]  [-n]  [-v]  [-k]  [-K]  [-c]
            [-M[M]] [-d debuglevel] [-D binddn]
            [-W] [-w passwd] [-y passwdfile]
            [-H ldapuri] [-h ldaphost] [-p ldapport]
            [-P 2|3] [-O security-properties] [-I]
            [-Q] [-U authcid] [-R realm] [-x]
            [-X authzid] [-Y mech] [-Z[Z]] [-f file]
            [dn rdn]
  • -r

Remove old RDN values from the entry. Default is to keep old values.

  • -c

Continuous operation mode. If an error is found it is reported, but ldapmodrdn will continue reading pairs dn-rdn. The default is to exit after reporting an error.

  • -h ldaphost

Specifies an alternate host on which the LDAP server is running

  • -p ldapport

Specifies the TCP port where the LDAP server is listening

  • -D binddn

Binddn is the distinguished name used to bind to the LDAP server

  • -w passwd

Use passwd as the password for simple authentication

  • -f file

Read the pairs dn - rdn from file.

  • dn rdn

Distinguished name of the entry and new rdn.

slapindex

Sometimes it may be necessary to regenerate indices (such as after modifying slapd.conf(5)). This is possible using the slapindex(8) program. slapindex is invoked like this

slapindex -f <slapdconfigfile> [-d <debuglevel>] [-n <databasenumber>|-b <suffix>]

Where the -f, -d, -n and -b options are the same as for the slapadd(1) program. slapindex rebuilds all indices based upon the current database contents.

slapadd

Slapadd is used to add entries specified in LDAP Directory Interchange Format (LDIF) to a slapd(8) database. It opens the given database determined by the database number or suffix and adds entries corresponding to the provided LDIF to the database. Databases configured as subordinate of this one are also updated, unless -g is specified. The LDIF input is read from standard input or the specified file.

As slapadd is designed to accept LDIF in database order, as produced by slapcat(8), it does not verify that superior entries exist before adding an entry, does not perform all user and system schema checks, and does not maintain operational attributes (such as createTimeStamp and modifiersName).

slapadd [-v] [-c] [-g] [-u] [-q] [-w] [-d level] [-b suffix] [-n dbnum] [-f slapd.conf] [-F confdir] [-l ldif-file]

slapcat

The slapcat program is used to dump the database to an LDIF file. This can be useful when you want to make a human-readable backup of your database or when you want to edit your database off-line. The program is invoked like this:

slapcat -l <filename> -f <slapdconfigfile> [-d <debuglevel>] [-n <databasenumber>|-b <suffix>]

where -n or -b is used to select the database in the slapd.conf(5) specified using -f. The corresponding LDIF output is written to standard output or to the file specified using the -l option.

304.3 Whitepages (weight: 1)

Description: Candidates should be able to build and maintain a whitepages service

Key Knowledge Areas

  • Plan whitepages services
  • Configure whitepages services
  • Configure clients to retrieve data from whitepages services

The following is a partial list of the used files, terms and utilities:

  • whitepages
  • Outlook

whitepages

For a whitepages service you need the following:

  • Directory structure. For example a subtree for every department.
  • The correct schema's with all the attributes for storing the information you want/need.
  • Client application, for example Mozilla Thunderbird, Microsoft Outlook.
  • A tool or scripts to create the ldif's and fill your directory.

FIXME

Outlook

The following shows the LDAP attribute mappings to Outlook Address Book entry Properties determined to date. Outlook seems to be oblivious to “objectclass” when retrieving data from an LDAP server, and simply maps LDAP attributes by name as shown. In other words, assigning an LDAP entry an “objectclass” of ResidentialPerson does *not* cause the address information to switch from the [Business] tab to the [Home] tab.

Refer to FAQ entry “MS Outlook (1): What LDAP Attributes are Recognised?” for a full list of LDAP attributes that seem to be recognised by Outlook. Not all apparently-recognised LDAP attributes are shown below. This indicates a mapping has not yet been determined. Please feel free to share what you discover.

The mappings described are based on experimenting with Outlook Express 5, and mainly by inferencing from LDAP lookups. LDIF importing has not been evaluated. Unless otherwise noted, only a single value is retrieved even if multiple values exist in the LDAP entry.

Outlook Properties Tab
. Outlook Field - LDAP Attribute(s) (1)
-----------------------------------
Summary
. Name - cn, display-name
. E-Mail Address - mail (2)
. Home Phone - homePhone
. Pager - officePager, pager (3)
. Mobile - mobile
. Personal Web Page
. Business Phone - telephoneNumber
. Business FAX - officeFAX, facsimileTelephoneNumber
. Job Title - title
. Department - department, organizationUnitName, ou (3)
. Office - physicalDeliveryOfficeName
. Company Name - o, organizationName
. Business Web Page - URL
Name
. First - givenName
. Middle - initials
. Last - sn
. Title
. Display - cn, display-name
. Nickname
. E-Mail Address - mail (2)
. Send E-Mail using plain text only
Home
. Street Address - homePostalAddress (4)
. City
. State/Province
. Zip Code
. Country/Region:
. Default
. Web Page
. Phone - homePhone
. Fax - otherFacsimileTelephoneNumber 
. Mobile - mobile
Business
. Company Name -  o, organizationName (3)
. Street Address - postalAddress, street, streetAddress (4)
. City - l
. State/Province - st
. Zip Code - postalCode
. Country/Region - c, co, countryName (3)
. Default
. Web Page - URL
. Job Title - title
. Department - department, organizationalUnitName, ou (3)
. Office - physicalDeliveryOfficeName
. Phone - telephoneNumber
. Fax - officeFAX, facsimileTelephoneNumber
. Pager - officePager, pager (3)
. IP Phone
Personal
. Spouse
. Children
. Gender
. Birthday
. Anniversary
Other
. Notes - comment, info (3)
. Group Membership
Conferencing
. Conferencing Server - conferenceInformation
. Conferencing Address
Digital IDs
. E-Mail Address - mail
. Digital IDs... - userCertificate;binary (7)
Organisation (8)
. Manager - Manager (5)
. Reports - Reports (5,6)
General (8)
. (white space) - labeledURI (9)

Notes
-----
(1) Where more than one attribute name is given, sometimes the first one
    encountered is used, and sometimes one name takes preference over others.
(2) Only the first listed email address is retrieved.
(3) Retrieves from the first-listed attribute that has a value in the order
    shown.
(4) Replaces embedded "$"s with line separators, displaying as separate lines
    in scrollable region.
(5) DN format, and double-clickable to go to corresponding entry.
(6) Multiple values allowed.
(7) DER encoded X.509.
(8) Tab only appears if an underlying attribute exists!
(9) When specified, URI is retrieved and displayed in the white space on this
    tab.

More information

Topic 305: Integration and Migration

305.1 LDAP Integration with PAM and NSS (weight: 2)

Description: Candidates should be able to confiure PAM and NSS to retrieve information from an LDAP directory

Key Knowledge Areas

  • Configure PAM to use LDAP for authentication
  • Configure NSS to retrieve information from LDAP
  • Configure PAM modules in various Unix environments

The following is a partial list of the used files, terms and utilities:

  • PAM
  • NSS
  • /etc/pam.d/*
  • /etc/nsswitch.conf

PAM

PAM is Pluggable Authentication Modules. While NSS is an information service, PAM is a mechanism to run a set of authentication algorithms on credentials entered by the user, and determine their identity and access right to a resource (e.g., logging into a machine).

The Pluggable Authentication Module allows integration of various authentication technologies such as standard UNIX, RSA, DCE, LDAP etc. into system services such as login, passwd, rlogin, su, ftp, ssh etc. without changing any of these services.

First implemented by Sun Solaris, PAM is now the standard authentication framework of many Linux distributions, including RedHat and Debian. It provides an API through which authentication requests are mapped into technology specific actions (implemented in the so called pam modules). This mapping is done by PAM configuration files, in which, for each service are basically given the authentication mechanisms to use.

In our case, the pam_ldap module, implemented in the shared library pam_ldap.so, allows user and group authentication using an LDAP service.

Each service that needs an authentication facility, can be configured through the PAM configuration files to use different authentication methods. This means that it is possible, using the PAM configuration files, to write a custom list of requirements that an user must satisfy to obtain access to a resource.

NSS

NSS is the name service switch. It bridges queries for things like password file entries and group entries to a naming service (like flat files, or an LDAP directory, or even a Windows domain controller.

Once an user is authenticated, many applications still need access to user information. This information is traditionally contained in text files (/etc/passwd, /etc/shadow, and /etc/group) but can also be provided by other name services.

NSS uses a common API and a configuration file (/etc/nsswitch.conf) in which the name service providers for every supported database are specified.

The databases currently supported by NSS [2] are:

    * aliases: Mail aliases.
    * ethers: Ethernet numbers.
    * group: Groups of users.
    * hosts: Host names and numbers.
    * netgroup: Network wide list of host and users.
    * network: Network names and numbers.
    * protocols: Network protocols.
    * passwd: User passwords.
    * rpc: Remote procedure call names and numbers.
    * services: Network services.
    * shadow: Shadow user passwords.

Using the nss_ldap shared library it is possible to implement the maps above using LDAP, anyway here I'll focus only on the LDAP implementation of shadow, passwd and group database tough all the maps above can be implemented. For most of the other maps it is even unadvisable to store them in ldap, as they tend not to change too often, so it is not a problem to have them locally as files, and storing them in ldap would cause some minor performance loss.

/etc/pam.d/*

For example this is the PAM configuration file for the login service (in a file named login).

#%PAM-1.0
auth     required   /lib/security/pam_securetty.so
auth     required   /lib/security/pam_nologin.so
auth     sufficient /lib/security/pam_ldap.so
auth     required   /lib/security/pam_unix_auth.so use_first_pass
account  sufficient /lib/security/pam_ldap.so
account  required   /lib/security/pam_unix_acct.so
password required   /lib/security/pam_cracklib.so
password sufficient /lib/security/pam_ldap.so
password required   /lib/security/pam_unix_passwd.so use_first_pass md5 shadow
session  required   /lib/security/pam_unix_session.so

Another example, system-auth (used by RedHat for login)

#%PAM-1.0
auth     required   /lib/security/pam_securetty.so
auth     required   /lib/security/pam_nologin.so
auth     sufficient /lib/security/pam_ldap.so
auth     required   /lib/security/pam_unix_auth.so use_first_pass
account  sufficient /lib/security/pam_ldap.so
account  required   /lib/security/pam_unix_acct.so
password required   /lib/security/pam_cracklib.so
password sufficient /lib/security/pam_ldap.so
password required   /lib/security/pam_unix_passwd.so use_first_pass md5 shadow
session  required   /lib/security/pam_unix_session.so

Ldap server (ip/dns) and base are configured in /etc/ldap.conf

/etc/nsswitch.conf

passwd: files ldap
group:  files ldap
shadow: files ldap

305.2 NIS to LDAP Migration (weight: 1)

Description: Candidates should be able to plan and implement a NIS migration strategy, including a NIS to LDAP gateway

Key Knowledge Areas

  • Analyze NIS structure prior to migration to LDAP
  • Analyze NIS structure prior to integration with LDAP
  • Automate NIS to LDAP migration
  • Create a NIS to LDAP gateway

The following is a partial list of the used files, terms and utilities:

  • NIS
  • NIS to LDAP gateway
  • slapd.conf
  • /etc/yp/*

NIS

The Network Information Service or NIS (originally called Yellow Pages or YP) is Sun Microsystems’ client-server directory service protocol for distributing system configuration data such as user and host names between computers on a computer network.

Analyze NIS structure prior to migration to LDAP

Determine which of your NIS maps you will migrate to your directory. ypwhich -m gives a list of maps and their master server. The maps are typically in /var/yp/<domainname>. On your client systems, the file /etc/nsswitch.conf determines which NIS files the client is using.

Analyze NIS structure prior to integration with LDAP

Your directory architect needs to decide where in your directory to place your NIS information. Here are some possibilities:

  • Create a separate subtree for NIS data - The migration scripts can import all your NIS data into the separate subtree.
  • Integrate the NIS information into your directory - The migration scripts may be helpful depending on where you put the NIS data in your directory. You could use them just to generate LDIF, edit the LDIF, then import the LDIF into your directory.

Automate NIS to LDAP migration

The scripts require Perl, which is assumed to be in /usr/bin/perl. You may need to edit the path to the Perl interpreter if this is not the case. The migration tools are available separately from PADL’s FTP site. At the time of writing, the following scripts are provided:

  • migrate_base.pl creates naming context entries, including subordinate contexts such as ou=People and ou=Hosts.
  • migrate_aliases.pl migrates aliases in /etc/aliases to entries conforming to the rfc822MailGroup schema. Organizations who have deployed LDAP-based messaging solutions, such as Netscape’s Messaging Server, may wish to use a different schema for representing mail aliases. Ypldapd does not use X.500 groups (such as groupOfUniqueNames) for mail alias expansion because flattening an arbitrarily nested group at runtime may be expensive. (It is possible to write a ypldapd plug-in to support such a schema, however.)
  • migrate_automount.pl migrates automount maps
  • migrate_group.pl migrates groups in /etc/group
  • migrate_hosts.pl migrates hosts in /etc/hosts
  • migrate_networks.pl migrates networks in /etc/networks
  • migrate_passwd.pl migrates users in /etc/passwd. Note that if users are allowed read the userPassword attribute, and your LDAP server doesn’t support authenticating against hashed passwords then anyone may read the userPassword attribute’s value and authenticate as that user. Modern LDAP servers, such as Netscape Directory Server, support authenticating against hashed passwords, so this is not an issue. The OpenLDAP slapd (http://www.openldap.org) also supports authenticating against hashed passwords.
  • migrate_protocols.pl migrates protocols in /etc/protocols
  • migrate_services.pl migrates services in /etc/services
  • migrate_netgroup.pl migrates netgroups in /etc/netgroup
  • migrate_netgroup_byuser.pl migrates the netgroup.byuser map
  • migrate_netgroup_byhost.pl migrates the netgroup.byhost map
  • migrate_profile.pl creates a POSIX DUA configuration profile entry; this is not supported by ypldapd but may be by other implementations of RFC 2307
  • migrate_rpc.pl migrates RPCs in /etc/rpc
  • migrate_slapd_conf.pl creates a skeletal OpenLDAP 2.x configuration file

The configuration for these Perl scripts is contained at the head of migrate_common.ph

$ migrate_hosts.pl /etc/hosts
dn: cn=mira.aceindustry.com,ou=Hosts,dc=aceindustry,dc=com
objectclass: ipHost
objectclass: device
objectclass: top
ipHostNumber: 10.1.70.5
cn: mira
cn: www.aceindustry.com
cn: mira.aceindustry.com

$ migrate_passwd.pl /etc/passwd
dn: cn=Joe Bloggs,ou=People,dc=aceindustry,dc=com
cn: Joe Bloggs
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: account
mail: jbloggs@aceindustry.com
givenname: Joe
sn: Bloggs
uid: jbloggs
userPassword: {crypt}daCXgaxahRNkg
loginShell: /bin/csh
uidNumber: 20
gidNumber: 20
homeDirectory: /home/jbloggs

NIS to LDAP gateway

The NIS/LDAP Gateway, or ypldapd, is a Network Information Service (NIS) server which uses LDAP as its information source. It permits existing NIS clients to transparently use LDAP to resolve user, group and host information. Enterprises can thus realize the benefits of LDAP, such as its distribution and being scalable, without upgrading clients.

slapd.conf

Install the posix schema (RFC 2307) into your directory.

include         /etc/openldap/schema/nis.schema
## Give the ypldapproxy user read access to all information. 
access to dn=".*,dc=plainjoe,dc=org" 
     by dn="uid=ypldapproxy,ou=people,dc=plainjoe,dc=org" read

/etc/yp/*

FIXME
ypldapd.conf

## NIS domain to serve
ypdomain yp.plainjoe.org
      
## LDAP server
ldaphost 192.168.1.77
      
## Search base
basedn dc=plainjoe,dc=org
      
## Enable caching.
caching on
      
## Dump caches every half hour.
cache_dump_interval 30
      
## Use the default naming context mappings.
namingcontexts namingcontexts.conf
## Define a DN used for binding to the LDAP server.
binddn uid=ypldapproxy,ou=people,dc=plainjoe,dc=org
      
## Include the clear-text password for the binddn.
bindcred secret

## Hide the password field from nonprivileged users.
hide_passwords on

305.3 Integrating LDAP with Unix Services (weight: 1)

Description: Candidates should be able to integrate LDAP authentication with a number of common Unix services

Key Knowledge Areas

  • Integrate SSH with LDAP
  • Integrate FTP with LDAP
  • Integrate HTTP with LDAP
  • Inegrate FreeRADIUS ? with LDAP
  • Integrate print services with LDAP

The following is a partial list of the used files, terms and utilities:

  • sshd.conf
  • ftp
  • httpd.conf
  • radiusd.conf
  • cupsd.conf
  • ldap.conf

sshd.conf

Allow all users access who are member of the group “cn=ssh,ou=services,ou=auth,dc=example,dc=com”

$/etc/pam.d/ssh
<snip>
auth            sufficient      /usr/local/lib/pam_ldap.so config=/usr/local/etc/openldap/ldap-ssh.conf
</snip>

$/usr/local/etc/openldap/ldap-ssh.conf
pam_groupdn cn=ssh,ou=services,ou=auth,dc=example,dc=com
pam_member_attribute member 

ftp

Implementation depends on the server software. Most ftp server can be configured to use pam and using pam (as above) you can authenticate using ldap. FIXME

httpd.conf

Subset of the httpd.conf file

<Directory /path/to/protected/dir>
   AllowOverride AuthConfig
   order allow,deny
   allow from all
   AuthName "Protected site"
   AuthType Basic
   AuthLDAPEnabled on
   AuthLDAPURL ldap://127.0.0.1/ou=users,dc=example,dc=com?uid?one
   AuthLDAPAuthoritative on
</Directory>

radiusd.conf

Subset of the radiusd.conf file

modules {
        #
        #  Each module has a configuration as follows:
        #
        #       name [ instance ] {
        #               config_item = value
        #               ...
        #       }
        #
        #  The 'name' is used to load the 'rlm_name' library
        #  which implements the functionality of the module.
        #
        #  The 'instance' is optional.  To have two different instances
        #  of a module, it first must be referred to by 'name'.
        #  The different copies of the module are then created by
        #  inventing two 'instance' names, e.g. 'instance1' and 'instance2'
        #
        #  The instance names can then be used in later configuration
        #  INSTEAD of the original 'name'.  See the 'radutmp' configuration
        #  below for an example.
        #

        # Lightweight Directory Access Protocol (LDAP)
        #
        #  This module definition allows you to use LDAP for
        #  authorization and authentication.
        #
        #  See doc/rlm_ldap for description of configuration options
        #  and sample authorize{} and authenticate{} blocks
        #
        #  However, LDAP can be used for authentication ONLY when the
        #  Access-Request packet contains a clear-text User-Password
        #  attribute.  LDAP authentication will NOT work for any other
        #  authentication method.
        #
        #  This means that LDAP servers don't understand EAP.  If you
        #  force "Auth-Type = LDAP", and then send the server a
        #  request containing EAP authentication, then authentication
        #  WILL NOT WORK.
        #
        #  The solution is to use the default configuration, which does
        #  work.
        #
        #  Setting "Auth-Type = LDAP" is ALMOST ALWAYS WRONG.  We
        #  really can't emphasize this enough.
        #
        ldap {
                server = "localhost"
                # identity = "cn=admin,o=My Org,c=UA"
                # password = mypass
                basedn = "dc=example,dc=com"
                filter = "(uid=%{Stripped-User-Name:-%{User-Name}})"
                # base_filter = "(objectclass=radiusprofile)"

                # set this to 'yes' to use TLS encrypted connections
                # to the LDAP database by using the StartTLS extended
                # operation.
                # The StartTLS operation is supposed to be used with normal
                # ldap connections instead of using ldaps (port 689) connections
                start_tls = no

                # tls_cacertfile        = /path/to/cacert.pem
                # tls_cacertdir         = /path/to/ca/dir/
                # tls_certfile          = /path/to/radius.crt
                # tls_keyfile           = /path/to/radius.key
                # tls_randfile          = /path/to/rnd
                # tls_require_cert      = "demand"

                # default_profile = "cn=radprofile,ou=dialup,o=My Org,c=UA"
                # profile_attribute = "radiusProfileDn"
                # access_attr = "dialupAccess"
                # Mapping of RADIUS dictionary attributes to LDAP
                # directory attributes.
                # dictionary_mapping = ${raddbdir}/ldap.attrmap

                ldap_connections_number = 5

                password_header = "{ssha}"
                password_attribute = userPassword
                #
                # Un-comment the following to disable Novell eDirectory account
                # policy check and intruder detection. This will work *only if*
                # FreeRADIUS is configured to build with --with-edir option.
                #
                # edir_account_policy_check=no
                #
                # groupname_attribute = cn
                # groupmembership_filter = "(|(&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)
(uniquemember=%{Ldap-User Dn})))"
                # groupmembership_attribute = radiusGroupName
                timeout = 4
                timelimit = 3
                net_timeout = 1
                # compare_check_items = yes
                # do_xlat = yes
                # access_attr_used_for_allow = yes

                #
                #  By default, if the packet contains a User-Password,
                #  and no other module is configured to handle the
                #  authentication, the LDAP module sets itself to do
                #  LDAP bind for authentication.
                #
                #  You can disable this behavior by setting the following
                #  configuration entry to "no".
                #
                #  allowed values: {no, yes}
                # set_auth_type = yes
        }
}
#  Authorization. First preprocess (hints and huntgroups files),
#  then realms, and finally look in the "users" file.
#
#  The order of the realm modules will determine the order that
#  we try to find a matching realm.
#
#  Make *sure* that 'preprocess' comes before any realm if you
#  need to setup hints for the remote radius server
authorize {
        #
        #  The preprocess module takes care of sanitizing some bizarre
        #  attributes in the request, and turning them into attributes
        #  which are more standard.
        #
        #  It takes care of processing the 'raddb/hints' and the
        #  'raddb/huntgroups' files.
        #
        #  It also adds the %{Client-IP-Address} attribute to the request.
        preprocess
        #
        #  The ldap module will set Auth-Type to LDAP if it has not
        #  already been set
        ldap
}

#  Authentication.
#
#
#  This section lists which modules are available for authentication.
#  Note that it does NOT mean 'try each module in order'.  It means
#  that a module from the 'authorize' section adds a configuration
#  attribute 'Auth-Type := FOO'.  That authentication type is then
#  used to pick the apropriate module from the list below.
#

#  In general, you SHOULD NOT set the Auth-Type attribute.  The server
#  will figure it out on its own, and will do the right thing.  The
#  most common side effect of erroneously setting the Auth-Type
#  attribute is that one authentication method will work, but the
#  others will not.
#
#  The common reasons to set the Auth-Type attribute by hand
#  is to either forcibly reject the user, or forcibly accept him.
#
authenticate {
        # Uncomment it if you want to use ldap for authentication
        #
        # Note that this means "check plain-text password against
        # the ldap database", which means that EAP won't work,
        # as it does not supply a plain-text password.
        Auth-Type LDAP {
                ldap
        }
}

cupsd.conf

Configure CUPS to use pam_ldap

The last piece to get CUPS using VT PID/PW authentication is to instruct PAM to auth CUPS through pam_ldap. PAM keeps a file for each process that may use authentication in /etc/pam.d: /etc/pam.d/cups should already exist if you have cups installed. The file will likely contain these original lines:

auth required pam_stack.so service=system-auth

account required pam_stack.so service=system-auth

To use LDAP instead, we’ll simply link to pam_ldap.so. These lines than become:

auth required pam_ldap.so
account required pam_ldap.so

The ONLY accounts that will be able to access the printer are valid VT PIDs with correct passwords. If you would like to permit local UNIX accounts as well, precede those lines with the originals, replacing “required” with “sufficient” as so:

auth sufficient pam_stack.so service=system-auth
auth required pam_ldap.so
account sufficient pam_stack.so service=system-auth
account required pam_ldap.so

No service need to be restarted after this change. And we’re done.

ldap.conf

# @(#)$Id: ldap.conf,v 1.38 2006/05/15 08:13:31 lukeh Exp $
#
# This is the configuration file for the LDAP nameservice
# switch library and the LDAP PAM module.
#
# The man pages for this file are nss_ldap(5) and pam_ldap(5)
#
# PADL Software
# http://www.padl.com
#

# Your LDAP server. Must be resolvable without using LDAP.
# Multiple hosts may be specified, each separated by a
# space. How long nss_ldap takes to failover depends on
# whether your LDAP client library supports configurable
# network or connect timeouts (see bind_timelimit).
#host 127.0.0.1

# The distinguished name of the search base.
base dc=example,dc=com

# Another way to specify your LDAP server is to provide an
# uri with the server name. This allows to use
# Unix Domain Sockets to connect to a local LDAP Server.
#uri ldap://127.0.0.1/
#uri ldaps://127.0.0.1/
#uri ldapi://%2fvar%2frun%2fldapi_sock/
# Note: %2f encodes the '/' used as directory separator

# The LDAP version to use (defaults to 3
# if supported by client library)
#ldap_version 3

# The distinguished name to bind to the server with.
# Optional: default is to bind anonymously.
#binddn cn=proxyuser,dc=example,dc=com

# The credentials to bind with.
# Optional: default is no credential.
#bindpw secret

# The distinguished name to bind to the server with
# if the effective user ID is root. Password is
# stored in /etc/ldap.secret (mode 600)
#rootbinddn cn=manager,dc=example,dc=com

# The port.
# Optional: default is 389.
#port 389
# The search scope.
#scope sub
#scope one
#scope base

# Search timelimit
#timelimit 30
timelimit 120

# Bind/connect timelimit
#bind_timelimit 30
bind_timelimit 120

# Reconnect policy: hard (default) will retry connecting to
# the software with exponential backoff, soft will fail
# immediately.
#bind_policy hard

# Idle timelimit; client will close connections
# (nss_ldap only) if the server has not been contacted
# for the number of seconds specified below.
#idle_timelimit 3600
idle_timelimit 3600

# Filter to AND with uid=%s
#pam_filter objectclass=account

# The user ID attribute (defaults to uid)
#pam_login_attribute uid

# Search the root DSE for the password policy (works
# with Netscape Directory Server)
#pam_lookup_policy yes

# Check the 'host' attribute for access control
# Default is no; if set to yes, and user has no
# value for the host attribute, and pam_ldap is
# configured for account management (authorization)
# then the user will not be allowed to login.
#pam_check_host_attr yes

# Check the 'authorizedService' attribute for access
# control
# Default is no; if set to yes, and the user has no
# value for the authorizedService attribute, and
# pam_ldap is configured for account management
# (authorization) then the user will not be allowed
# to login.
#pam_check_service_attr yes

# Group to enforce membership of
#pam_groupdn cn=PAM,ou=Groups,dc=example,dc=com

# Group member attribute
#pam_member_attribute uniquemember

# Specify a minium or maximum UID number allowed
#pam_min_uid 0
#pam_max_uid 0

# Template login attribute, default template user
# (can be overriden by value of former attribute
# in user's entry)
#pam_login_attribute userPrincipalName
#pam_template_login_attribute uid
#pam_template_login nobody

# HEADS UP: the pam_crypt, pam_nds_passwd,
# and pam_ad_passwd options are no
# longer supported.
#
# Do not hash the password at all; presume
# the directory server will do it, if
# necessary. This is the default.
#pam_password clear

# Hash password locally; required for University of
# Michigan LDAP server, and works with Netscape
# Directory Server if you're using the UNIX-Crypt
# hash mechanism and not using the NT Synchronization
# service.
#pam_password crypt

# Remove old password first, then update in
# cleartext. Necessary for use with Novell
# Directory Services (NDS)
#pam_password clear_remove_old
#pam_password nds

# RACF is an alias for the above. For use with
# IBM RACF
#pam_password racf

# Update Active Directory password, by
# creating Unicode password and updating
# unicodePwd attribute.
#pam_password ad

# Use the OpenLDAP password change
# extended operation to update the password.
#pam_password exop


# Redirect users to a URL or somesuch on password
# changes.
#pam_password_prohibit_message Please visit http://internal to change your password.

# RFC2307bis naming contexts
# Syntax:
# nss_base_XXX          base?scope?filter
# where scope is {base,one,sub}
# and filter is a filter to be &'d with the
# default filter.
# You can omit the suffix eg:
# nss_base_passwd       ou=People,
# to append the default base DN but this
# may incur a small performance impact.
#nss_base_passwd        ou=People,dc=example,dc=com?one
#nss_base_shadow        ou=People,dc=example,dc=com?one
#nss_base_group         ou=Group,dc=example,dc=com?one
#nss_base_hosts         ou=Hosts,dc=example,dc=com?one
#nss_base_services      ou=Services,dc=example,dc=com?one
#nss_base_networks      ou=Networks,dc=example,dc=com?one
#nss_base_protocols     ou=Protocols,dc=example,dc=com?one
#nss_base_rpc           ou=Rpc,dc=example,dc=com?one
#nss_base_ethers        ou=Ethers,dc=example,dc=com?one
#nss_base_netmasks      ou=Networks,dc=example,dc=com?ne
#nss_base_bootparams    ou=Ethers,dc=example,dc=com?one
#nss_base_aliases       ou=Aliases,dc=example,dc=com?one
#nss_base_netgroup      ou=Netgroup,dc=example,dc=com?one

# Just assume that there are no supplemental groups for these named users
nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon

# attribute/objectclass mapping
# Syntax:
#nss_map_attribute      rfc2307attribute        mapped_attribute
#nss_map_objectclass    rfc2307objectclass      mapped_objectclass

# configure --enable-nds is no longer supported.
# NDS mappings
#nss_map_attribute uniqueMember member

# Services for UNIX 3.5 mappings
#nss_map_objectclass posixAccount User
#nss_map_objectclass shadowAccount User
#nss_map_attribute uid msSFU30Name
#nss_map_attribute uniqueMember msSFU30PosixMember
#nss_map_attribute userPassword msSFU30Password
#nss_map_attribute homeDirectory msSFU30HomeDirectory
#nss_map_attribute homeDirectory msSFUHomeDirectory
#nss_map_objectclass posixGroup Group
#pam_login_attribute msSFU30Name
#pam_filter objectclass=User
#pam_password ad

# configure --enable-mssfu-schema is no longer supported.
# Services for UNIX 2.0 mappings
#nss_map_objectclass posixAccount User
#nss_map_objectclass shadowAccount user
#nss_map_attribute uid msSFUName
#nss_map_attribute uniqueMember posixMember
#nss_map_attribute userPassword msSFUPassword
#nss_map_attribute homeDirectory msSFUHomeDirectory
#nss_map_attribute shadowLastChange pwdLastSet
#nss_map_objectclass posixGroup Group
#nss_map_attribute cn msSFUName
#pam_login_attribute msSFUName
#pam_filter objectclass=User
#pam_password ad

# RFC 2307 (AD) mappings
#nss_map_objectclass posixAccount user
#nss_map_objectclass shadowAccount user
#nss_map_attribute uid sAMAccountName
#nss_map_attribute homeDirectory unixHomeDirectory
#nss_map_attribute shadowLastChange pwdLastSet
#nss_map_objectclass posixGroup group
#nss_map_attribute uniqueMember member
#pam_login_attribute sAMAccountName
#pam_filter objectclass=User
#pam_password ad

# configure --enable-authpassword is no longer supported
# AuthPassword mappings
#nss_map_attribute userPassword authPassword

# AIX SecureWay mappings
#nss_map_objectclass posixAccount aixAccount
#nss_base_passwd ou=aixaccount,?one
#nss_map_attribute uid userName
#nss_map_attribute gidNumber gid
#nss_map_attribute uidNumber uid
#nss_map_attribute userPassword passwordChar
#nss_map_objectclass posixGroup aixAccessGroup
#nss_base_group ou=aixgroup,?one
#nss_map_attribute cn groupName
#nss_map_attribute uniqueMember member
#pam_login_attribute userName
#pam_filter objectclass=aixAccount
#pam_password clear

# Netscape SDK LDAPS
#ssl on

# Netscape SDK SSL options
#sslpath /etc/ssl/certs

# OpenLDAP SSL mechanism
# start_tls mechanism uses the normal LDAP port, LDAPS typically 636
#ssl start_tls
#ssl on

# OpenLDAP SSL options
# Require and verify server certificate (yes/no)
# Default is to use libldap's default behavior, which can be configured in
# /etc/openldap/ldap.conf using the TLS_REQCERT setting.  The default for
# OpenLDAP 2.0 and earlier is "no", for 2.1 and later is "yes".
#tls_checkpeer yes

# CA certificates for server certificate verification
# At least one of these are required if tls_checkpeer is "yes"
#tls_cacertfile /etc/ssl/ca.cert
#tls_cacertdir /etc/ssl/certs

# Seed the PRNG if /dev/urandom is not provided
#tls_randfile /var/run/egd-pool

# SSL cipher suite
# See man ciphers for syntax
#tls_ciphers TLSv1

# Client certificate and key
# Use these, if your server requires client authentication.
#tls_cert
#tls_key

# Disable SASL security layers. This is needed for AD.
#sasl_secprops maxssf=0

# Override the default Kerberos ticket cache location.
#krb5_ccname FILE:/etc/.ldapcache

# SASL mechanism for PAM authentication - use is experimental
# at present and does not support password policy control
#pam_sasl_mech DIGEST-MD5

305.4 Integrating LDAP with Samba (weight: 1)

Description: Candidates should be able to integrate LDAP with Samba services

Key Knowledge Areas

  • Migrate from smbpasswd to LDAP
  • Understand OpenLDAP Samba schema
  • Understand LDAP as a Samba password backend

The following is a partial list of the used files, terms and utilities:

  • smb.conf
  • smbpasswd
  • samba3.schema
  • slapd.conf

smb.conf

Just specify

    * passdb backend = ldapsam:ldap://<your-hostname>
    * ldap suffix = 

and optionally

    * ldap admin dn 
    * ldap group suffix = ou=Groups
    * ldap user suffix = ou=Users
    * ldap machine suffix = ou=Computers
    * ldap ssl = start_tls

then run smbpasswd -w <ldap-secret> to let samba know the password for the admin dn

smbpasswd

Please, use samba/examples/LDAP/*passwd* utilities.

The easiest way to set up your directory and add the default base entries can be done using the smbldap-populate script 12:

[root@etoile root]# smbldap-populate 
Populating LDAP directory for domain IDEALX-NT (S-1-5-21-4205727931-4131263253-1851132061)
(using builtin directory structure)

adding new entry: dc=idealx,dc=org
adding new entry: ou=Users,dc=idealx,dc=org
adding new entry: ou=Groups,dc=idealx,dc=org
adding new entry: ou=Computers,dc=idealx,dc=org
adding new entry: uid=root,ou=Users,dc=idealx,dc=org
adding new entry: uid=nobody,ou=Users,dc=idealx,dc=org
adding new entry: cn=Domain Admins,ou=Groups,dc=idealx,dc=org
adding new entry: cn=Domain Users,ou=Groups,dc=idealx,dc=org
adding new entry: cn=Domain Guests,ou=Groups,dc=idealx,dc=org
adding new entry: cn=Domain Computers,ou=Groups,dc=idealx,dc=org
adding new entry: cn=Administrators,ou=Groups,dc=idealx,dc=org
adding new entry: cn=Account Operators,ou=Groups,dc=idealx,dc=org
adding new entry: cn=Print Operators,ou=Groups,dc=idealx,dc=org
adding new entry: cn=Backup Operators,ou=Groups,dc=idealx,dc=org
adding new entry: cn=Replicators,ou=Groups,dc=idealx,dc=org
adding new entry: sambaDomainName=IDEALX-NT,dc=idealx,dc=org

Please provide a password for the domain root: 
Changing password for root
New password : 
Retype new password : 

We suppose that you use the shadow password. We'll then also use the shadow file to migrate password's account. Users migration should be done as follow :

  • copy /etc/passwd and /etc/shadow in a temporary directory
  • remove all accounts on both file that you not want to be in the directory

don't forget to remove the user nobody as it is created when initializing the directory with smbldap-populate.

  • migrate accounts :
/usr/share/doc/smbldap-tools-*/smbldap-migrate-unix-accounts -a -P /tmp/passwd -S /tmp/shadow
  • remove migrated users from /etc/passwd and /etc/shadow

Note : with the -a option on smbldap-migrate-unix-accounts, the sambaSAMAccount will be added to users. All users having previously a shell defined in /etc/passwd will then be able to connect to the server and update their “windows” password using /opt/IDEALX/sbin/smbldap-passwd script.

We'll now migrate all groups defined in /etc/group file. Migration process should be done as follow :

  • copy /etc/group in a temporary directory
  • remove all groups that you not want to be in the directory
  • migrate groups :
/usr/share/doc/smbldap-tools-*/smbldap-migrate-unix-groups -a -G /tmp/group
  • remove migrated groups from /etc/group

Note : with the -a option on smbldap-migrate-unix-groups, the sambaGroupMapping will be added to groups so that they can be used as “windows” groups (samba will than mapped unix groups to windows groups). You should remove this option if you don't want this.

samba3.schema

slapd.conf

Create/update the slapd.conf file. The order in the icluded schemas are sensitive:

------ snip ------

# This file should NOT be world readable.
#
include /usr/local/etc2/openldap_2/etc/openldap/schema/core.schema
include /usr/local/etc2/openldap_2/etc/openldap/schema/cosine.schema
# to support the RFC2307 (NIS) schema
include /usr/local/etc2/openldap_2/etc/openldap/schema/nis.schema
include /usr/local/etc2/openldap_2/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc2/openldap_2/etc/openldap/schema/samba.schema
 

# Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral       ldap://root.openldap.org
#referral       ldap://arcos.cti.unav.es

pidfile         /usr/local/etc2/openldap_2/var/slapd.pid
argsfile        /usr/local/etc2/openldap_2/var/slapd.args

#The <hash> to use for userPassword generation.  One
#of   {SSHA},   {SHA},   {SMD5},   {MD5},   {CRYPT},
#KERBEROS}, {SASL}, and  {UNIX}.   The  default  is {SSHA}.
password-hash   {CRYPT}

#Server and CA Certificates
TLSCertificateFile      /usr/local/etc2/ssl/arcos-cert.pem
TLSCertificateKeyFile   /usr/local/etc2/ssl/arcos-key.pem
TLSCACertificateFile    /usr/local/etc2/ssl/CAcerts
#TLSCipherSuite         EXPORT56
 

#######################################################################
# ldbm database definitions
#######################################################################
#
#
#######################################################################
#  UNAV SMB
#######################################################################
#
database        ldbm
suffix          "o=smb,dc=unav,dc=es"
rootdn          "cn=root,o=smb,dc=unav,dc=es"
rootpw          <a_very_secret_word>
directory       /usr/local/etc2/openldap_2/unav-smb-2
#
# dbcachesize is required only if you use ldbm (DB  Berkeley 3.x)
cachesize       40000
dbcachesize     60000000
#
#
index           cn,sn,uid,displayName           pres,sub,eq
index           uidNumber,gidNumber             eq
index           sambaSID                        eq
index           sambaPrimaryGroupSID            eq
index           sambaDomainName                 eq
index           objectClass                     pres,eq
#               old 2.x samba attrs
index           rid,primaryGroupID              eq
#
index           default                         sub

## posixGroup entries in the directory as well
#  index memberUid     eq
 

#
access  to dn=".*dc=unav,dc=es"
        by self                         write
        by *                            read
----

305.5 Integrating LDAP with Active Directory (weight: 2)

Description: Candidates should be able to integrate LDAP with Active Directory Services

Key Knowledge Areas

  • Kerberos integration with LDAP
  • Cross platform authentication
  • Single sign-on concepts
  • Integration and compatibility limitations between OpenLDAP and Active Directory

The following is a partial list of the used files, terms and utilities:

  • Kerberos
  • Active Directory
  • single sign-on
  • DNS

Kerberos

Once you have Kerberos setup, you can configure your LDAP servers. The first thing to do is to create a user and group dedicated to the LDAP server if your OS doesn't already come with one (Red Hat does if you've installed the openldap-servers RPM). I recommend calling both ldap.

The next thing you'll need is an SSL certificate for each of your LDAP servers. You could purchase these, but making your own is easy and doesn't cause any extra headaches like making your own Web SSL certificates does. When creating the cert, you should use the official hostname (as reported by a reverse DNS lookup) in the CN field. You can add other names to the certificate by adding them to the subjectAltName field in the usr_cert section of openssl.cnf. (The OpenLDAP tools require that the hostname you specify when running them match either the CN or subjectAltName fields of the SSL cert supplied by the server.) The format is like this:

subjectAltName=DNS:ldap2.example.com,DNS:ldap.example.com

Once you've got the cert, you'll need to make sure that the key portion of it (some certs have both the key and the cert in one file, others have them seperated) is readable by the server that the ldap user will run as, but preferably not owned or writeable by that user, nor readable by anyone else. Something like chown root:ldap key.pem; chmod 640 key.pem should do the trick.

Next up you need to create a Kerberos service principal for the LDAP server and extract it to a keytab file (but not the system keytab in /etc/krb5.keytab because then you'd have to give the LDAP server permission to read that file which you don't want to do). The permissions on this keytab file should be the same as on the SSL key. Be careful with the hostname here, it needs to match what you get for a reverse lookup of the server's IP address. If you have the short (i.e. not fully qualified) hostname listed first in /etc/hosts you should probably change that.

  • kadmin
        o addprinc -randkey ldap/hostname
        o ktadd -k /etc/openldap/ldap.keytab ldap/hostname"
  • chgrp ldap /etc/openldap/ldap.keytab; chmod 640 /etc/openldap/ldap.keytab

Next up is creating your slapd.conf. Here's a sample one. Some of the things you need to edit are:

  • ACLs
  • SSL certificate paths
  • suffix
  • rootdn and rootpw
  • Hostnames in replication sections

Then configure slapd to be started at boot time and start it. The command line should look like the following. This presumes that the default group for the ldap user is the ldap group. If not, you'll need to add a -g ldap to make sure that slapd is running as group ldap so it can read the Kerberos keytab and SSL key. The KRB5_KTNAME points the Kerberos libraries at a different keytab. The -h option tells slapd to listen on both the standard and ldaps ports. For debugging purposes, you can add a -d 1 and slapd will run in the foreground, printing out info about its actions. This can be very helpful if things aren't working. See the slapd man page for info about values other than 1 to -d to get even more info.

KRB5_KTNAME=/etc/openldap/ldap.keytab /usr/sbin/slapd -u ldap -h “ldap:/// ldaps:/” * For Red Hat do the following: <file> o Add export KRB5_KTNAME=/etc/openldap/ldap.keytab to /etc/sysconfig/ldap o chkconfig ldap on o /etc/init.d/ldap start </file> * For other OSs: <file> o Create an init script which runs the above command </file> Next up is the initial population of your database. Import it with the following command (make sure to specify the rootdn that is actually in slapd.conf). * ldapadd -x -D “cn=Manager,dc=example,dc=com” -W -f sample.ldif Presuming that was successful, you should now comment out the rootdn and rootpw entries out of slapd.conf and restart slapd. All future modifications should be authorized via the ACLs defined in slapd.conf. === Active Directory === Active Directory from Microsoft is a directory service that uses some open protocols, like Kerberos, ldap and SSL. There are several ways to use AD for authentication, you can use pam_krb5, LDAP or winbind. Install pam_krb5 Then to setup pam_krb5 go to /etc/krb5.conf and open it up using your favorite text editor. <code> [logging] default = FILE:/var/log/krb5lib.log [libdefaults] ticket_lifetime = 24000 default_realm = EXAMPLE.COM default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc [realms] EXAMPLE.COM = { kdc = windc.example.com admin_server = windc.example.com default_domain = example.com } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM </code> Then you need to set up /etc/pam.d/common-auth (or other pam service) <code> auth sufficient pam_krb5.so ccache=/tmp/krb5cc_%u auth sufficient pam_unix.so likeauth nullok use_first_pass auth required pam_deny.so </code> Change /etc/ldap.conf to retrieve information from the AD. <code> # Replace windc.example.com with your Windows DC uri ldap://windc.example.com/ base dc=example,dc=com ldap_version 3 # Add a user to AD, that can read the container # with the users, that you want use. binddn cn=ldapreader,cn=Users,dc=example,dc=com bindpw cvfd123 scope sub timelimit 30 pam_filter objectclass=User pam_login_attribute sAMAccountName pam_lookup_policy yes # Modify cn=User,dc=e… to your container with your users. nss_base_passwd cn=User,dc=example,dc=com?sub nss_base_shadow cn=User,dc=example,dc=com?sub nss_base_group cn=User,dc=example,dc=com?sub # For MSSFU: nss_map_objectclass posixAccount User nss_map_objectclass shadowAccount User nss_map_attribute uid sAMAccountName nss_map_attribute uniqueMember member nss_map_attribute uidNumber msSFU30UidNumber nss_map_attribute gidNumber msSFU30GidNumber nss_map_attribute userPassword msSFU30Password nss_map_attribute homeDirectory msSFU30HomeDirectory nss_map_attribute loginShell msSFU30LoginShell nss_map_attribute gecos name nss_map_attribute cn sAMAccountName </code> And /etc/nsswitch.conf <code> passwd: file ldap shadow: file ldap group: file ldap </code> === single sign-on === Single sign-on (SSO) is a method of access control that enables a user to authenticate once and gain access to the resources of multiple software systems. Kerberos is a popular mechanism for applications to externalize authentication entirely. Users sign into the Kerberos server, and are issued a ticket, which their client software presents to servers that they attempt to access. Kerberos is available on Unix, Windows and mainframe platforms, but requires extensive modification of client/server application code, and is consequently not used by many legacy applications. Central to the Kerberos process is the key distribution center (KDC), which in a Windows implementation is installed on all domain controllers. All parties within the Kerberos transaction are said to be part of the same realm, which really means that they have a common shared secret in order to communicate with trust. All messages are encrypted using keys (symmetric - not PKI). A user key is generated from the logon password, a host key is generated when the computer joins the realm and the KDC is effectively a database of security principles. The AS exchange takes place at logon and is concerned with giving clients the right to request tickets to access resources (avoiding the need to hold logon factors). In this process, the client sends an KRB_AS_REQ request to the KDC and, if approved, the KDC will generate a ticket granting ticket (TGT) which is returned to the client as part of the KRB_AS_REP reply. The TGT allows the client to request service tickets and is analogous to a passport - i.e. it is valid for a certain period after which it expires; however once the TGT has been issued, there is no further use of passwords or other logon factors. When the client requires access to a resource, the TGS exchange will commence, whereby the client sends a KRB_TGS_REQ service ticket (ST) request to the KDC with the name of the service to which access is required. The KDC will validate the authentication token within the TGT and if permitted, will return a service ticket which is valid for the requested service as part of the KRB_TGS_REP reply; however at this stage the client is still not authenticated. The service ticket is only valid between the user and the service but provides mutual authentication and speeds up connection times by eliminating the need for the service to perform authentication. Only after the client has sent a KRB_AP_REQ request to the service server and there is mutual authentication, will the client be authenticated and allowed access to the requested resource. The service server may, or may not, send a KRB_AP_REP reply. At all stages, only the KDC can read the TGT and only the service can read the ST. More information === DNS === you need to set up a DNS zone with the same name as your Kerberos realm. The easiest is if you own the publicly visible DNS name, such as `example.org' if your realm is `EXAMPLE.ORG', but you can set up an internal DNS server with the information for your realm only. If this is done, you do not need to keep configuration files updated for the KDC addressing information. KDC location information is to be stored using the DNS SRV RR [RFC 2052]. The format of this RR is as follows: Service.Proto.Realm TTL Class SRV Priority Weight Port Target The Service name for Kerberos is always “_kerberos”. The Proto can be either “_udp”, “_tcp”, or “_tls._tcp”. If these SRV records are to be used, a “_udp” record MUST be included. If the Kerberos implementation supports TCP transport, a “_tcp” record MUST be included. When using “_tcp” with “_kerberos”, this indicates a “raw” TCP connection without any additional encapsulation. A “_tls._tcp” record MUST be specified for all Kerberos implementations that support communication with the KDC across TCP sockets encapsulated using TLS [RFC2246] Example: <code> _kerberos._udp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com. _kerberos._udp.ASDF.COM. IN SRV 1 0 88 kdc2.asdf.com. _kerberos._tcp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com. _kerberos._tcp.ASDF.COM. IN SRV 1 0 88 kdc2.asdf.com. _kerberos._tls._tcp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com. _kerberos._tls._tcp.ASDF.COM. IN SRV 1 0 88 kdc2.asdf.com. </code> ==== 305.6 Integrating LDAP with Email Services (weight: 1) ==== Description: Candidates should be able to integrate LDAP with email services Key Knowledge Areas * Plan LDAP schema structure for email services * Create email attributes in LDAP * Integrate Postfix with LDAP * Integrate Sendmail with LDAP The following is a partial list of the used files, terms and utilities: * Postfix * Sendmail * schema * SASL * POP * IMAP === Postfix === In order to use LDAP lookups, define an LDAP source as a table lookup in main.cf, for example: <code> alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-aliases.cf </code> The file /etc/postfix/ldap-aliases.cf can specify a great number of parameters, including parameters that enable LDAP SSL and STARTTLS. For a complete description, see the ldap_table(5) manual page. == Example: local(8) aliases == Here's a basic example for using LDAP to look up local(8) aliases. Assume that in main.cf, you have: alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-aliases.cf and in ldap:/etc/postfix/ldap-aliases.cf you have: server_host = ldap.example.com search_base = dc=example, dc=com Upon receiving mail for a local address “ldapuser” that isn't found in the /etc/aliases database, Postfix will search the LDAP server listening at port 389 on ldap.example.com. It will bind anonymously, search for any directory entries whose mailacceptinggeneralid attribute is “ldapuser”, read the “maildrop” attributes of those found, and build a list of their maildrops, which will be treated as RFC822 addresses to which the message will be delivered. == Example: virtual domains/addresses == If you want to keep information for virtual lookups in your directory, it's only a little more complicated. First, you need to make sure Postfix knows about the virtual domain. An easy way to do that is to add the domain to the mailacceptinggeneralid attribute of some entry in the directory. Next, you'll want to make sure all of your virtual recipient's mailacceptinggeneralid attributes are fully qualified with their virtual domains. Finally, if you want to designate a directory entry as the default user for a virtual domain, just give it an additional mailacceptinggeneralid (or the equivalent in your directory) of “@fake.dom”. That's right, no user part. If you don't want a catchall user, omit this step and mail to unknown users in the domain will simply bounce. In summary, you might have a catchall user for a virtual domain that looks like this: dn: cn=defaultrecipient, dc=fake, dc=dom objectclass: top objectclass: virtualaccount cn: defaultrecipient owner: uid=root, dc=someserver, dc=isp, dc=dom 1 → mailacceptinggeneralid: fake.dom 2 → mailacceptinggeneralid: @fake.dom 3 → maildrop: realuser@real.dom 1: Postfix knows fake.dom is a valid virtual domain when it looks for this and gets something (the maildrop) back. 2: This causes any mail for unknown users in fake.dom to go to this entry … 3: … and then to its maildrop. Normal users might simply have one mailacceptinggeneralid and maildrop, e.g. “normaluser@fake.dom” and “normaluser@real.dom”. More information === Sendmail === LDAP can be used for aliases, maps, and classes by either specifying your own LDAP map specification or using the built-in default LDAP map specification. The built-in default specifications all provide lookups which match against either the machine's fully qualified hostname (${j}) or a “cluster”. The cluster allows you to share LDAP entries among a large number of machines without having to enter each of the machine names into each LDAP entry. To set the LDAP cluster name to use for a particular machine or set of machines, set the confLDAP_CLUSTER m4 variable to a unique name. For example: define(`confLDAP_CLUSTER', `Servers') Here, the word `Servers' will be the cluster name. As an example, assume that smtp.sendmail.org, etrn.sendmail.org, and mx.sendmail.org all belong to the Servers cluster. Every entry must have either a sendmailMTAHost or sendmailMTACluster attribute or it will be ignored. Be careful as mixing clusters and individual host records can have surprising results (see the CAUTION sections below). == Aliases == The ALIAS_FILE (O AliasFile) option can be set to use LDAP for alias lookups. To use the default schema, simply use: <code>define(`ALIAS_FILE', `ldap:')</code> == Maps == FEATURE()'s which take an optional map definition argument (e.g., mailertable, mailertable, virtusertable, etc.) can instead take the special keyword `LDAP', e.g.: <code> FEATURE(`access_db', `LDAP') FEATURE(`virtusertable', `LDAP') </code> More information === schema === * For posfix integration you can use whatever schema you like, and configure Postfix accordingly. * For sendmail integration you need the sendmail.schema schema. It is distributed with the sendmail source code. Attributes (subset) used by sendmail: * mailHost → where is the mailbox of the user located (optional). * mailLocalAddress → which mail addresses are link to the user (optional). * mailRoutingAddress → main mail address of the user (optional). === SASL === /etc/saslauthd.conf <code> ldap_servers: ldap://ldap.example.com/ ldap_search_base: dc=example,dc=com ldap_auth_method: userPassword </code> Configure a service (for example /etc/sasl2/Sendmail.conf) <code>pwcheck_method: saslauthd</code> === POP + IMAP === Implementation depends on used pop/imap daemon. Some can be configured using PAM. Others have their own configuration for using LDAP. FIXME ===== Topic 306: Capacity Planning ===== ==== 306.1 Measure Resource Usage (weight: 4) ==== Description: Candidates should be able to measure hardware resources and network bandwidth usage Key Knowledge Areas * Measure CPU usage * Measure memory usage * Measure disk I/O * Measure network I/O * Measure firewalling and routing throughput * Map client bandwidth usage The following is a partial list of the used files, terms and utilities: * iostat * vmstat * pstree * w * lsof * top * uptime * sar * mpstat === iostat === Without parameters this command gives you statistics about CPU and Disk. If iostat is not on your system, it is in the sysstat rpm. Running without parameters is the combination of 'iostat -c' and 'iostad -d'. For complete reference check the man page. The default output for iostat is: [root@localhost ~]# iostat Linux 2.6.18-8.1.8.el5 (localhost.localdomain) 09/26/2007 avg-cpu: %user %nice %system %iowait %steal %idle 3.40 0.00 14.88 1.88 0.00 79.83 Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn sda 8.88 194.69 62.55 149045 47884 dm-0 14.86 190.05 62.54 145498 47880 dm-1 0.14 1.15 0.00 880 0 hda 0.01 0.19 0.00 144 0 If you like to see more use 'iostat -x'. To display a certain device use 'iostat -d -p hda'. Play around on your practice system so what you can do with iostat. === vmstat === With vmstat you can also see disk and cpu statistics. In addition it gives you information about your physical and virtual memory. Default it gives you the following output: procs ———–memory———- —swap– —–io—- –system– —–cpu—— r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 0 142128 9308 71504 0 0 58 20 1014 49 2 10 87 1 0 Check the man page for reference. If you have high numbers in the swap section, it might be a good idea to increase your virtual memory. === pstree === To see a hierarchical view of your process list, use pstree. Check the man page for formatting options and how to display the information. A snippet of possible output is below: init-+-acpid |-anacron |-atd |-auditd-+-python | `-{auditd} |-automount—4*[{automount}] |-crond |-cupsd |-dbus-daemon === w === The w command shows who is doing what on your system. <code> 00:04:22 up 631 days, 22:45, 1 user, load average: 0.00, 0.02, 0.00 USER TTY LOGIN@ IDLE JCPU PCPU WHAT root pts/1 00:04 0.00s 0.00s 0.00s w </code> === lsof === lsof - list open files <code> COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME init 1 root cwd DIR 253,0 4096 2 / init 1 root rtd DIR 253,0 4096 2 / init 1 root txt REG 253,0 38620 6062237 /sbin/init init 1 root mem REG 253,0 129824 14814385 /lib/ld-2.6.so init 1 root mem REG 253,0 1673804 14814386 /lib/libc-2.6.so init 1 root mem REG 253,0 20660 14814387 /lib/libdl-2.6.so init 1 root mem REG 253,0 93512 14811242 /lib/libselinux.so.1 init 1 root mem REG 253,0 245376 14814413 /lib/libsepol.so.1 init 1 root 10u FIFO 0,16 1593 /dev/initctl </code> or when used with /path/file it reports which process has /path/file open <code> COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME init 1 root mem REG 253,0 129824 14814385 /lib/ld-2.6.so udevd 612 root mem REG 253,0 129824 14814385 /lib/ld-2.6.so auditd 2061 root mem REG 253,0 129824 14814385 /lib/ld-2.6.so audispd 2063 root mem REG 253,0 129824 14814385 /lib/ld-2.6.so syslogd 2085 root mem REG 253,0 129824 14814385 /lib/ld-2.6.so klogd 2088 root mem REG 253,0 129824 14814385 /lib/ld-2.6.so irqbalanc 2100 root mem REG 253,0 129824 14814385 /lib/ld-2.6.so rpcbind 2122 rpc mem REG 253,0 129824 14814385 /lib/ld-2.6.so rpc.statd 2151 rpcuser mem REG 253,0 129824 14814385 /lib/ld-2.6.so </code> === top === top - display Linux tasks <code> top - 23:57:21 up 4:38, 1 user, load average: 0.07, 0.10, 0.09 Tasks: 176 total, 1 running, 175 sleeping, 0 stopped, 0 zombie Cpu0 : 0.8%us, 0.3%sy, 0.0%ni, 98.7%id, 0.0%wa, 0.2%hi, 0.0%si, 0.0%st Cpu1 : 0.2%us, 0.0%sy, 0.0%ni, 99.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 0.8%us, 0.3%sy, 0.0%ni, 98.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 0.5%us, 0.2%sy, 0.0%ni, 99.4%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 4139076k total, 1036272k used, 3102804k free, 87672k buffers Swap: 4194296k total, 0k used, 4194296k free, 425324k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3439 someuser 20 0 149m 44m 25m S 1 1.1 3:18.00 amarokapp 24215 someuser 20 0 69252 11m 6248 S 1 0.3 1:25.23 xmms 3146 root 20 0 116m 91m 5436 S 0 2.3 10:45.09 Xorg 4905 root 20 0 2532 1048 780 R 0 0.0 0:00.04 top 1 root 20 0 2140 644 556 S 0 0.0 0:00.99 init 2 root 15 -5 0 0 0 S 0 0.0 0:00.00 kthreadd 3 root RT -5 0 0 0 S 0 0.0 0:00.03 migration/0 4 root 15 -5 0 0 0 S 0 0.0 0:00.01 ksoftirqd/0 5 root RT -5 0 0 0 S 0 0.0 0:00.00 watchdog/0 6 root RT -5 0 0 0 S 0 0.0 0:00.04 migration/1 7 root 15 -5 0 0 0 S 0 0.0 0:00.00 ksoftirqd/1 8 root RT -5 0 0 0 S 0 0.0 0:00.00 watchdog/1 9 root RT -5 0 0 0 S 0 0.0 0:00.03 migration/2 10 root 15 -5 0 0 0 S 0 0.0 0:00.00 ksoftirqd/2 11 root RT -5 0 0 0 S 0 0.0 0:00.00 watchdog/2 12 root RT -5 0 0 0 S 0 0.0 0:00.04 migration/3 13 root 15 -5 0 0 0 S 0 0.0 0:00.00 ksoftirqd/3 14 root RT -5 0 0 0 S 0 0.0 0:00.00 watchdog/3 15 root 15 -5 0 0 0 S 0 0.0 0:00.06 events/0 16 root 15 -5 0 0 0 S 0 0.0 0:00.04 events/1 17 root 15 -5 0 0 0 S 0 0.0 0:00.05 events/2 18 root 15 -5 0 0 0 S 0 0.0 0:00.04 events/3 </code> === uptime === uptime - Tell how long the system has been running. <code> 23:58:43 up 631 days, 22:54, 1 user, load average: 0.00, 0.00, 0.00 </code> === sar === sar - Collect, report, or save system activity information. <code> Linux 2.6.22.9-91.fc7PAE (localhost.localdomain) 10/14/2007 12:14:40 AM CPU %user %nice %system %iowait %steal %idle 12:14:41 AM all 0.75 0.00 0.25 0.00 0.00 99.00 12:14:42 AM all 0.50 0.00 0.25 0.00 0.00 99.25 12:14:43 AM all 0.53 0.00 0.00 0.00 0.00 99.47 12:14:44 AM all 0.70 0.00 0.23 0.00 0.00 99.06 12:14:45 AM all 0.50 0.00 0.25 0.00 0.00 99.25 12:14:46 AM all 0.50 0.00 0.25 0.00 0.00 99.25 12:14:47 AM all 0.75 0.00 0.25 0.00 0.00 99.00 12:14:48 AM all 0.50 0.00 0.25 0.00 0.00 99.25 12:14:49 AM all 0.50 0.00 0.25 0.00 0.00 99.25 12:14:50 AM all 0.51 0.00 0.51 0.00 0.00 98.99 Average: all 0.58 0.00 0.25 0.00 0.00 99.17 </code> === mpstat === mpstat - Report processors related statistics. <code> Linux 2.6.22.9-91.fc7PAE (localhost.localdomain) 10/14/2007 12:10:02 AM CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s 12:10:02 AM all 3.24 0.29 0.71 0.13 0.02 0.02 0.00 95.60 272.12 </code> ==== 306.2 Troubleshoot Resource Problems (weight: 4) ==== Description: Candidates should be able to identify and troubleshoot resource problems Key Knowledge Areas * Match / correlate system symptoms with likely problems * Identify bottlenecks in a system The following is a partial list of the used files, terms and utilities: * swap * processes blocked on I/O * blocks in * blocks out === swap === Using the command free you can see memory and swap usage. <code> total used free shared buffers cached Mem: 4139076 1035864 3103212 0 89060 428132 -/+ buffers/cache: 518672 3620404 Swap: 4194296 0 4194296 </code> === processes blocked on I/O === Using the command ps you can see the process stats, for example: <code> ps -eo pid,state,comm | grep ' D ' </code> From the ps manual: <file> PROCESS STATE CODES Here are the different values that the s, stat and state output specifiers (header “STAT” or “S”) will display to describe the state of a process. D Uninterruptible sleep (usually IO) </file> === blocks in + out === Using the command vmstat (column bi and bo) <code> procs ———–memory———- —swap– —–io—- –system– —–cpu—— r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 3100184 89860 428184 0 0 6 6 68 391 3 1 96 0 0 </code> Using the command iostat <code> Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn sda 3.08 47.34 44.57 945092 889892 sdb 0.10 0.93 0.00 18491 16 dm-0 7.73 47.08 44.57 939986 889888 dm-1 0.01 0.04 0.00 888 0 sdc 0.00 0.02 0.00 360 0 dm-2 0.10 0.81 0.00 16138 16 </code> ==== 306.3 Analyze Demand (weight: 2) ==== Description: Candidates should be able to analyze capacity demands Key Knowledge Areas * Identify capacity demands * Detail capacity needs of programs * Determine CPU / memory needs of programs * Assemble program needs into a complete analysis The following is a partial list of the used files, terms and utilities: * PDQ * CPU usage * memory usage * appropriate measurement time * trend * model * what-if * validate * performance equation === PDQ === PDQ (Pretty Damn Quick) is a queueing model solver, not a simulator. Computer system resources (whether hardware and software) are represented by queues (more formally, a queueing network-not to be confused with a data network-which could be a PDQ queueing model) and the queueing model is solved “analytically” (meaning via a combination of algorithmic and numerical procedures). Queues are invoked as functions in PDQ by making calls to the appropriate library functions. Once the queueing model is expressed in PDQ, it can be solved almost instantaneously by calling the PDQ_Solve() function. This in turn generates a report of all the corresponding performance metrics such as: system throughput, and system response time, as well as details about queue lengths and utilizations at each of the defined queues. This algorithmic solution technique makes it orders of magnitude faster than setting up (and debugging; a step that is often not mentioned by simulationists) and running repeated (another step that is often glossed over) experiments to see if the solutions are statistically meaningful. PDQ solves everything as though it were in steady state. The tradeoff is that you cannot computer higher order statistics. (Actually, you can but that would be major digression here. Come to a class to find out more about that). More information === appropriate measurement time === During normal working hours and at peak hours. === trend === Analyzing changes over time and extrapolating future demands. === what if === Predict impact of changes in workload. === validate === Validate results overtime and verify trends. === performance equation === The performance equation is a term used in computer science. It refers to the calculation of the performance or speed of a central processing unit (CPU). ==== 306.4 Predict Future Resource Needs (weight: 1) ==== Description: Candidates should be able to monitor resource usage to predict future resource needs Key Knowledge Areas * Predict capacity break point of a configuration * Observe growth rate of capacity usage * Graph the trend of capacity usage The following is a partial list of the used files, terms and utilities: * diagnose * predict growth * average * resource exhaustion Monitoring and predicting capacity growth can be done using the tools described in section 306.1. Graphing this can be done using rrd-tools. FIXME ===== Additional notes ===== https://group.lpi.org/publicwiki/bin/view/Examdev/LPIC-301-Task-List ===== Acknowledgments ===== Most of the information in this document was collected from different sites on the internet and was copied (un)modified. Some text was created by me and my colleagues. The copyright of the text in document remains by their owners and is noway claimed by me. If you wrote some of the text we copied, I like to thank you for your excellent work. Nothing in this document should be published for commercial purposes without gaining the permission of the original copyright owners. For questions about this document or if you want to help keep this document up-to-date, you can contact me at webmaster@universe-network.net

wiki/certification/lpic301.txt · Last modified: 2008/10/26 20:38 by maartenl