LPIC-3 (301 exam) book

Michael Boelen - rootkit.nl [ Security+, Linux+, LPIC-1, LPIC-2, CIW Security Professional, ITIL ] Usage notes Last 26 October 2008 updated Goal Provide a study guide for LPIC-3, 117-301 Network and LDAP administrators, people who want to attain Audience LPIC-3 (117-301) certification License Creative Commons license Notes All operations are performed on an Ubuntu system. Keep this in mind when using different file locations or installation/configuration instructions on your system. This book is setup as an step by step guide to install, configure and maintain OpenLDAP. This book is a work in progress and can contain grammar errors. Suggestions or input are appreciated. Progress: Stage 1: Initial writing Stage 2: Completing examples/adding exam questions Stage 3: Finishing questions/after care Stage: 1 3 2

100% 45%

Index
Introduction What is LDAP? Installation Installation Configuration General configuration Database configuration Slapd Database configuration and tweaking Database indexing LDAP client configuration Security: Security: SASL Security: Proxy Authorization Security: Authentication methods Security: Client/Server certificates Security: Hardening LDAP servers Security: Access Control Lists Security: TLS/SSL Security: Security Strength Factors Integration

 LDAP and authentication Integration: Apache2 and LDAP Integration: Postfix and LDAP Integration: Sendmail and LDAP Integration: FreeRADIUS and LDAP Integration: OpenSSH and LDAP Integration: Samba and LDAP Integration: Dovecot POP/IMAP and LDAP Integration: CUPS printing and LDAP Integration: Kerberos and LDAP Integration: Active Directory and LDAP Migration: NIS to LDAP Replication Debugging: Logging Misc: Pre capacity planning Custom tooling: Perl OpenLDAP cheatsheet Useful links References and Thanks

What is LDAP?
LDAP stands for Lightweight Directory Access Protocol, a way to describe directory contents as separated records (entries). These entries consist of a collection of attributes, all with a globally-unique key, the Distinguished Name (DN). The DN consists of smaller pieces, describing the entity. Examples (with naming attribute): user (cn), group (cn), computer (cn), container (cn), organizational unit (ou), domain (dc). LDAP is based on the DAP X.500 standard (created at the University of Michigan), but with the goal to be "simple". The X.500 standard is very extensive and often too complex for smaller needs, that's why a light version of DAP was created. With LDAP we can create and store information for white pages (same as yellow pages, but for individuals, not companies), authentication of users and hosts and storing custom data sets. Another use is creating meta directories, systems which control the flow between multiple directory systems (with all belong to one directory information tree, or DIT) for ie single sign-on purposes and more. OpenLDAP does not support Class of Service (at the time of writing). The exam requires you to know the definition behind it: a way to define templates which can be used when creating new records. This templates define default values, often user based. They can be compared to the usage of roles. A directory namespace is a (big) container in which one or more forests and trees of objects reside. This is also know as the context. We use the term container to define where an object (like a user) belongs to, for example: ou=Sales,dc=rootkit,dc=nl. Container objects can be containers itself, organizational units, or domains and can contain other objects (like user objects, group objects, computer objects etc). An object class defines the type of the object. It must be present in every LDAP entry (example: posixAccount).

Installation

Option 1: install binary package (apt-get/dpkg, rpm)

# apt-get install slapd

Option 2: install from sources

# # # # # # # tar xfvz openldap-2.4.8.tgz ./configure --help ./configure <options> make make dep make test make install

To customize and optimize an OpenLDAP installation, option 2 is preferred. You can tune the options and application support your OpenLDAP installation will have. Disabling unused modules for your site is one of the options to optimize (for speed and throughput). Read the INSTALL file for basic installation details. LDAPv3 compliancy OpenLDAP needs SASL libraries to be LDAP version 3 compliant. Exam note: You should be familiar with installing OpenLDAP from source or by using binary packages (dpkg, apt-get, rpm)

General configuration
After installing OpenLDAP, a directory /etc/ldap should be present with the following contents:
/etc/ldap# -rw-r--r-drwxr-xr-x drwxr-xr-x -rw-r----ls -l 1 root 2 root 2 root 1 root root 245 2008-04-07 23:34 root 4096 2008-04-07 23:34 root 4096 2008-04-20 16:10 openldap 4746 2008-04-20 16:10 ldap.conf sasl2 schema slapd.conf

The OpenLDAP server configuration file is called slapd.conf. The ldap.conf file is used for clients, the sasl2 directory for SASL specific settings and the schema directory to store the available schema's. The general format of the slapd.conf file is as follows: # Global configuration directives <global config directives> # Backend definition backend <type 1> <backend-specific directives> # First database definition & Config directives database <type 1> <database-specific directives> # Second database definition & Config directives database <type 2> <database-specific directives> # Other backend, database and config options <other configuration things>

slapd.conf To store the data from OpenLDAP we define the directory where the database files should be located. Default this will be /var/lib/ldap. From a security point of view it's mandatory to lock down permissions only to the root and openldap user/group, to avoid reading configuration snippets or passwords. Exam note: Make sure to know all options in the slapd.conf configuration file. Backends Without OpenLDAP a backend is being used to store data. By default some backends are already available, while others can be installed or configured while installing OpenLDAP. List of available backends: Type bdb config dnssrv hdb Description Berkeley DB transactional backend Slapd configuration backend DNS SRV backend Hierarchical variant of bdb backend Lightweight Directory Access ldap Protocol (Proxy) backend ldbm Lightweight DBM backend Lightweight Data Interchange ldif Format backend meta Meta Directory backend Monitor backend (dynamic, not for monitor storing normal data) Provides read-only access to passwd passwd(5) perl Perl Programmable backend shell Shell (extern program) backend sql SQL Programmable backend Exam note: make sure to know which backends are supported and that hdb and bdb are often used.

