ution!

..

understanding LDAP and Direct'ones

*
nding Nlicrosoft Direct1ory Sen
3

nding

lmmary

O Solutions Fast Track

equently Asked

ons

52

Chapter 3

Directory Services

Introduction
Directory services form a crucial component for managing and cataloging
objects such as user accounts and profile settings, groups, computers, printers, email, and other network and infrastructure objects. Just as core network services
are a prerequisite for directory services, directory services are a prerequisite (or a
desirable integration point) for other network services such as authentication,
messaging, and groupware services.
This chapter begins with an overview of directory services and Lightweight
Directory Access Protocol (LDAP). The section covers LDAP fundamentals
including Directory Information Tree (DIT) concepts, Distinguished Name (DN)
convention, objectclasses, schema components, and other LDAP concepts. We
also examine LDAP queries and connections.
Following the directory services overview, we explore Microsoft's directory
services solutions. Microsoft's directory services changed considerably from
Windows NT / Exchange 5.5 to Windows 2000. In Windows NT, the Security
Accounts Manager (SAM) stores all user account information, and Exchange 5.5
provides extended contact and messaging information. In Windows 2000, both of
these functions are combined into Active Directory (AD).
The next section examines OpenLDAP, the premier open source directory
server. We examine features of the OpenLDAP suite including server daemons,
client and server utilities, distributed directory services, and data import / export.
Directory services in a small company may consist of a single, non-dedicated
server, whereas directory services in a larger company tend to be distributed,
redundant, and utilized as an integration point for many other network services.
The section entitled "Designing Linux-Based Directory Services" will help you
determine key requirements for your company's directory services and design a
flexible solution that meets the current requirements as well as allowing for
future growth.

Understanding LDAP and Directories

LDAP is a cross-platform protocol that allows for commumcations with a directory server. LDAP is evolved from the Directory Access Protocol (DAP) component of an X.500 system. The primary functions of LDAP include authentication
and query operations with an X.500-style directory. When we discuss LDAP in
this book, we are referring to LDAPv3.

www.syngress.com

Directory Services Chapter 3

Understanding LDAP Terms

We begin our discussion of LDAP with an overview of the terms used to
describe directory structure and directory objects.You need to understand this
fundamental information in order to understand the rest of this chapter. For an
in-depth analysis of LDAP, consult Adam Williams' LDAP and OpenLDAP (on the
Linux platform) presentation at ftp'//kalamazoolinux.org/pub/pdf/ldapv3.pdf.

Understanding Directory Structure

A directory is orgamzed into a hierarchical structure. This structure is called is
called the Directory Information Tree, or DIT. The DIT structure begins with
the base D N (also called suff-~x) and is logically separated by organizational unit
(ou) objects. DITs are typically organized by the type of object contained in each
tree. In some situations, a company's geographical or business unit organization
may affect D IT design.
Figure 3.1 shows a DIT for a typical company, such as Acme Widgets and
Ballystyx. This type of D IT is usually sufficient for most companies.
F i g u r e 3.1 Directory Information T r e e - Simple Model

I
ou=Groups

Figure 3.2 shows a DIT for a company with very clear delineation among
business units. This might be a good way to organize a company where business
units operate as separate "islands", with almost no commumcation or information
sharing between business groups.
F i g u r e 3.2 Directory Information T r e e - Business Group Model

oo=s, ,os

.....................................
I..........i~.......................

53

54

Chapter 3 Directory Services

Figure 3.3 shows a DIT for a very large company with multiple large offices
on multiple continents. In this case, all admimstrative, IT, and business functions
are separated by continents for legal, financial, technical, and other business reasons. Although this type of orgamzation is not applicable to most compames, it
illustrates another type of directory structure and design.

Figure 3.3 Directory Information Tree- Geographical Model

)
,

[' ou=Americas ) [ o u

=AsiaPacific]

