LPIC
-
Upload
cedric-leven -
Category
Documents
-
view
24 -
download
1
Transcript of LPIC
-
LPIC-3 (301 exam) book
Michael Boelen - rootkit.nl
[ Security+, Linux+, LPIC-1, LPIC-2, CIW Security Professional, ITIL ]
Usage notes
Last
updated 26 October 2008
Goal Provide a study guide for LPIC-3, 117-301
Audience Network and LDAP administrators, people who want to attain
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 100%
Stage 2: Completing
examples/adding exam questions 45%
Stage 3: Finishing questions/after
care
Stage:
1 2 3
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
# 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# ls -l
-rw-r--r-- 1 root root 245 2008-04-07 23:34 ldap.conf
drwxr-xr-x 2 root root 4096 2008-04-07 23:34 sasl2
drwxr-xr-x 2 root root 4096 2008-04-20 16:10 schema
-rw-r----- 1 root openldap 4746 2008-04-20 16:10 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
# Backend definition
backend
# First database definition & Config directives
database
# Second database definition & Config directives
database
# Other backend, database and config options
-
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 Description
bdb Berkeley DB transactional backend
config Slapd configuration backend
dnssrv DNS SRV backend
hdb Hierarchical variant of bdb backend
ldap Lightweight Directory Access
Protocol (Proxy) backend
ldbm Lightweight DBM backend
ldif Lightweight Data Interchange
Format backend
meta Meta Directory backend
monitor Monitor backend (dynamic, not for
storing normal data)
passwd Provides read-only access to
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# ls -l
-rw-r--r-- 1 root root 2180 2008-04-07 23:34 collective.schema
-rw-r--r-- 1 root root 2084 2008-04-07 23:34 corba.schema
-rw-r--r-- 1 root root 21175 2008-04-07 23:34 core.ldif
-rw-r--r-- 1 root root 20346 2008-04-07 23:34 core.schema
-rw-r--r-- 1 root root 12091 2008-04-07 23:34 cosine.ldif
-rw-r--r-- 1 root root 14030 2008-04-07 23:34 cosine.schema
-rw-r--r-- 1 root root 10476 2008-04-07 23:34 duaconf.schema
-rw-r--r-- 1 root root 3146 2008-04-07 23:34 dyngroup.schema
-rw-r--r-- 1 root root 3573 2008-04-07 23:34 inetorgperson.ldif
-rw-r--r-- 1 root root 6362 2008-04-07 23:34 inetorgperson.schema
-rw-r--r-- 1 root root 3295 2008-04-07 23:34 java.schema
-rw-r--r-- 1 root root 2473 2008-04-07 23:34 misc.schema
-rw-r--r-- 1 root root 5998 2008-04-07 23:34 nadf.schema
-rw-r--r-- 1 root root 6891 2008-04-07 23:34 nis.ldif
-rw-r--r-- 1 root root 7725 2008-04-07 23:34 nis.schema
-
-rw-r--r-- 1 root root 3393 2008-04-07 23:34 openldap.ldif
-rw-r--r-- 1 root root 1602 2008-04-07 23:34 openldap.schema
-rw-r--r-- 1 root root 4678 2008-04-07 23:34 ppolicy.schema
-rw-r--r-- 1 root root 3593 2008-04-07 23:34 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 openldap 2048 2008-04-20 16:10 alock
-rw------- 1 openldap openldap 8192 2008-04-20 16:10 __db.001
-rw------- 1 openldap openldap 2629632 2008-04-20 16:10 __db.002
-rw------- 1 openldap openldap 98304 2008-04-20 16:10 __db.003
-rw------- 1 openldap openldap 565248 2008-04-20 16:10 __db.004
-rw------- 1 openldap openldap 24576 2008-04-20 16:10 __db.005
-rw-r--r-- 1 openldap openldap 96 2008-04-20 16:10 DB_CONFIG
-rw------- 1 openldap openldap 8192 2008-04-20 16:10 dn2id.bdb
-rw------- 1 openldap openldap 32768 2008-04-20 16:10 id2entry.bdb
-rw------- 1 openldap openldap 53766 2008-04-20 16:10 log.0000000001
-rw------- 1 openldap 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 ldaps://ldap.rootkit.nl/
BASE dc=rootkit,dc=nl
TLS_CACERT /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 ldap1.rootkit.nl ldap2.rootkit.nl
base dc=rootkit,dc=nl
ssl start_tls
tls_checkpeer yes
tls_cacertfile /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 -p lac_ldap -t pam-auth
# auth-client-config -p lac_ldap -t pam-password
# auth-client-config -p lac_ldap -t pam-account
# auth-client-config -p lac_ldap -t 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 install apache2
# apt-get install php5
# apt-get install php5-ldap
# a2enmod ldap
# a2enmod 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 ldap://10.1.7.1 ldap://10.1.7.2
LpkUserDN ou=users,dc=example,dc=com
LpkGroupDN ou=groups,dc=example,dc=com
LpkBindDN cn=Manager,dc=example,dc=com
LpkBindPw somepasswordifneeded
LpkServerGroup somegroupname
LpkForceTLS yes
LpkSearchTimelimit 3
LpkBindTimelimit 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 /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /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 - 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++
Firewall - Stress test LDAP or other services and measure especially
CPU load and memory increase
-
Network - Test transfer rate on private network segment, by FTP/SCP
files
LDAP
daemon - 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 iostat, mpstat, w, uptime
Disk utilization iostat, lsof, vmstat (-d)
-
Memory usage top, vmstat, cat /proc/mem
Network usage ifstat
Swap file usage 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:
# 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 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[.]= (user matches regular expression) or 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 Gives right to
none =0 no access
disclose =d information disclosure on error
auth =dx authenticate (bind) permission
compare =cdx compare
search =scdx apply search filters
read =rscdx read search results
write =wrscdx modify/rename data
manage =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 Server
Hello -->
-
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