Database configuration
Within the slapd.conf file, we can define our database backend and connection settings. Access: To define an "manager" account of the database, use the RootDN option. This entity will have no limits (like access control limits).
RootDN: "cn=Manager,dc=rootkit,dc=nl" RootPW: secret

This DN can be protected with a password, as shown in the example above. The password can be saved in clear text or as a hash (hashed password can be created with slappasswd).
# slappasswd New password: Re-enter new password: {SSHA}a5vgUC+7Sgc6thpZ8w3IN+OUAOj+HnQL

Slapd
To run a OpenLDAP server, we have to start the slapd process, which stands for Stand-alone LDAP Daemon. By default the daemon listens at TCP port 389 (or 636 for LDAPS) for incoming requests. Most options to start the daemon are very common, like defining debug level, network connectivity, configuration file location. For security the -r option is interesting, to chroot the daemon (and therefor limiting the access to other files in case of a security breach). TLS/SSL To use encryption, slapd can be started with the -h parameter, defining which protocols are available (and on which network addresses/ports). Example:
slapd -h ldap://127.0.0.1:389 ldaps:///

In this example slapd will listen on the local machine at the default port 389 (TCP) for unencrypted LDAP requests, and listen to all available network addresses at the default LDAPS port (636/TCP) for encrypted requests). Tool mode Slapd can also be used to start the more used tools like slapadd, slapcat etc. This "tool mode" is available as a backup when the normal scripts/tools are not present.

Pre capacity planning

Before creating a directory, you should have at least answered a few basic questions:

What data do I want to store? What is the initial size of the data? What after 1 year? 3 years? 10 years? Can I scale my hardware to the needs of the directories? What will be my peek times? Which redundancy do I need? at what cost?

Capacity planning can save a lot of troubles later on, especially when the amount of data is growing rapidly.

Creating an initial directory

A common way to fill a directory is by using LDIF files (LDAP Data Interchange Format). These plain text files can be used to insert, modify or delete data. LDIF files can be imported

by using ldapadd (which authenticates to a running service) or with slapadd (directly into a database while LDAP daemon is offline). The data being imported has to be redirected on the stdin (example: slapadd < filename.ldif). Example:
dn: uid=michael,ou=People,dc=rootkit,dc=nl uid: michael cn: Michael Boelen objectClass: account objectClass: posixAccount objectClass: top userPassword: {crypt}rF4x4xNEP1bA. loginShell: /bin/sh uidNumber: 3000 gidNumber: 3000 homeDirectory: /home/michael gecos: Michael Boelen, Administrator

Changing entries
To extend or change existing directory entries, we can use a LDIF file with the changetype option. Example:
dn: cn=Michael,ou=People,dc=rootkit,dc=nl # modify DN above changetype: modify # Add phone number add: telephonenumber telephonenumber: 1234567890

Common changetypes:

add: add a field, or if "add" is omitted, add a new entry. Add is the default action when no changetype is specified in LDIF files. delete: delete a field, or if "delete" is omitted, delete entry modify: modify a field modrdn: rename DN (only if no child entries are present)

In addition, for these actions there are commands which can be directly used: ldapadd, ldapmodify, ldapdelete, ldapmodrdn.

Extending directories
# ldapadd -x -D "cn=admin,dc=rootkit,dc=nl" < /data/ldap/michael.ldif ldap_bind: Server is unwilling to perform (53) additional info: unauthenticated bind (DN with no password) disallowed # ldapadd -x -D "cn=admin,dc=rootkit,dc=nl" -W < /data/ldap/michael.ldif Enter LDAP Password: adding new entry "uid=michael,ou=People,dc=rootkit,dc=nl"

LDAP referrals LDAP directories can redirect a request to another server, for example when a "write" request is being performed on a read-only slave. The slave host redirects the client with the request, to the correct server.

Schema and objectClass definitions

Within the context of LDAP, schema's define what a directory looks like and which attributes it contains. Every element in a schema is identified by a globally unique Object Identifier (OID), which looks the same as in the SNMP protocol. An OID consists of a string with numbers (example: 1.3.6.1.4.1.7165.2.2.6). When creating or extending a schema, an unique OID should be used and can not be 'hijacked' from an existing OID tree. Instead, a new OID should be registered at IANA. Schema's can be included in the main configuration file (slapd.conf) by using the include directive (example: include /path/to/core.schema). Example snippet from core schema:
attributeType ( 2.5.4.41 NAME 'name' DESC 'name(s) associated with the object' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) attributeType ( 2.5.4.3 NAME ( 'cn' 'commonName' ) DESC 'common name(s) associated with the object' SUP name )

OID 2.5.4.41 has the alias 'name' with a syntax and data type description. Structural and auxiliary object classes An object class is structural when it defines to which object(s) the object belongs to. All others are auxiliary object classes, which have the purpose to extend existing objects with extra attributes. Every entry can not have more than one structural object class. Also if the structural object class of an entry has to be changed, this can be only done by recreating the entry. OpenLDAP has a few default schema's, which are often used. For example, there is a NIS based schema, to support authentication of systems and people for example.
/etc/ldap/schema# -rw-r--r-- 1 root -rw-r--r-- 1 root -rw-r--r-- 1 root -rw-r--r-- 1 root -rw-r--r-- 1 root -rw-r--r-- 1 root -rw-r--r-- 1 root -rw-r--r-- 1 root -rw-r--r-- 1 root -rw-r--r-- 1 root -rw-r--r-- 1 root -rw-r--r-- 1 root -rw-r--r-- 1 root -rw-r--r-- 1 root -rw-r--r-- 1 root ls -l root 2180 root 2084 root 21175 root 20346 root 12091 root 14030 root 10476 root 3146 root 3573 root 6362 root 3295 root 2473 root 5998 root 6891 root 7725 2008-04-07 2008-04-07 2008-04-07 2008-04-07 2008-04-07 2008-04-07 2008-04-07 2008-04-07 2008-04-07 2008-04-07 2008-04-07 2008-04-07 2008-04-07 2008-04-07 2008-04-07 23:34 23:34 23:34 23:34 23:34 23:34 23:34 23:34 23:34 23:34 23:34 23:34 23:34 23:34 23:34 collective.schema corba.schema core.ldif core.schema cosine.ldif cosine.schema duaconf.schema dyngroup.schema inetorgperson.ldif inetorgperson.schema java.schema misc.schema nadf.schema nis.ldif nis.schema