( ou =Europe

Each object in the directory is umquely identified by a distinguished name.

The D N is composed of the attribute that umquely identifies that object (usually
common name (cn) or user ID (uid)) followed by the path that locates the object
within the DIT. Figure 3.4 shows two example person objects and a corresponding DN.

Figure 3.4 Directory Information Tree- Distinguished Name

tic=example dC=c0m
....

(._oo:G.roo0,)[
=

[~o: D,vi~ Al,,,.,

1
lobjectClass: person /
po: A,~
/
uid" dallen

'I
i

.....

.....Christian
i Lahti
[cn"
IobjectClass:person
I~: L.hu
[uid: lahti

Idn n=Dav~d A''en'~=us~s'dc=examp'e''~c=cm

Understanding Directory Objects

A directory is a hierarchical store of objects and their attributes. Each object is an
instance of one or more ob]ectclasses. Ob]ectclasses define the collection of
attributes that may or must comprise these types of objects. Attributes may contain text, numeric, binary, or other types of data.

www.syngress.com

Directory Services Chapter 3

The collection of objectclasses supported by a directory server is called the

directory schema. Schema fdes (such as those included with OpenLDAP and
Samba) contain objectclass, attributes, and syntax definitions. Each of these entities is associated with an Object Identifier (OID). OIDs are represented by a
hierarchical dotted-decimal notation, and umquely identify object, attribute, and
syntax defimtions. The following shows the defimtion for the "person" objectclass
in core.schema.
objectclass

( 2.5.6.6

NAME

DESC

'RFC2256:

a person'

SUP
MUST
MAY

top

'person'

STRUCTURAL

( sn

$ cn

( userPassword

$ telephoneNumber

$ seeAlso

$ description

) )

This objectclass definition lists the attributes that must comprise a person
object (common name and surname) and the attributes that may optionally be
present (userPassword, telephoneNumber, seeAlso, and description). The following shows the definition of selected attributes.
attributetype
DESC
SUP

( 2.5.4.3

'RFC2256:
name

attributetype
DESC
SUP

'commonName'

common name(s)

( 2.5.4.4

name

DESC

( 'cn'

for which the e n t i t y

is

known

by'

'RFC2256:

attributetype

NAME

NAME

last

( 'sn'

(family)

'surname'

name(s)

for which the e n t i t y

is k n o w n

by'

( 2.5.4.20

NAME

'telephoneNumber'

' R F C 2 2 5 6 : Telephone Number'

EQUALITY

telephoneNumberMatch

SUBSTR

telephoneNumberSubstringsMatch

SYNTAX

1.3.6.1.4.1.1466'.115.121.1.50{32}

Connecting to a Directory Server

In order to perform operations such as LDAP queries, a client m u s t first connect
to the directory server. In LDAP parlance, this is called a bind operation. There
are four types of bind operations:

55

56

Chapter 3 Directory Services

Anonymous bind

Simple bind

Simple bind with Transport Layer Security (TLS)

Simple bind with Simple Authentication and Security Layer (SASL)

In an anonymous bind, the LDAP client supplies an empty binding D N and

password. In an authenticated bind, the LDAP client supplies the D N of the
directory object to bind as, and provides credentials such as a password. Simple
binds (without encryption) have a disadvantage in that the password is transmitted in clear-text over the network.
In order to protect the password from smflqng, some form of encryption must
be used. Most LDAP implementations support the use of the StartTLS operation,
which encrypts all further communications between the client and the server.
SASL is a more complex form of authentication that supports Kerberos and
Generic Security Services Application Programming Interface (GSSAPI). We will
discuss authentication and encryption in greater detail in Chapter 4. For now the
most important detail to keep in mind is that non-anonymous binds that
transmit clear-text passwords create a security issue.

Understanding LDAP Queries

Following a successful connection to the directory server, the LDAP client will
typically issue a query. An LDAP query is composed of the following parts:

Search Base The search base contains the D N of the portion of directory tree where the search should begin. Typically this is in the form of
dc=domain,dc=com, although older implementations may use o=orga nization,c=country. This is also sometimes called the search sufftx.
Search Scope The search scope may be base, one, or sub. A base
search scope searches only at the search base level. A search scope of one
searches up to one level below the base. The sub search scope will search
through all subtrees below and including the search base.
Search Filter The search fdter specifies which types of objects and
attributes the directory server should return. Search fdters are specified
using regular expression syntax.
Search Attributes The search attributes parameter lists the attributes
to return in the LDAP query. If the search attribute field is not popu-

Directory Services

Chapter 3

lated, all attributes of the object will be returned. To mimmize the performance impact to the directory server, it is considered a best practice
to ask for only the attributes that are needed.
Another way to represent an LDAP search is through the use of a Uniform
Resource Indicator, or U R I . The basic format of an LDAP U R I is as follows:
'idap://' [hostport]
[filter] ]] ] ] ]

['/'

[dn ['?'

[attributes]

['?'

[scope]

['?'

More information about LDAP search filters can be found in R F C 2254,

"The String Representation of LDAP Search Filters)' More information about
LDAP U R I format can be found in R F C 2255, "The LDAP U R L Format."

Understanding
Microsoft Directory Services
Windows N T and Windows 2000 Server employ three directory servers. These
three servers are the N T Security Accounts Manager, Exchange 5.5 Directory
Services, and Windows 2000 Active Directory. We examine these directory
servers below.

Understanding Windows NT SAM

Windows N T makes use of a SAM to store user objects. The Windows N T
SAM is managed by User Manager or third-party utilities and contains only a
limited amount of information compared to other directory services. There is no
LDAP interface to N T SAM.
Windows N T SAM also supports the use of groups, including nested groups.
The SAM splits groups into two types, local and global. Local groups can contain
global groups, but global groups cannot contain local groups.
The Windows N T SAM stores usernames and computer accounts internally
as a Security Identifier (SID). A user account also contains L A N M A N (LAN
Manager) and N T L M (NT LANMAN) password hashes, the full user name,
description, home directory, profile path, logon script, logon times, and account
status.
Windows N T is a single-master directory service. A master (read-write)
directory server is called a Primary Domain Controller (PDC), and a slave (readonly) directory server is called a Backup Domain Controller (BDC). There is

57

58

Chapter 3 Directory Services

only one PDC in a Windows N T domain, but there may be zero or more
BDCs.
Windows N T domains are not hierarchical, but instead depend on trust relationships for interoperation. In this book, we shall consider only a single-domain
model. If you have multiple domains, you may use the single-domain migration
techniques to migrate some or all portions of each domain individually. These
domains may be kept separate or collapsed into a single domain, depending on
your requirements.

Understanding Exchange 5.5 Directory Services

Exchange Server was the first implementation of Microsoft directory services to
feature multi-master replication and LDAP support. The Exchange 5.5 directory
server supports LDAPv3 and a rich set of objects and attributes. Each Exchange
server contains a full copy of the directory. Changes to the Exchange directory
made on one Exchange server propagate to all other Exchange servers within the
Exchange orgamzation.
Exchange supports the use of groups to create mailing lists. In Exchange 5.5,
these groups are called Distribution Lists. However, these groups are not the same
as N T SAM groups and are not interchangeable. Part of the advantage of Active
Directory over the Exchange 5.5 directory is that AD groups may be used for
both e-mail and access control.
Exchange 5.5 supports the concept of external recipients. The recipients are
called Custom Recipients, and are generally accessible to all persons using the
Exchange directory. They are similar to contacts in Outlook and other e-mail
clients, but exist in the directory instead of on the local mail client.
Exchange 5.5 links N T SAM user objects to Exchange user mailboxes via
the Primary Windows N T Account (Assoc-NT-Account) field. In Exchange
Administrator, this field shows up as a Windows N T account, although it is acreally stored as a SID in the Exchange directory.
The Exchange directory is a precursor to Active Directory, and contains a
subset of Active Directory features and functionality.

Understanding Active Directory

Active Directory is Microsoft's Windows 2000 implementation of directory services. Active Directory is used as the directory server for Microsoft enterprise
domain implementations, and forms a core requirement for many of Microsoft's

www.syngress.com

Directory Services Chapter 3

products, including Exchange Server. Active Directory runs only on Windows

servers.

Active Directory implements an LDAP interface, although Active Directory

Services Interface (ADSI) is the most widely used method to access Active
Directory objects. Active Directory is tightly integrated with Microsoft's
Windows 2000 DNS (Domain Name System) and D H C P (Dynamic Host
Control Protocol) implementation, and requires DNS services in order to function properly.
While Active Directory performs similar basic functions to the N T Domain
model, there are a number of differences between these two directory services.
Table 3.1 summarizes these differences.

Table 3.1 Differences Between Windows NT Domains and Active Directory

Domains
,,

Active Directory Domains

,,,

Windows NT Domains

,,,,,

DNS-integrated.
Hierarchical, transitive trust model.

No DNS integration.
Island model with various types of trust

relationships.
Store credentials for Kerberos and
NT/LANMAN authentication.

Stores credentials for NT/LANMAN

authentication. No Kerberos

capabilities.
Stores extensive user contact
information.
Multi-master replication model.

Stores very limited user contact

information.

Single-master replication model.

,,,

Active Directory stores a considerable amount of information, and is a

superset of the N T SAM and Exchange 5.5 directory. Username, full name,
description, password hashes, home directory, profile path, contact information, email address(es), and other information are stored in Active Directory. More
information about Active Directory is available at: www.microsoft.com/
windows2000/technologies/directory/

Understanding OpenLDAP
OpenLDAP is the premier open source directory solution. It contains a full suite
of client and server components necessary to implement and utilize directory
services. OpenLDAP runs on all versions of Linux and features robust replication

59

60

Chapter 3 Directory Services

support for distributed directory services. OpenLDAP is a mature product. It was

originally developed by the University of Michigan, but is now managed by the
OpenLDAP Foundation. More information about OpenLDAP is available at
www.openldap.org.

Understanding OpenLDAP Server Daemons

Slapd (Stand-alone LDAP Daemon) is the OpenLDAP server process that listens
on network ports and responds to LDAP connections from clients. Slapd is managed through the use of the slapd.conf file, usually found in/etc/openldap or
/etc/ldap.
Slurpd (Stand-alone Update Replication Daemon) enables distributed directory services by providing replication capabilities. Slurpd is capable of masterslave (single-master) or master-master (multi-master) models of replication.
Master-slave replication works by maintaimng a single read-write copy (the
master) of the directory, and replicating the directory to one or more read-only
copies (the slaves). Single-master replication is the least complicated replication
method to use, and is the method used by most orgamzations. Slurpd uses a push
style of replication, meamng that the master imtiates connections to the other
servers and pushes updates to them.
Multi-master replication works by allowing multiple directory servers to
write to the directory. When a change occurs, the directory server processing the
write operation sends an update to the other directory servers.

Understanding OpenLDAP Utilities

The OpenLDAP suite features a number of client utilities and libraries. Table 3.2
lists commonly used OpenLDAP utilities.

Table 3.2 Commonly-Used OpenLDAP Utilities

OpenLDAP Utility Name

Description

Idapsearch
Idapadd
Idapmodify
Idapdelete
Idappasswd
slappasswd

Queries a directory server

Adds a directory object
Modifies a directory object
Deletes a directory object
Changes the password of a directory object
Generates encrypted passwords
Continued

www.syngress.com

Directory Services Chapter 3

Table 3.2 Commonly-Used OpenLDAP Utilities
OpenLDAP Utility Name

Description

slapcat
slapadd

Writes contents of directory to LDIF file

Adds contents of a directory from LDIF file generated by slapcat
Regenerates slapd indices

slapindex
,,,

In order to maintain database consistency, slapd should be shut down (or runrang in read-only mode) when performing a slapcat or slapindex operation.
Slapd should also be shut down during a slapadd operation. In most cases, an
LDIF fde is specified for input when executing ldapadd, ldapmodify, or
ldapdelete, especially if multiple objects are to be affected. More information
about OpenLDAP utilities may be obtained by typing m a n utilityname.

Designing
Linux-Based Directory Services
With an understanding of directory services, LDAP, and OpenLDAP, you are
ready to design and deploy your Linux-based directory services. The following
sections will help you determine the best way to meet your orgamzation's directory services requirements.

Designing a Directory Information Tree

The first step in directory services design is determimng the structure of your
orgamzation's DIT. This process starts with determimng your base DN. For a
company with a .com Internet domain name, this usually means using dc=yourdomain,dc=com as the base DN. For a company without an Internet domain
name, you may consider using dc=companyname,dc=local.
After determimng your base DN, you must determine how to logically separate your directory hierarchy into orgamzational umts. For the vast majority of
compames, only four orgamzational umts are needed. Figure 3.5 illustrates the
recommend DIT structure.

61

62

Chapter 3 Directory Services

Figure 3.5 Recommended Directory Information Tree Structure

1 ...............

.....

(o0oG 00 , ?

fo0o=00,,4 {o0=o

One of the advantages of this D IT structure is that it seamlessly allows you to

use the Webmin www.webmin.com modules created by IDEALX for LDAP
admimstration of Samba and Posix accounts. Using the idxldapaccounts modules
is a recommended way for managing your directory. Information and downloads
are available at www.idealx.org/prj/webmin/index.en.html.
If your orgamzation is large and there is negligible commumcation and/or
resource sharing between business umts and/or office locations, you may consider a more complex DIT structure. However, in most cases it is best to use the
recommended DIT, adding additional top-level orgamzational units as needed.

Designing the OpenkDAP Infrastructure

N o w that you have determined the structure of your DIT, you must determine
the type, placement, and number of OpenLDAP servers in your orgamzation. For
a very small company like Acme Widgets with few employees and only one
server, the choice is simple: Acme Widgets installs OpenLDAP on the only available server.
For a company like Ballystyx with many employees, multiple sites, and five
servers, more options are available. The following criteria help to shape the decision-making process in medium- and large-sized orgamzations:
n

Bandwidth usage and availability

Server availability and scalability

Directory service usage patterns including:

[]

Usage patterns of end-user clients (such as e-mail address lookups)

www.syngress.com

Directory Services

Chapter 3

Usage patterns of server clients (such as authentication and messaging)

Usage patterns at each site, and number of sites requiring directory

service

Frequency and type of directory read and write operations

Directory replication and disaster recovery considerations

Security and legal considerations

Support personnel availability

Given these considerations, the directory services infrastructure design that

makes the most sense for BaUystyx is to use single-master replication with the
master OpenLDAP server located in Silicon Valley and a slave OpenLDAP server
located in the Bangalore office. Figure 3.6 illustrates this arrangement.

Figure 3.6 BallystyxEngineeringDirectoryServices

Boron

Nitrogen
Repllcdon

OpenLDAP
Master

OpenLDAP
Slave

(i!

m ,]

63

64

Chapter 3 Directory Services

Configuring and
Testing the OpenLDAP Server(s)
With the type and placement of your server(s) determined, you are ready to test
directory services in the lab. Compile and install the current OpenLDAP package
or install the current OpenLDAP package from your distribution on a test lab
server. Depending on which features of OpenLDAP you wish to use, you may
need to supply switches to ./configure to enable specific compile-time options.
If you are installing an OpenLDAP package from a distribution, there may be
multiple similarly named versions compiled with different options. For basic
unencrypted directory services, the default options should work well. If you need
additional features, you may recompile or upgrade the OpenLDAP software at a
later time. More information about building and installing OpenLDAP is available at ww.openldap.org/doc/admin22/install.html.
After you install OpenLDAP, you must customize the OpenLDAP server
configuration file, slapd.conf, to reflect your environment. The following illustrates the sladp.conf fde for Acme Widgets.

Directory Services Chapter 3

# Schema

~les

include

/ etc / o p e n l d a p / schema/core, schema

include

/ etc / o p e n l d a p / s c h e m a / c o s ine. schema

include

/ etc / o p e n l d a p / s c h e m a / i n e t o r g p e r s o n , schema

include

/ etc / o p e n l d a p / schema/nis, schema

include

/ etc / o p e n l d a p / schema/samba, schema

schemacheck

on

lastmod

on

# This

section

database
suffix

deflnes the a c m e w i d g e t s . c o m

directory

database

bdb
"dc=acmewidgets,dc=com"

rootdn

"cn=Manager,dc=acmewidgets,dc=com"

rootpw

"secret"

directory

# These

/var/lib/Idap

database

indices

improve

performance
eq

index

objectClass, uidNumber, g i d N u m b e r

index

cn, sn, uid, d i s p l a y N a m e

pres, sub, eq

index

mail, givenname, m e m b e r U i d

eq, subini tial

index

sambaSID, s a m b a P r i m a r y G r o u p S I D , s a m b a D o m a i n N a m e

# Access
access

Control

to a t t r s = u s e r P a s s w o r d , s a m b a N T P a s s w o r d , s a m b a L M P a s s w o r d
by

self w r i t e

by a n o n y m o u s
by
# all
access

eq

others
to
by

auth

* none
attributes

are

readable

to e v e r y b o d y

*
* read

N o t e the included schema definitions. In m a n y cases y o u must copy

samba.schema from the Samba package. These schemas are required to provide
the following objectclasses that will be used for the migration:

65

66

Chapter 3 Directory Services

top

posixAccount

shadowAccount

sambaAccount

[]

sambaSAMAccount

m sambaDomain

person

m orgamzationalPerson

inetOrgPerson

m posixGroup

sambaGroupMapping

W h e n you have properly set up slapd.conf, start the OpenLDAP server and
perform a simple bind operation using the rootdn credentials
(cn=Manager, dc=yourdomain,dc=com). Although there will be no visible data
other than the schema information, you have verified that you are able to properly connect to the directory server.You are now ready to populate the directory
with your data.

www.syngress.com
I~

~.~

Directory Services

Chapter 3

Summary
Directory services enable the hierarchical storage and centralized management of
information about users, groups, computers, and other network and infrastructure
items. Since directory services are a prerequisite (or a desirable integration point)
for the other network services mentioned in this book, deploying your Linuxbased directory services represents the establishment of a significant foundation
for the network services in the following chapters.
in the next chapter you will be introduced to Samba, which will integrate with
your OpenLDAP directory to allow for authentication. We will also examine the
migration of NT, Exchange 5.5, and/or Active Directory information.

Solutions Fast Track

Understanding LDAP and Directories
A directory is a hierarchical store of objects and their attributes.
LightweightDirectory Access Protocol (LDAP) allows for authentication
and query operatiom with a directory server.
The hierarchical structure of a directory is called a Directory
Information Tree, or DIT. The DIT begins with a base DN, or directory
sufftx, such as dc=example, dc=com. Organization unit (ou) objects are
used to create the tree-l~e hierarchical structure. Directories trees are
usually organized by object type, buy may also be organized by
geography or business unit structure.
ga The schema defines the objectclasses and attributes supported by a
directory. An objectclass definition lists the attributes that must or may
comprise an object of that type. Objectclasses and attributes are
referenced by a unique Object Identifier (OID).
Prior to performing a query, an LDAP client binds with the directory
server. Binding may be anonymous or authenticated.

-,'~7"',,: ~'

- ~'~ -', --,-~

:: :=:
......~':~
~~~
~'i:~:~:

:';~

LDAP queries are composed of a search base, scope, filter, and/or

attribute list.An LDAP query may be defined by command-line arguments or represented by a Uniform Resource Indicator (UR.I) More
information about LDAP search filters and URls can be found in ILFCs
2254 and 2255.

Understanding Microsoft Directory Services

In Windows N T and Windows 2000 server there are three types of
directory services: N T Security Accounts Manager (SAM), Exchange
5.5 directory services, and Active Directory.
ga The Windows N T SAM is a very simple directory service that stores
information about user accounts, computer accounts, and groups.
Windows N T domains contain a Primary Domain Controller (PDC)
and zero or more Backup Domain Controllers (BDCs). N T domains
utilize single-master replication with the PDC having a read-write copy
of the directory and BDC(s) having a read-only copy.

...

~_~,.

L ' ; i:-

~-

'

- "

-,,. ~

':,~..'-

..

~/I The Exchange 5.5 directory features multi-master replication and LDAP
support, and contains a rich set of objects and attributes. The Exchange
directory supports user mailboxes, groups (for mailing lists), and custom
recipients. User mailboxes are linked to the N T SAM through the use
of a P r i m a r y W'mdows N T A c c o u n t field.
I/] Active Directory is Microso~'s Windows 2000 implementation of enter-~
prise directory services. Active Directory contains a superset of the
information in the N T SAM and Exchange 5.5 directories. More informarion about Active Directory is avaihble at www.microsoft.com/windows2000/technologies/directory/.

Understanding OpenLDAP
OpenLDAP is the premier open source directory solution. It contains a
fixU-feamred suite of client and server components necessary to implement and utilize directory services.

I~ Shpd (Stand-alone LDAP daemon) is the OpenLDAP server process

that responds to LDAP connectiom from clients. Slurpd (Stand-alone

Directory Services Chapter 3

Update Replication daemon) enables OpenLDAP distributed directory

services by providing replication capabilities.
[/I The OpenLDAP suite contains a number of utilities, including
OpenLDAP Idapsearch, ldapadd, ldapmodify, ldapdelete, ldappasswd, slappasswd, slapcat, slapadd, and slapindex. More information about
OpenLDAP utilities may be obtained by typing m a n utilitTname.

Designing Linux-Based Directory Services

l~ The ftrst step in designing Limtx-based directory services is determining
the structure of you organization's DIT and determining the base DN
(directory SUffLX).For a company with a .corn internet domain name,
this usually means using dc=yourdomain,dc=com.
The next step is to determine the type, placement, and number of
OpenLDAP servers in the organization. Bandwidth, server
availability/scalability, directory usage patterns, replication, disaster
recovery, security, and support considerations shape this decision-making
process.

The final step prior to deployment is to install, configure, and test directory services in the lab. Customize slapd.conf to include the schema
files, base DN, database configuration, and access controls appropriate for
your organization.

~ Chapter 3 Directory Services

Frequently Asked Questions

The following. Frequently Asked Questions, answered by the authors of this book,
are designed to both measure your understanding of the concepts presented in
this chapter and to assist you with real-life implementation of these concepts. To
have your questions about this chapter answered by the author, browse to
www.syngress.com/solutions and click on the "Ask the Author" form. You will
also gain access to thousands of other FAQs at ITFAQnet.com.

Q: Is there

an easy way to back up or restore the contents of an OpenLDAP

directory?

A: The use of slapcat and slapadd is recommended for these purposes. Do not
attempt to copy the database ftle of a live database that is performing write
operations - the database may be in an inconsistent state and cause a restore
operation to fail.

Q: Why is the Windows SAM considered to be a directory server?

A: Although the
500-style directory and lacks an
LDAP inteffac
objects. For ~

Q: Are

one, two,
What is the b,
tlenecks?

nechanism for users and group

other Microsoft directory servers.
e ~ , m y
organization?
"
at are the typical bot-

A: In an organization with well-designed dis

ory services, there is

usually one read-write (master) OpenLDAP s ' ~ ~
headquarters, and a
read-only server at each branch of[ice, if certain apl~t,ttons (such as postfix
or Samba servers) perform a significant amount of directory lookups, a dedicated OpenLDAP server (read-only) may be deployed for these applications.

Q: Is there a simple way to redirect clients to another directory server i one

fails?

A: Using round-robin DNS is a best-practices methodology to enable load balancing, redundant, and highly available directory services.