-rw-r--r--rw-r--r--rw-r--r--rw-r--r--

1 1 1 1

root root root root

root root root root

3393 1602 4678 3593

2008-04-07 2008-04-07 2008-04-07 2008-04-07

23:34 23:34 23:34 23:34

openldap.ldif openldap.schema ppolicy.schema README

Schema files provide useful information about which attributes may or must be filled in. samba3.schema example:
objectclass ( 1.3.6.1.4.1.7165.2.2.6 NAME 'sambaSamAccount' SUP top AUXILIARY DESC 'Samba 3.0 Auxilary SAM Account' MUST ( uid $ sambaSID ) MAY ( cn $ sambaLMPassword $ sambaNTPassword $ sambaPwdLastSet $ sambaLogonTime $ sambaLogoffTime $ sambaKickoffTime $ sambaPwdCanChange $ sambaPwdMustChange $ sambaAcctFlags $ displayName $ sambaHomePath $ sambaHomeDrive $ sambaLogonScript $ sambaProfilePath $ description $ sambaUserWorkstations $ sambaPrimaryGroupSID $ sambaDomainName $ sambaMungedDial $ sambaBadPasswordCount $ sambaBadPasswordTime $ sambaPasswordHistory $ sambaLogonHours))

Attributes consist of an unique OID and several fields, to describe what type of data is hold. Some examples of the fields are: name (case sensitive unique name) - description (description of the data in it) - equality (for example to ignore capitals) - substring (for example searching a part of the string, is enough to show up as a result) - syntax.

Searching/Querying LDAP directories

ldapsearch -x "(cn=Michael Boelen)" ldapsearch -x "(ou=people)" "(objectClass=account)" When multiple records are found, output will be in LDIF format. Search on multiple fields: When a search query has to match 2 or more fields, the ampersand sign (&) can be used. Example: (&(objectClass=posixAccount)(uid=michael)) In this example the user id has to be 'michael' and it should be of the type "posix account" (used in nis schema). Examples: Search full tree: ldapsearch -b "dc=rootkit,dc=nl" -s sub "objectclass=*" Search a single contact (CN) and return specific fields: ldapsearch -b "dc=rootkit,dc=nl" "cn=Michael Boelen" mail telephonenumber Search everyone from the office in Germany: ldapsearch -b "o=Office Germany,dc=rootkit,dc=nl"

Exam note: You should be familiar with searching data and optimizing LDAP queries. Use proper search filters to minimize the amount of entries returned.

LDAP tools overview

slapadd Usage: add data When to use: importing LDIF files to extend or restore the directory. Notes: Tool should be used when slapd is offline slapacl Usage: test if access control lists are defined properly. When to use: for example after creating a new user to see if his/her permissions are correct. Notes: slapcat Usage: dump LDAP database to LDIF format. When to use: when new data has to be inserted via slapadd or when creating a text backup of your database. Notes: slapindex Usage: recreate indices for slapd database(s). When to use: after changing slapd.conf (like adding/removing schema's), or database problems. Notes: run as the same slapd id, to prevent file permission issues. Also make sure the databases are not in use. Exam note: Be familiar with the tools and when to use them.

Database configuration and tweaking

By default OpenLDAP uses the hdb backend (which is the hierarchical version of a Berkeley Database Backend (BDB)). The database and related configuration file (DB_CONFIG) can be found in /var/lib/ldap.
/var/lib/ldap# ls -l -rw-r--r-- 1 openldap -rw------- 1 openldap -rw------- 1 openldap -rw------- 1 openldap -rw------- 1 openldap -rw------- 1 openldap -rw-r--r-- 1 openldap -rw------- 1 openldap -rw------- 1 openldap -rw------- 1 openldap -rw------- 1 openldap openldap 2048 2008-04-20 16:10 alock openldap 8192 2008-04-20 16:10 __db.001 openldap 2629632 2008-04-20 16:10 __db.002 openldap 98304 2008-04-20 16:10 __db.003 openldap 565248 2008-04-20 16:10 __db.004 openldap 24576 2008-04-20 16:10 __db.005 openldap 96 2008-04-20 16:10 DB_CONFIG openldap 8192 2008-04-20 16:10 dn2id.bdb openldap 32768 2008-04-20 16:10 id2entry.bdb openldap 53766 2008-04-20 16:10 log.0000000001 openldap 8192 2008-04-20 16:10 objectClass.bdb

Common errors:
/var/lib/ldap# db4.6_stat -c a db4.6_stat: Program version 4.6 doesn't match environment version 0.77

db4.6_stat: DB_ENV->open: DB_VERSION_MISMATCH: Database environment version mismatch Solution: check which db version is used (apt-cache showpkg slapd) and install the correct db-utils (apt-get install db4.2-util).

Tuning cache: One of the options to tune is the cachesize. This size describes the number of entries it will hold in it's cache. This option can be set in DB_CONFIG. Check points: OpenLDAP can use check points (snapshots). Configuring checkpoints is generally a good idea, or else if things crash there will be no recovery point available. Example: checkpoint 256 15 (make a check every 256 kilobyte of data or every 15 minutes, whichever occurs first). The option 'dbnosync' can be used together with check points. It can improve performance, since changes don't get written back to the database (from memory). However, when the server crashes all data between the last check point and the crash, is lost. Proper indexing: By using proper indexes, (and well formed) requests could be speed up greatly.

Database indexing
To optimize search requests, OpenLDAP can be configured to put an index on one or more fields. Using indices can improve performance huge, but also decrease when improperly used (ie. index at wrong fields or too much indices). Creating performance statistics (or graphs) can be a good help in maintaining a properly optimized LDAP server. The general rule for creating an index: if you use the attribute often in a search, create an index for it. slapd.conf example:
index cn,sn,givenname,mail eq

This snippet will add an index to the attributes cn, sn, givenname and mail. It will index only the full strings in these attributes, since the type is 'eq', which means only exact matches will show up in the search results. Index types:

approx: phonetic match eq: exact match pres: value present or not sub: substring matching

Note: When adding one or more indexes, slapd won't use them automatically. You have to run slapindex to recreate the indexes. Keep in mind to execute slapindex as the correct database user, to avoid an incorrect file owner on the database files.

 OpenLDAP client configuration

The OpenLDAP client tools (ldap*) use the configuration file /etc/openldap/ldap.conf. Example /etc/openldap/ldap.conf:
URI BASE TLS_CACERT ldaps://ldap.rootkit.nl/ dc=rootkit,dc=nl /etc/ssl/ca-cert.pem

When using PAM, the nss_ldap module use the /etc/ldap.conf file, to find server connection information. Example /etc/ldap.conf:
host base ssl tls_checkpeer tls_cacertfile ldap1.rootkit.nl ldap2.rootkit.nl dc=rootkit,dc=nl start_tls yes /etc/ssl/ca-cert.pem

LDAP and authentication

Check if the LDAP module (pam_ldap.so) is already installed, or install if not present.
apt-get install libpam-ldap

Check /etc/auth-client-config/profile.d/ldap-auth-config to see which PAM sections are applied and run the auth-client-config tool.
# # # # auth-client-config auth-client-config auth-client-config auth-client-config -p -p -p -p lac_ldap lac_ldap lac_ldap lac_ldap -t -t -t -t pam-auth pam-password pam-account pam-session

This will add the pam_mkhomedir.so, so a new home directory is created after logging in Check the nsswitch.conf file to include LDAP in search queries.
# /etc/nsswitch.conf # passwd: compat ldap group: compat ldap shadow: compat ldap

Integration: Apache2 and LDAP

# # # # # apt-get apt-get apt-get a2enmod a2enmod install apache2 install php5 install php5-ldap ldap authnz_ldap

Add following snippet to the Apache VirtualHost configuration:

AuthBasicProvider ldap AuthLDAPBindDN "cn=Admin,dc=rootkit,dc=nl" AuthLDAPBindPassword "test" AuthLDAPURL "ldap://127.0.0.1:389/ou=People,dc=rootkit,dc=nl?uid" AuthLDAPGroupAttributeIsDN on Require ldap-user michael AuthType basic AuthName "secret"

See the Apache 2.2 mod_authnz page for more information.

 Integration: Postfix and LDAP

# apt-get install postfix-ldap Example snippet from main.cf: alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-aliases.cf and in /etc/postfix/ldap-aliases.cf: server_host = ldap.example.com search_base = dc=example, dc=com

See the Postfix LDAP readme for more information.

Integration: Sendmail and LDAP

define(`confLDAP_CLUSTER', `Servers') define(`ALIAS_FILE', `ldap:') FEATURE(`access_db', `LDAP') FEATURE(`virtusertable', `LDAP')

Integration: FreeRADIUS and LDAP

Installation:
# apt-get install freeradius-ldap

Configuration: FreeRADIUS has a module called rlm_ldap which can be used for LDAP support. There is a mapping file (raddb/ldap.attrmap) between FreeRADIUS and LDAP to match attributes. An schema exists with the file name RADIUS-LDAPv3.schema and can be found in the doc directory. The objectclass for FreeRADIUS is radiusprofile. To configure LDAP support, edit the radiusd.conf configuration file and add an "ldap" section to the modules. Example:
modules { ... ldap { server = localhost port = 636 net_timeout = 1 timeout = 2 timelimit = 5 ldap_debug = 0x0028 ldap_connections_number = 5 basedn = "o=Rootkit Org,c=NL" filter = "(uid=%u)" start_tls = no tls_mode = 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 = "allow" default_profile = "cn=RadiusProfile,o=Rootkit Org,c=NL" access_attr = "dialupAccess" } }

Integration: OpenSSH and LDAP

include /etc/openldap/schema/openssh-lpk.schema sshd_config: UseLPK yes LpkServers LpkUserDN LpkGroupDN LpkBindDN LpkBindPw LpkServerGroup LpkForceTLS LpkSearchTimelimit LpkBindTimelimit

ldap://10.1.7.1 ldap://10.1.7.2 ou=users,dc=example,dc=com ou=groups,dc=example,dc=com cn=Manager,dc=example,dc=com somepasswordifneeded somegroupname yes 3 3

/etc/ldap.conf (pam_ldap/nss_ldap): UseLPK yes LpkLdapConf /etc/ldap.conf n: uid=michael,ou=People,dc=rootkit,dc=nl sn: michael cn: Michael Boelen gecos: Michael Boelen uidNumber: 1001 gidNumber: 1001 uid: michael homeDirectory: /home/michael loginShell: /bin/bash objectClass: inetOrgPerson objectClass: person objectClass: ldapPublicKey objectClass: posixAccount sshPublicKey: ssh-rsa Ss6tx... sshPublicKey: environment="LDP_USER=michael" ssh-rsa AAAAB...

Integration: Samba and LDAP

Installing Samba:
apt-get install samba apt-get install samba-doc apt-get install smbldap-tools

Before Samba can access the LDAP server, you need to store the LDAP admin password in the Samba database (secrets.tdb). This can be done with the following command:
# smbpasswd -w secret

This Samba database can be inspected by using the tdbdump tool. Import samba3.schema
cp /usr/share/doc/samba-doc/examples/LDAP/samba.schema.gz /etc/ldap/schema/ gunzip /etc/ldap/schema/samba.schema.gz

Required schema's for Samba

Edit slapd.conf: include include include include /etc/openldap/schema/cosine.schema /etc/openldap/schema/inetorgperson.schema /etc/openldap/schema/nis.schema /etc/openldap/schema/samba.schema

When everything is configured, run `slapindex` to create the indexes. To convert smbpasswd databases and create an import for LDAP, it's recommended to use a tool (like mkntpwd or pdbedit). Example of importing an existing database:
pdbedit --import=smbpasswd:/etc/samba/smbpasswd -export=ldapsam:ldap://ldap.example.com

Example of an samba account (sambaSamAccount) in LDAP:

objectClass: sambaSamAccount sambaAcctFlags: [U ] sambaLMPassword: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx sambaNTPassword: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy sambaSID: S-1-0-0-14966

The sambaSID value is created by taking the primary SID and an unique ID. This ID is made by taking the Unix uid, multiple it by 2 and add 1000 (or 1001 for groups, or gids).
dn: uid=michael,ou=People,dc=rootkit,dc=nl sambaLogonTime: 0 displayName: Michael Boelen sambaLMPassword: 552902031BEDE9EFAAD3B435B51404EE sambaPrimaryGroupSID: S-1-5-21-2447931902-1787058256-3961074038-1201 objectClass: posixAccount objectClass: sambaSamAccount sambaAcctFlags: [UX ] userPassword: {crypt}CzZ2ek9Rrreti uid: michael uidNumber: 1001 cn: Michael Boelen loginShell: /bin/bash logoffTime: 2147483647 gidNumber: 1001 sambaKickoffTime: 2142283620 sambaPwdLastSet: 1022199456 sambaSID: S-1-5-21-2447931902-1787058256-3961074038-5004 homeDirectory: /home/michael sambaPwdCanChange: 0 sambaPwdMustChange: 2147483647 sambaNTPassword: 878D8014606CDA29677A44EFA1353FC7

Example of smb.conf:
security = user passdb backend = ldapsam:ldap://ldap.example.com ldap ssl = start tls ldap suffix = dc=example,dc=com ldap user suffix = ou=people ldap group suffix = ou=group ldap admin dn = uid=admin,ou=people,dc=rootkit,dc=nl

The option passdb defines which backend is being used, to store passwords. Since we want to use LDAP, we use the ldapsam option. Required attributes: Samba3 (sambaSamAccount): uid sambaSID

Integration: Dovecot POP/IMAP and LDAP

Example snippet from Dovecot configuration file:
auth default { mechanisms = plain passdb ldap { args = /etc/dovecot/dovecot-ldap.conf } userdb ldap { args = /etc/dovecot/dovecot-ldap.conf } }

The file /etc/dovecot/dovecot-ldap.conf contains the LDAP specific settings (base, scope, filter string).

Integration: Pure-FTPd and LDAP

Pure-FTPd uses the default 'posixAccount' object class, which is included in the nis schema.

Integration: CUPS printing and LDAP

Steps:

PAM with ldap support (pam_ldap) Configure PAM to support LDAP lookups (/etc/pam.d) Edit /etc/ldap.conf to match your LDAP settings

Some of the available LDAP options within cupsd.conf:

BrowseLDAPBindDN admin BrowseLDAPDN foobar BrowseLDAPPassword mypass BrowseLDAPServer localhost BrowseLocalProtocols ldap BrowseRemoteProtocols ldap

Integration: Kerberos and LDAP

When combining LDAP with Kerberos a single sign-on solution can be created, for example to allow cross platform authentication, but also for usage with different applications. Create SSL certificate for LDAP servers:
kadmin > addprinc -randkey ldap/HOSTNAME > ktadd -k /etc/openldap/ldap.keytab ldap/HOSTNAME $ chgrp ldap /etc/openldap/ldap.keytab; chmod 640 /etc/openldap/ldap.keytab $

KRB5_KTNAME=/etc/openldap/ldap.keytab /usr/sbin/slapd -u ldap -h "ldap:/// ldaps:///"

Integration: Active Directory and OpenLDAP

Integrating Microsoft Active Directory with Unix can be done in different ways, varying in software being used:

Import schema into Active Directory to support additional Unix related fields Talk with Winbind (Samba) to Active Directory (domain controller) Use OpenLDAP's proxy mechanism

When using OpenLDAP together with Active Directory (for example when proxying), the base option in slapd.conf should be set to: cn=Users,dc=rootkit,dc=nl or cn=Users,dc=MyDomain,dc=rootkit,dc=nl.
nss_base_passwd cn=Users,dc=rootkit,dc=nl?sub nss_base_shadow cn=Users,dc=rootkit,dc=nl?sub nss_base_group cn=Users,dc=rootkit,dc=nl?sub nss_map_objectclass posixAccount user nss_map_objectclass shadowAccount user nss_map_attribute uid sAMAccountName nss_map_attribute uidNumber msSFU30UidNumber nss_map_attribute gidNumber msSFU30GidNumber nss_map_attribute loginShell msSFU30LoginShell nss_map_attribute gecos name nss_map_attribute userPassword msSFU30Password nss_map_attribute homeDirectory msSFU30HomeDirectory nss_map_objectclass posixGroup Group nss_map_attribute uniqueMember msSFU30PosixMember nss_map_attribute cn cn pam_login_attribute sAMAccountName pam_filter objectclass=user pam_member_attribute msSFU30PosixMember pam_groupdn cn=unixusergroup,dc=rootkit,dc=nl pam_password ad

Integration notes: - Active directory users are in the form of "CN=Administrator,CN=Users,DC=ad,DC=rootkit,DC=nl".

Migration: NIS to LDAP

NIS uses maps to combine all information for users, groups and authentication. By using the command ypwhich -m we can see which maps are present, together with the master server. This information helps when planning a migration to LDAP. Map files generally are located within /etc/yp or /var/yp. Migration Using migration tools is the recommended way of migrating NIS information to LDAP. The tools have builtin checks (to test for issues like double user ids) and convert information where needed (like shadow files). In case an user is migrated by hand, make sure the password hash type is available in the userPassword field. NIS to LDAP gateway When migrating from NIS to LDAP, it can be useful to have a temporary gateway. This way new or migrated clients can already talk to the LDAP service directly, while older clients use NIS. Another option is a NIS gateway, which uses NIS on the front (client to NIS gateway) and LDAP in the back (NIS gateway to LDAP server). Some tools:

Penrose Sun's Network Information Service (NIS) to LDAP transition service (N2L service) ypldapd (from PADL) YPTransitd

Replication
Replication is the process of syncing data between two or more nodes. In this process there is often one master and multiple slave nodes, where the master is leading. The master will operate as a replication hub, a central point which pushes data to all slaves, or where all slaves connect to for data updates. Slurpd Note: Slurpd replication was removed since OpenLDAP 2.4, but still an exam requisite. Slurpd is a daemon to keep master and slaves in sync. When data is changed on the master, slurpd will replicate data to the slaves, on a regular period. This replication is done by using a replication log (defined by the replog option in slapd.conf), with the change(s) and synced to the slaves. The format of the log is a variant to the LDIF format, with having extra command and information lines in it. When a client tries to perform a change on a slave, the slave server will send a referral back to the client instructing it to go to the appropriate master server. This way the master server also serves as a replication hub, a central point to store data and serve it to the slave server(s) connected to it. Slurpd has also an option called one-shot mode (with parameter -o). It will do the replication between the master and slaves, and exit directly. Disadvantages of Slurpd: - Only push-mode: pushing data from master node to slaves Setting up

Master:

Add directive: replica Add directive: replogfile

Slave: Same configuration as master, except:

Do NOT use directives replica and replogfile Add updatedn (which should be the same value as binddn on the master) Make sure the DN has enough rights to write data

When everything is configured, restart the master LDAP server (tip: running it in read-only mode is a good thing, to make sure changes are not propagated to the master instead). Syncrepl The LDAP Sync replicator works on a client-server based model. A consumer (client) can maintain a (partial) shadow copy of a DIT, which is provided by a provider (server). Syncrepl is able to sync from zero to a full replicate, or from a out of date copy to fully updated, by using incremental updates. The replication can be done in two ways: - refreshOnly The provider uses a pull-based method, by using the replication request information from the consumer. The provider does not maintain a "notify" list of the consumers, when new data is available. - refreshAndPersist The provider uses a push-based method, and keeps track of the consumers which need to be notified when new data is available. Replication works best when using the back-bdb or back-hdb backend. Advantages of Syncrepl: - Can sync full or partial data sets

Performance testing
Tests Disk

Firewall

- Create a big file with dd to see read/write speed - Test output of iostat under low/high utilization, to see CPU block on IO requests - Create benchmark with bonnie++ - Stress test LDAP or other services and measure especially CPU load and memory increase

Network LDAP daemon

- Test transfer rate on private network segment, by FTP/SCP files - Test number of concurrent requests - Test answering time of incoming requests

Tuning and monitoring

While maintaining a running OpenLDAP server, it's important to monitor several components of the system, like CPU usage, memory and disk utilization. This helps in troubleshooting capacity problems, but also planning and extending capacity demands. Some parts to measure are: - Normal amount of requests (per day/hour for trend analysis) - Peek times requests, server load Monitoring can be best configured while setting up OpenLDAP, so an initial base line is available. While finishing the installation/configuration, the impact of ie. data imports can be made visible directly. Also test results (and monitoring) can be tested without problems when no users are active yet. Later on, when everything is in production, trends can be followed (like average increase of users, data traffic usage, peek times). Another reason to start monitoring from the beginning, is to predict the growth rate of the application(s) and to be ahead with monitoring data before problems occur. When they do occur, you can very quickly compare memory usage, CPU load, network traffic and more, with the base line created early. With some stress testing tools, it's also possible to predict the borders of what your machine can handle and what not. In many cases you quickly can identify the bottlenecks of the system at stress tests, by keeping an eye on most common factors. If for example CPU load rises to a high value, but memory usage stays low, you can conclude that optimizing the processing speed of requests is more important instead of adding extra memory banks. Using monitoring and testing tools, a performance equation can be made, to test what impact small adjustments have on the system (and speed, responsiveness etc). This can be adjustments related system tweaking/tuning, but also things which influent the system in a "negative" way, like adding an IP chains packet filter (adding a packet filter is good, but it will come as usual at a cost, as in extra delay to fulfill a request). Most of the monitoring will be performed at connection side of the server. However, don't forget to do some testing at the clients like response time of small and big request results. Pretty Damn Quick One of the capacity planning tools which you can use, is mentioned in the exam objectives, named PDQ (Pretty Damn Quick). See Performance Dynamics Company website. Monitoring tools CPU usage Disk utilization iostat, mpstat, w, uptime iostat, lsof, vmstat (-d)

Memory usage Network usage Swap file usage

top, vmstat, cat /proc/mem ifstat swapon -s

Another nice tool to mention is sar, which can collect system information. If you want to test memory at full potential, make sure to disable swap (with swapoff). Swapping itself means more disk writes/reads and can be a big influence on system performance and the testing results. Monitoring LDAP OpenLDAP has special database backend to monitor the system, called "monitor". To enable this, perform the following steps: - Load module (moduleload back_monitor) - Create database section (database monitor) with ACL
access to * by dn="cn=Admin,dc=rootkit,dc=nl" read by * none

# ldapsearch -x -D 'cn=Admin,dc=rootkit,dc=nl' -W -b 'cn=Monitor' -s base '(objectClass=*)' '*' '+' Search result should give something like:
<output omitted> # Write, Waiters, Monitor dn: cn=Write,cn=Waiters,cn=Monitor objectClass: monitorCounterObject cn: Write # search result search: 2 result: 0 Success # numResponses: 59 # numEntries: 58

The monitoring capabilities are extensive and can give much (detailed) information. A small example to see which backends are supported:
# ldapsearch -x -D 'cn=Admin,dc=rootkit,dc=nl' -W -b 'cn=Backends,cn=Monitor' -s base '(objectClass=*)' '+' '*' Enter LDAP Password: # extended LDIF # # LDAPv3 # base <cn=Backends,cn=Monitor> with scope baseObject # filter: (objectClass=*) # requesting: + * # # Backends, Monitor dn: cn=Backends,cn=Monitor objectClass: monitorContainer structuralObjectClass: monitorContainer cn: Backends creatorsName: modifiersName: createTimestamp: 20080427090213Z modifyTimestamp: 20080427090213Z description: This subsystem contains information about available backends. monitoredInfo: config

monitoredInfo: ldif monitoredInfo: hdb monitoredInfo: monitor entryDN: cn=Backends,cn=Monitor subschemaSubentry: cn=Subschema hasSubordinates: TRUE # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1

Debugging: Logging
OpenLDAP logs to syslog via the LOCAL4 level. With the option loglevel in slapd.conf we can increase or decrease the amount of logging. The option loglevel understands decimal, hexdecimal, or names as parameter. Example:
loglevel 16384 (alias of sync, replication traffic) loglevel acl sync (multiple names)

When using a loglevel of -1, it will enable all debugging information. By default a loglevel of 256 is used.
Create an empty log file: # touch /var/log/ldap.log Edit /etc/syslog.conf: local4.* /var/log/ldap.log Inform syslogd about the changes: # killall -HUP syslogd

Security: SASL
SASL stands for Simple Authentication and Security Layer, an additional security layer which gives servers and clients the option to discuss which (most secure) authentication they both have. Steps: 1. Client initiates session to server 2. Server acknowledges connection and sends back which authentication methods are accepted 3. Client picks the preferred method from the list and confirms the chosen option Cyrus Make sure it has support for Kerberos V (and GSSAPI, the API used by the tools to talk). Database: /etc/sasldb2.db Managing users:

Enable/create account: saslpasswd2 -c -u DOMAIN USERID Disable/delete account: saslpasswd2 -d -u DOMAIN USERID Show users: To view a SASL database, we can use the sasldblistusers2 tool (in package sasl2-bin). Example:
# sasldblistusers2 user1@test: userPassword

With testsaslauthd a newly created account can be tested. Example:

# /usr/local/sbin/testsaslauthd -u user1 -p user1 0: OK "Success."

Security: Proxy Authorization

SASL offers the option for authorization proxying, to allow an intermediate user between the end user and the LDAP server. This intermediate user will make requests on behalf of the end user. An example is when using a web interface, where an user can change his/her password. The web application connects with a dedicated user name (ie. cn=webproxy,dc=rootkit,dc=nl), but is via ACLs allowed to make changes for another user. The LDAP server will think it's the end user itself, who is performing the requests. To make proxy authorization work, the LDAP administrator can add the following attributes to LDAP entries:
dn: cn=webproxy,dc=rootkit,dc=nl authzTo: ldap:///dc=rootkit,dc=nl??sub?(objectclass=person)

This example gives the DN 'cn=webproxy,dc=rootkit,dc=nl' the permission to work on behalf of all entities with the objectclass 'person'. Another option is to use the authzFrom.

Security: Authentication methods

When a client connects to a server, it can do this on two different ways: simple method (with -x) or SASL method.

anonymous: no username or password. Anonymous connections are allowed by default, but can be disabled with the option disallow bind_anon. unauthenticated: a username name is provided, but no password. By default these kind of connections are disabled, but can be enabled with "allow bind_anon_cred" user/password authenticated: a username and password is provided.

Simple binds can be completely disabled with disallow bind_simple, to increase security when for example SASL is being used..

Security: Client/Server certificates

Client certificates: On the LDAP server side we can ask a client to use (or even force) an client certificate. This can be achieved with the TLSVerifyClient option. TLSVerifyClient { never | allow | try | demand }

Never: the server will not ask for a certificate Allow: ask the client for a certificate. If a valid one is provided, use it. If the certificate is invalid, ignore it. Try: same as Allow. However if the certifcate is invalid, inmediately disconnect. Demand: force the client to provide a certificate. If no certificate is given or a certificate is invalid, the connection will be disconnected.

Server certificates: TLS_REQCERT { never | allow | try | demand } This option works the same as TLSVerifyClient, except that it checks the certificate from the server instead. /etc/ldap.conf: TLS_CACERT /usr/share/ssl/certs/ca.cert

Security: Hardening LDAP servers

Disallow anonymous binds:
Add disallow bind_anon to slapd.conf

Firewalling with iptables: When using a local LDAP server, iptables should allow local traffic:
-A INPUT -i lo -j ACCEPT

When using traffic from the (inter)network, allow incoming traffic (these rules could be restricted by adding specific networks or interfaces):
# Ports 389 TCP (ldap), 636 TCP(ldaps) -A INPUT -m state --state NEW -p tcp --dport ldap -j ACCEPT -A INPUT -m state --state NEW -p tcp --dport ldaps -j ACCEPT

Security: Access Control Lists

By using the access keyword, access to all or specific DNs can be restricted. This way the LDAP server can be protected against unauthorized data removal, changes and inserts. When users or hosts connect to a LDAP server, they can be a guest (=anonymous) or an authenticated user (=users). If both (anonymous,users) are allowed to connect for example, we can use a wildcard (=*). Another possibility is to compare the DN the users belong to with dn[.<basic-style>]=<regex> (user matches regular expression) or dn.<scope-style>=<DN> (user is within the scope of a DN). A special one is self, which defines that the owner of the entry is the same as the user to authenticate.

Permission Alias none disclose auth compare search read write manage =0 =d =dx =cdx =scdx =rscdx =wrscdx

Gives right to no access information disclosure on error authenticate (bind) permission compare apply search filters read search results modify/rename data

=mwrscdx manage

Security: TLS/SSL
StartTLS TLS is a security enhancement, to allow applications use encrypted conversations, but still allow backwards compatibility. This way programs (and the network traffic) can be hardened, and still operate at common port numbers (389/TCP by default). A simple example to display the use of StartTLS: Client Hello StartTLS --> <---> <-Query --> <-Query results Acknowledge TLS Hello Server

SSL Creating a SSL certificate and implementing it:

/etc/ldap/ssl# openssl req -new -x509 -nodes -keyout /etc/ldap/ssl/server.key -out /etc/ldap/ssl/server.crt Generating a 1024 bit RSA private key ..............++++++ ..........................++++++ writing new private key to '/etc/ldap/ssl/server.key' ----You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. -----

Country Name (2 letter code) [AU]:NL State or Province Name (full name) [Some-State]:My State Locality Name (eg, city) []:My City Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company Organizational Unit Name (eg, section) []: Common Name (eg, YOUR name) []:ldap.rootkit.nl Email Address []:[email protected] /etc/ldap/ssl# openssl genrsa -out /etc/ldap/ssl/ca.key 1024 (Note: Add -des3 to create a CA key WITH password) Generating RSA private key, 1024 bit long modulus ...........++++++ ..............................++++++ e is 65537 (0x10001) /etc/ldap/ssl# openssl rsa -in /etc/ldap/ssl/ca.key -out /etc/ldap/ssl/ca.key writing RSA key /etc/ldap/ssl# openssl req -new -x509 -days 365 -key /etc/ldap/ssl/ca.key -out /etc/ldap/ssl/ca.crt You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----Country Name (2 letter code) [AU]:NL State or Province Name (full name) [Some-State]:My State Locality Name (eg, city) []:My City Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company Organizational Unit Name (eg, section) []: Common Name (eg, YOUR name) []:Michael Boelen Email Address []:[email protected]

Add to slapd.conf:
TLSCertificateFile /etc/ldap/ssl/server.crt TLSCertificateKeyFile /etc/ldap/ssl/server.key TLSCACertificateFile /etc/ldap/ssl/ca.crt

Testing # gnutls-cli --print-cert -p 636 ldap.rootkit.nl (apt-get install gnutls-cli)

Security: Security Strength Factors

Existing ACL's can be hardened by adding Security strength factors (SFF) to them. This defines the strength of the connection/authentication. For example, DES is 56, 3DES is 112, and AES 128, 192, or 256.
access to * by ssf=128 self write by ssf=64 anonymous auth by ssf=64 users read

 Custom tooling: Perl

Perl scripts Writing small scripts to automate repeating tasks, can be easily done in shell or Perl scripts. Since Perl is one of the objectives, will this be discussed further. Installation Option 1: from tar ball
gunzip perl-ldap-0.36.tar.gz tar xfvz perl-ldap-0.36.tar cd perl-ldap-0.36 perl Makefile.PL make make test make install

Option 2: CPAN shell

# perl -MCPAN -e shell (note: when running first time, CPAN will ask for first time settings/preferences) cpan> install Net::LDAP

The CPAN shell will handle dependencies and ask in interactive mode if these have to be installed. Example code:
#!/bin/perl -w # Use LDAP library use Net::LDAP; # Bind DN values (in this case we use RootDN) my $dn = "cn=admin,dc=rootkit,dc=nl"; my $passwd = "test"; # Connect to LDAP server $ldap = Net::LDAP->new('localhost') or die "$@"; # Bind with DN $mesg = $ldap->bind( $dn, password => $passwd, version => 3 ) or die "$@" + $mesg->code; $mesg = $ldap->search( base => "dc=rootkit,dc=nl", filter => "cn=Michael Boelen", ); # Amount of entries returned my $max = $mesg->count; # Show error message if request was not successful if ($mesg->code) { print $mesg->error,"\n"; } for ( my $index = 0; $index < $max; $index++ ) { my $entry = $mesg->entry($index); my $dn = $entry->dn; # Obtain DN for entry @attrs = $entry->attributes; # Obtain attributes for entry foreach my $var (@attrs) { # Get all values for attribute $attr = $entry->get_value( $var, asref => 1 );

if ( defined($attr) ) { foreach my $value ( @$attr ) { print "$var: $value\n"; # Print each value for the attribute. } } } } # The End