Ldap Programming Management And Integration 1st

Edition Clayton Donley download

https://ebookbell.com/product/ldap-programming-management-and-
integration-1st-edition-clayton-donley-975188

Explore and download more ebooks at ebookbell.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.

Ldap Directories Explained An Introduction And Analysis 6th Printing

Arkills

https://ebookbell.com/product/ldap-directories-explained-an-
introduction-and-analysis-6th-printing-arkills-21354964

Ldap System Administration 1st Edition Gerald Carter

https://ebookbell.com/product/ldap-system-administration-1st-edition-
gerald-carter-1939174

Ldap In The Solaris Operating Environment Deploying Secure Directory

Services Michael Haines

https://ebookbell.com/product/ldap-in-the-solaris-operating-
environment-deploying-secure-directory-services-michael-haines-922834

Understanding Ldap Design And Implementation Ibm Redbooks

https://ebookbell.com/product/understanding-ldap-design-and-
implementation-ibm-redbooks-2620322
Practical Spring Ldap Using Enterprise Javabased Ldap In Spring Data
And Spring Framework 6 2nd Edition Varanasi Balaji

https://ebookbell.com/product/practical-spring-ldap-using-enterprise-
javabased-ldap-in-spring-data-and-spring-framework-6-2nd-edition-
varanasi-balaji-54527848

Solaris And Ldap Naming Services Deploying Ldap In The Enterprise Tom
Bialaski Michael Haines

https://ebookbell.com/product/solaris-and-ldap-naming-services-
deploying-ldap-in-the-enterprise-tom-bialaski-michael-haines-4126172

Practical Spring Ldap Enterprise Java Ldap Development Made Easy 1st
Edition Balaji Varanasi

https://ebookbell.com/product/practical-spring-ldap-enterprise-java-
ldap-development-made-easy-1st-edition-balaji-varanasi-4568498

Understanding And Deploying Ldap Directory Services 2nd Edition

Timothy A Howes

https://ebookbell.com/product/understanding-and-deploying-ldap-
directory-services-2nd-edition-timothy-a-howes-923744

The Abcs Of Ldap How To Install Run And Administer Ldap Services 1st
Edition Reinhard E Voglmaier

https://ebookbell.com/product/the-abcs-of-ldap-how-to-install-run-and-
administer-ldap-services-1st-edition-reinhard-e-voglmaier-983832
LDAP Programming, Management
and Integration
LDAP Programming,
Management and
Integration

CLAYTON DONLEY

MANNING
Greenwich
(74° w. long.)
For online information and ordering of this and other Manning books,
go to www.manning.com. The publisher offers discounts on this book
when ordered in quantity. For more information, please contact:
Special Sales Department
Manning Publications Co.
209 Bruce Park Avenue Fax: (203) 661-9018
Greenwich, CT 06830 email: [email protected]

©2003 by Manning Publications Co. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted,

in any form or by means electronic, mechanical, photocopying, or otherwise, without prior
written permission of the publisher.

Many of the designations used by manufacturers and sellers to distinguish their products are
claimed as trademarks. Where those designations appear in the book, and Manning
Publications was aware of a trademark claim, the designations have been printed in initial
caps or all caps.

Recognizing the importance of preserving what has been written, it is Manning’s policy to have the
books we publish printed on acid-free paper, and we exert our best efforts to that end.

Manning Publications Co. Copyeditor: Tiffany Taylor

209 Bruce Park Avenue Typesetter: Dottie Marsico
Greenwich, CT 06830 Cover designer: Leslie Haimes

ISBN 1-930110-40-5
Printed in the United States of America
1 2 3 4 5 6 7 8 9 10 – VHG – 06 05 04 03
contents
preface xi
acknowledgments xv
about this book xvi
getting started xix
about the cover illustration xxii

Part 1 Fundamental LDAP concepts 1

1 Introduction to LDAP 3
1.1 What LDAP is 4
Directory services and directory servers 4 ✦ LDAP and directory
services 4 ✦ Other directory services 5
1.2 What LDAP is not 7
LDAP is not a relational database 7 ✦ LDAP is not a file system for
very large objects 7 ✦ LDAP is not optimal for very dynamic objects 9
LDAP is not useful without applications 9
1.3 Current applications 10
White pages 10 ✦ Authentication and authorization 12
Personalization 13 ✦ Roaming profiles 14 ✦ Public Key
Infrastructure 14 ✦ Message delivery 15
1.4 Brief history 15
X.500 and DAP 15 ✦ A new standard is born 16
LDAP goes solo 17 ✦ LDAPv3 18
1.5 LDAP revisions and other standards 18
Replication and access control 19 ✦ Directory Enabled
Networking 21 ✦ XML and directories 22
1.6 Directory management 23
1.7 Directory integration 24
Integration via metadirectories 27

v
 1.8 Integration and federation via virtual directory technology 30
1.9 Why this book? 31
1.10 Summary 32

2 Understanding the LDAP information model 34

2.1 Information model overview 35
Entries 35 ✦ Attributes 36 ✦ LDAP entries vs. database records 36
2.2 Working with LDAP schema 37
Standard LDAP schema 37
2.3 Attribute types 39
Defining attribute types 39 ✦ Syntax definitions 40 ✦ Matching rules for
attributes 41 ✦ Support for multiple values 43 ✦ Inheritance 44
User modification 45 ✦ Variables in Java, Perl, and C 45
2.4 Object classes 46
Defining object classes 46 ✦ Required and allowed attributes 47
Object class inheritance 47 ✦ Multiple object class memberships 48
Object class types 48 ✦ LDAP object classes and Java or C++ classes 50
2.5 Using object modeling to design LDAP schema 51
Modeling classes 51 ✦ Modeling relationships 51
Modeling object instances 53
2.6 Summary 54

3 Exploring the LDAP namespace 55

3.1 What is a namespace? 56
Hierarchical namespaces 57
3.2 Specifying distinguished names 59
Choosing a relative distinguished name attribute 60
Determining the base 62
3.3 Assigning the root naming context 64
Traditional style of assigning the root name context 64
Domain component style of assigning the root name context 65
3.4 Selecting and designing a directory tree 65
Intranet directories 66 ✦ Internet directories 69 ✦ Extranet directories 71
3.5 Summary 74

4 Search criteria 75
4.1 Performing a search 76
4.2 Where to search: base and scope 76
Search base 76 ✦ Search scope 77

vi CONTENTS
 4.3 What to evaluate: search filters 78
Presence filters 79 ✦ Exact equality filters 80 ✦ Substring matching 81
Ordered matching (greater than/less than) 83 ✦ Approximate filters 84
Multiple filters: AND and OR operators 84 ✦ Negative filters: the NOT
operator 86 ✦ Extensible searching and matching rules 86
4.4 What to return: the attribute return list 87
4.5 LDAP search criteria vs. SQL queries 87
Similarities between SQL SELECT and LDAP search criteria 88
Differences between SQL SELECT and LDAP search criteria 88
4.6 Increasing search performance 88
4.7 Summary 89

5 Exchanging directory information 90

5.1 Representing directory information outside the directory 91
5.2 LDAP Data Interchange Format 92
Expressing entries in basic LDIF 92 ✦ Writing LDAP changes
as LDIF 94 ✦ Representing schemas in LDIF 95 ✦ Advantages
and disadvantages of LDIF 96
5.3 Directory Services Markup Language 96
Why use DSML? 96 ✦ Getting started with DSML 98
A DSML example 98 ✦ Handling binary values in DSML entries 99
Entry changes and DSML 100
5.4 Defining directory schemas with DSML 100
DSML object classes 100 ✦ DSML attribute types 101
5.5 XSLT and DSML 102
Converting DSML to HTML using XSLT 102
5.6 Summary 104

Part 2 LDAP management 105

6 Accessing LDAP directories with Perl 107
6.1 LDAP access from Perl 108
6.2 Getting started with Net::LDAP 109
Using the module 109 ✦ Opening a connection 109
Binding to the directory 110
6.3 Searching with Net::LDAP 111
Performing a search 111 ✦ Understanding search scopes 113
LDAP search filters 115 ✦ Using search results 115 ✦ Limiting
attribute retrieval 115 ✦ Handling referrals 116

CONTENTS vii
 6.4 Manipulating entries 116
Updating an entry 116 ✦ Adding new entries 117
Deleting an entry 117 ✦ Renaming an entry 117
6.5 Comparing entries 118
6.6 Handling errors 119
6.7 Support for encrypted/SSL connections 119
6.8 Summary 120

7 Managing directory entries, groups, and accounts 121

7.1 Common types of managed entries 122
7.2 Entry management models 122
Centralized administration 122 ✦ Distributed administration 124
User self-administration/self-service 125
7.3 Creating people entries 126
People entries via a web form 127 ✦ People entries based on
existing data 130 ✦ Summary of creating entries 134
7.4 Creating and maintaining groups 134
Explicit groups 135 ✦ Dynamic groups and LDAP URLs 136
7.5 Representing and managing account information 136
Unix user accounts 137 ✦ Linking Unix accounts to people 141
7.6 Managing other information 142
Security services information 142 ✦ DNS information 142 ✦ Directory
Enabled Networking information 143 ✦ Card catalog information 143
7.7 Summary 143

8 Synchronizing LDAP information 144

8.1 Approaches to data flow management 145
Replication 145 ✦ File export/import 146 ✦ Scripting 146
8.2 Data flow analysis 146
Schema mapping 147 ✦ Determining the authoritative source 147
Data transformation 148 ✦ Namespace translation 149
8.3 Interchange formats 150
LDAP Data Interchange Format 150
Directory Services Markup Language 151
8.4 Migration to LDAP 152
Migrating a simple table 152 ✦ Migrating from multiple sources 154
Adding new information to existing entries 157
8.5 Joining related information 159
Multikey matches 159 ✦ Fuzzy matching 160

viii CONTENTS
 8.6 Synchronization 162
Synchronization to LDAP 162 ✦ Synchronization from LDAP 163
Bidirectional synchronization 166
8.7 Summary 167

9 Accessing operational information in LDAP 168

9.1 Getting server information 169
Retrieving available root naming contexts 169 ✦ Extracting object class
information 170 ✦ Getting attribute type details 174
9.2 Monitoring with LDAP 178
Getting the monitor’s name 178 ✦ Reading the monitor information 178
Polling the monitor entry 180
9.3 Testing replication 181
9.4 Summary 184

10 DSML: getting under the hood 185

10.1 DSML parsing with SAX 186
Basics of parsing XML with SAX 186 ✦ A simple XML parser handler 186
Parsing a simple document 188 ✦ PerlSAX’s built-in error checking 189
10.2 Parsing DSML into a Perl object 190
Beginnings of a useful DSML parser handler 192 ✦ Handling elements in
the DSML file 193 ✦ Extracting characters between start and end tags 194
Preparing to use DSMLHandler 194 ✦ Invoking the SAX parser using
DSMLHandler 194
10.3 Generating DSML 196
Writing directory entries 196 ✦ Converting RFC-style LDAP schemas to
DSML LDAP schemas 199 ✦ Conversion example for object classes 199
Converting attribute types 204
10.4 Using Perl to convert DSML with XSLT 208
Converting DSML to HTML 209
10.5 Summary 211

Part 3 Application integration 213

11 Accessing LDAP directories with JNDI 215
11.1 Introduction to JNDI 216
JNDI versus the LDAP Java SDK 216
11.2 JNDI architecture 216
JNDI providers 217 ✦ The JNDI package 217

CONTENTS ix
 11.3 JNDI operations: the DirContext class 217
Handling basic exceptions 218 ✦ Closing the connection 218
Binding to the directory 218 ✦ A reusable LDAP connection handler 219
11.4 Searching with JNDI 220
Abstracting the entry 221 ✦ A search class 223
11.5 Adding entries 226
A simple add example 226 ✦ A generalized add example 227
11.6 Manipulating entries 229
Modifying entries 229 ✦ Deleting entries 230 ✦ Renaming entries 231
11.7 Summary 232

12 Java programming with DSML 233

12.1 Writing DSML with Java 234
12.2 DSML with JNDI 235
Automatic DSML output from LDAP URLs 236
12.3 Working with schemas in DSML 237
Reading schemas with SAX 238 ✦ Designing a basic SAX handler 240
12.4 Transformation with XSLT in Java 244
12.5 Enhancements with DSMLv2 248
Implementing interapplication communication 249 ✦ Creating DSMLv2
SOAP requests 249 ✦ Creating DSMLv2 SOAP requests with JNDI 252
12.6 Summary 252

13 Application security and directory services 253

13.1 The relationship between security and directories 254
What is security? 254 ✦ How LDAP provides security 256
13.2 Storing key and certificate data 259
Preshared secret keys 259 ✦ Public/private key pairs 261
13.3 Using digital certificates 262
Creating a digital certificate in Java 263
Storing and distributing digital certificates 264
13.4 Managing authorization information 268
Understanding access control rules 268 ✦ Directory authorization 269
Application authorization 269
13.5 Encrypting LDAP sessions using JNDI and SSL 270
13.6 Summary 271

A: Standard schema reference 273

B: PerLDAP 302
index 317

x CONTENTS
preface
This book will help you understand and use the most important directory services—
those based on the leading industry standards—without having to read the many eso-
teric standards documents available on the Web. I am tempted to start the book with
a motivating example from my experience to explain why directory services are so
important and why you should read this book from cover to cover, but I will resist.
There is no need to tell a story from my experience, because I can tell a story from
your experience. Every single one of you has had experience with directory services,
whether you know it or not.
Did you log in to a computer today? When the computer checked your password,
it was probably using a directory service.
Do you use a personalized start page, such as Netscape Netcenter? If so, your pref-
erences and login information were found in a directory service and used to customize
your experience.
Have you ever looked up the email addresses of long-lost friends on the Internet,
or located the telephone number of the woman in receiving who can track down your
lost package? Both of these tasks are also common uses for directories.
However, you don’t need to learn how to type someone’s name into a search
engine or enter your password. What you do need to learn, and what this book will
teach you, is how to apply the standards that make directory services accessible over
computer networks ranging from the Internet to your corporate intranet to business
partners’ extranets.
We won’t stop there. The most pressing issue in the area of directory services today
is simply that there are so many of them. Every application written in the last 30 years
seems to have come with its own proprietary directory. Operating systems also have
directories. Most of these directories don’t care about each other or even acknowledge
the others’ existence. This book will help you get these existing directories to work well
with new, important standards-based directory services.
Finally, what good is a data repository without useful applications? If you are an
application developer trying to get your existing applications to work with Light-
weight Directory Access Protocol (LDAP), Directory Services Markup Language
(DSML), and other directory standards, this book not only will help you get a handle

xi
 on important application program interfaces (APIs), but also will deliver an under-
standing of the best strategies for using these applications to derive important appli-
cation benefits.

WHO AM I, AND WHAT’S MY MOTIVATION?

Many of the people picking up this book may know my reputation as a long-time
developer in the directory space. My background in this area includes writing the first
comprehensive Perl module for accessing directory services via LDAP, as well as writ-
ing software for getting applications such as Apache, the Squid proxy server, and
Cyrus mail servers to check passwords against servers supporting LDAP.
My recent work in this area has included the development of complete Java server
software for providing data via the LDAP protocol. The server, originally a part-time
open source project, is now the cornerstone of a virtual directory and proxy service
product offering from OctetString. However, this book is vendor neutral; all major
LDAP vendors are discussed to some extent in the first chapter.
Like many of you, I stumbled onto LDAP by accident. In 1993, I was employed
as part of Motorola’s Cellular Infrastructure Group in Arlington Heights, Illinois.
Along with a small group of other colleagues, I cofounded one of Motorola’s first web-
based intranets.
Unlike today, when most major web sites are dynamic and filled to the brim with
personalized content and real-time access to databases and important applications,
there were few web-based applications in those days. Sensing the potential use of this
new technology, yet realizing that this grass-roots project would not receive funding
if we couldn’t adequately expose business information, many team members pro-
ceeded to develop applications, such as card catalogs for engineering documents and
similar things.
I decided that my small project would be an email directory. As the only person
on this project from the IT organization, I was aware of a service provided by corporate
mainframes that presented information culled from human resources and local area
network (LAN) administrators over a simple protocol called WHOIS.
Using WHOIS, you could open a simple network connection to the server (which
in this case resided on a mainframe) and type the data to be used for searching. The
search results were returned as free-form text. My application did nothing more than
read this text, parse it, and write it out as HTML that could be displayed graphically
by a web browser.
It was an instant hit.
I became known at Motorola Cellular as the “directory” guy, and was instantly
pushed onto most of the projects that dealt with directories. At the time, these projects
primarily related to email. Email is an important use of directories—after all, if you
cannot locate the address of people with whom you need to communicate, a large email
infrastructure doesn’t do much good. However, I began to realize that this directory

xii PREFACE
 wasn’t just a way to look up information; it was a key storage point for identity infor-
mation—the only network-accessible place in the company where a person’s email
address, login ID, department, name, and manager were linked together. I realized that
smart applications could use this information to identify users throughout the com-
pany and authorize them based on criteria, such as their department. Those applica-
tions could also provide customized presentations based on that same information.
I also knew that as good as this idea was, it would be hard to execute given the lim-
itations of WHOIS, unless we customized each application. At this time, I came into
contact with X.500.
Like WHOIS, X.500 is a standard for a kind of directory service. Unlike WHOIS,
X.500 is anything but simple. It is a detailed set of standards definitions that seems
to describe everything within a 10-mile radius of directory services, including client
access, real security, server-to-server communications, and similar areas. Also unlike
WHOIS, X.500 comes from the OSI networking world, which was left in the dust in
the wake of the Internet explosion and the mass adoption of loosely networked systems
built around standards such as TCP/IP.
Nearly every book or article written about LDAP talks about X.500 being perfect
except for that dastardly OSI protocol stack, which makes deployment on desktop-
class hardware difficult. (Although there is truth to this reasoning, the real reason most
X.500 directory projects didn’t take off is that getting the right data into the directory
and keeping it up-to-date was difficult—after all, garbage in, garbage out. Similarly,
few applications were X.500 aware, partly due to its complexity.) This difficulty
spawned LDAP, which was meant to replace X.500’s Directory Access Protocol (DAP)
as a client implementation.
After making the move from X.500 to LDAP for the same published reasons every-
one else did, the lack of integration tools and directory-enabled applications was obvi-
ous. So, I created things like Net::LDAPapi and PerLDAP to glue together information
from different sources into the directory. Not long afterward, I wrote the code that
allowed users to be identified and authorized to many services, such as web, proxy,
and mail.
Today many applications are directory-enabled—so many that these applications
drive most new directory deployments, rather than the other way around. People look-
ing at deploying and accessing directories are faced with many difficult choices in
design and execution. My goal for this book is to help simplify this complex technol-
ogy in a way that accelerates your projects and improves your end results.

LESSONS LEARNED, AND THIS BOOK’S FOCUS

Since discovering LDAP, I’ve spent nearly every day looking to develop solutions to
these types of problems. Much of the time, the solution is centered on creating enter-
prise directory services. I’ve learned a few things about creating successful directory
services. The most critical are:

PREFACE xiii
 • Access is access.
• Configuration is trivial; management is complex.
Although these may seem like insanely simple lessons, let me explain.
Access is access
Certain methods of access may be more efficient or provide more underlying func-
tionality, but at the end of the day, it is only important that the directory service can
share information in a way that clients and applications can use. Today, that standard
for sharing information in directory services is LDAP. Therefore, we use LDAP as the
primary access protocol throughout this book.
However, many of the more advanced techniques described in parts 2 and 3 of this
book will work just as well with another means of access. In fact, part 3 describes the
use of Directory Services Markup Language (DSML), which you can use to represent
directory services information as XML.
Configuration is trivial; management is complex
This is not to say that your mother should be installing and configuring your direc-
tory servers. It is merely an indication of the relative complexity of configuration ver-
sus management.
I cannot stress enough that unless the directory is running in a stand-alone envi-
ronment where it is the only source of data, there will be effort in getting information
into and out of the directory. Unless you understand and make this effort up front,
the data in the directory will either be stale and useless or require yet another manual
administrative process to keep it up to date.
New technology is coming out that removes some of the technical barriers to splic-
ing information into authoritative directories. However, such technology does not
remove the internal political roadblocks and the need for up-front planning that is
required in nearly all meaningful directory service deployments.

xiv PREFACE
acknowledgments
Creating a quality technology book involves a great deal of effort from many talented
and passionate individuals. There is simply no way to thank all of those involved
enough for their efforts in making this book as good as it could possibly be.
I must start by thanking my wife Linda for her support in this endeavor. Without
her patience and strong support, this book certainly would never have been completed.
A few weeks before the book went to press, we received the special delivery of our son
Ethan, who was certainly an inspiration as the book’s development came to a close.
Too many people to name looked at bits and pieces of this book. Some of the peo-
ple who looked through early drafts were Kurt Zeilenga of the OpenLDAP project, La
Monte Yaroll of Motorola, Booker Bense of Stanford, Jay Leiserson and Richard
Goodwin of IBM, Jauder Ho of KPMG, Ranjan Bagchi, Juan Carlos Gomez and Raul
Cuza. Nathan Owen of IBM and Phil Hunt of OctetString also offered some very
helpful feedback on several key sections later in the development cycle.
Extra special thanks go to Booker Bense, who did a detailed final review of the
entire text and made a number of quality suggestions that I feel contributed to the
technical accuracy and readability of the book. Don Bowen of Sun was also especially
helpful in his review of key sections of the book as it neared completion.
Many people at Manning Publications were incredible throughout the process.
Marjan Bace and Mary Piergies were on top of this project with their full attention
and enthusiasm from the start. Lianna Wlasiuk was phenomenal as a development edi-
tor and offered many significant ideas that vastly improved the final content of the
book. Tiffany Taylor did a fantastic job of editing the text and removing all of the
embarrassing errors that I left behind. Dottie Marsico had the Herculean task of mak-
ing sense of a vast number of graphics in a myriad formats, among other things. Syd
Brown came up with the book’s wonderful design, and Leslie Haimes did a great job
putting together a captivating cover. Ted Kennedy did a masterful job of staying on
top of the entire review process.
Finally, a special thanks to everyone I’ve emailed or spoken with over the years
about this technology. These discussions helped shape much of the thinking that went
into this book. So much was learned from sharing information with the users of the
LDAP-related technology I’ve developed. This learning and interaction was truly a
reward for any effort on my part.

xv
about this book
Part 1 of the book has five chapters:
• Chapter 1 introduces core LDAP concepts, with the understanding that you may
have little or no past exposure to the protocol.
• Chapter 2 introduces LDAP’s information model and schema. Information in
an LDAP-enabled directory is presented in a simple and uniform way that you
should understand before proceeding. This chapter covers object classes,
attribute types, and schema standards.
• Chapter 3 offers information about LDAP namespace and naming standards.
Because all entries in LDAP are uniquely named, it’s important for you to
understand the information in this chapter.
• Chapter 4 provides an overview of LDAP search criteria. Because searching is
the most commonly used and most complex LDAP operation from a client per-
spective, we spend considerable time introducing and explaining filters, scope,
and search bases.
• Chapter 5 introduces the LDAP Data Interchange Format (LDIF) and the
Directory Services Markup Language (DSML), an XML standard for represent-
ing directory information, and shows how these standards can be used to easily
store and share directory information.
Part 2 is as follows:
• We begin exploring LDAP management in chapter 6. This chapter introduces the
Net::LDAP module, which lets you use Perl to access and manage an LDAP-
enabled directory.
• In chapter 7, we discuss administrative techniques. Examples include a web-
based tool that you can use to manage individual entries.
• Chapter 8 offers insights into synchronization and migration. No data exists in
a vacuum, so this chapter provides guidance about some of the ways data in
other directories and databases can be leveraged in an LDAP environment.

xvi
 • Chapter 9 explains how to monitor and manage information about the LDAP
server. Examples include schema retrieval scripts and tools for generating syn-
thetic transactions that can be used to check server availability.
• Chapter 10 expands on our previous discussion of DSML. Many examples are
provided, in Perl, including ones for generating DSML and transforming it to
HTML using XSLT.
Part 3 comprises the book’s final three chapters:
• In chapter 11, we begin discussing the best methods for directory-enabling your
applications. This chapter offers an introduction to the Java Naming and Direc-
tory Interface (JNDI), an API for accessing directory services based on many stan-
dards, including LDAP.
• In chapter 12, we refocus on DSML in an application context. Examples are
given that relate DSML to other technologies, such as web services and SOAP.
An exploration of DSML version 2 operations is also provided.
• Security ranks with messaging as a critical area for directory integration. For
that reason, we spend chapter 13 going over authentication, authorization, dig-
ital certificate storage, and LDAP security issues in general.
The book ends with two appendixes:
• Appendix A provides a compilation of standard schemas from Request for Com-
ments (RFCs), Internet Drafts, and other sources that you should consider prior
to the creation of new schemas. The LDAP schema is discussed in chapter 2.
• PerLDAP is a popular alternative to the Net::LDAP module discussed in part 2.
Appendix B offers an overview of PerLDAP and translation of many of the
examples in part 2.

WHO SHOULD READ THIS BOOK

This book is written for network and system administrators, as well as application
developers. Little or no past LDAP exposure is required.
Part 1 of this book uses command-line tools to demonstrate LDAP features. Part 2
provides examples in Perl that can be used unmodified in many cases or as the basis
for more advanced tools.
Finally, part 3 of the book is focused on application development issues with exam-
ples in Java. Although less directly useful to system and network administrators, it cov-
ers many important aspects of directory-enabled application development.

AUTHOR ONLINE
When you purchase LDAP Programming, Management and Integration you gain free
access to a private web forum run by Manning Publications where you can make

ABOUT THIS BOOK xvii

 comments about the book, ask technical questions, and receive help from the author
and from other users. To access the forum and subscribe to it, point your web
browser to www.manning.com/donley. This page provides information on how to get
on the forum once you are registered, what kind of help is available, and the rules of
conduct on the forum.
Manning’s commitment to our readers is to provide a venue where a meaningful
dialogue between individual readers and between readers and the author can take
place. It is not a commitment to any specific amount of participation on the part of
the author, whose contribution to the AO remains voluntary (and unpaid). We suggest
you try asking the author some challenging questions lest his interest stray!
The Author Online forum and the archives of previous discussions will be acces-
sible from the publisher’s web site as long as the book is in print.

SOURCE CODE
Source code for all examples presented in LDAP Programming, Management and
Integration is available for download from www.manning.com/donley.
Code conventions
Courier typeface is used for code examples. Bold Courier typeface is used in
some code examples to highlight important or changed sections. Certain references to
code in text, such as functions, properties, and methods, also appear in Courier
typeface. Code annotations accompany some segments of code.

xviii ABOUT THIS BOOK

getting started
Throughout this book, examples are provided wherever possible. This section details
where to get the tools you will need to use the examples.

DIRECTORY SERVERS
A directory server supporting LDAP is required to run these examples. The examples
should work with almost any LDAP-enabled directory server, except where noted
prior to the example.
This book is about getting the most from directory services, not installing and con-
figuring all the directories on the market. Following are pointers to some of the more
common directory servers available at the time of publication. Additionally, we
include basic instructions for obtaining a special LDAP server that has been precon-
figured to work with the examples in this book.
Directory server vendors
The LDAPZone (http://www.ldapzone.com) web site is a good place to begin when
you’re looking for answers to many directory issues. It has active community pages
and links to other sites related to LDAP. It also has links to the most popular LDAP
server implementations.
Among the servers currently listed are
• Novell eDirectory
• iPlanet Directory Server
• Oracle Internet Directory
• Critical Path InJoin Directory Server
• Microsoft Active Directory
• IBM SecureWay Directory
• Open Source OpenLDAP Directory
• Data Connection Directory
• OctetString Virtual Directory Engine

xix
 Each of these vendors provides a server that is directly LDAP accessible, with solid
documentation for installation and configuration.
Basic configuration parameters
The examples in this book assume the server will be listening on TCP port 389,
which is the standard LDAP port. This is usually easily configurable within the server,
although certain implementations (such as Microsoft Active Directory) cannot be
configured to listen on a different port.
The root of the directory tree used in the examples is dc=manning,dc=com.
This will be acceptable to most implementations, but some older servers may not be
aware of dc-style naming. If that is the case, substituting o=manning,c=us or any
other name for the root in configuration and examples should be acceptable. You can
find more information about naming and directory trees in chapter 3.
Most of the examples in this book use standard schemas related to people and
groups that can be found in virtually all LDAP implementations. If an example pro-
duces an error related to a schema violation, you may need to add the schema being
referenced by that example. Different directories have different files and configuration
options for adding new schemas.

COMMAND-LINE TOOLS
In part 1 of the book, no programming languages are used. Instead, we use com-
monly available LDAP tools to demonstrate key components of LDAP, such as infor-
mation model, entry naming, and search filters. These tools come with many
operating systems, such as Solaris and some Linux variants. They are also distributed
with many directory server products.
You can determine if the tools are available by attempting to run commands such
as ldapmodify and ldapsearch. If these commands exist, they should be suitable
for the examples in this book.
The source code to these tools can be found in at least two places:
• The OpenLDAP project (www.openldap.org)
• The Mozilla Directory project (www.mozilla.org/directory/)
Both of these versions are suitable for use with the examples in this book.
If you prefer to download precompiled versions of these tools, you can most easily
obtain them as part of the iPlanet Directory Software Development Kit (SDK). This
kit is available at http://www.iplanet.com/downloads/developer/.

LDAP PERL MODULES

Part 2 of this book, which focuses on directory management, uses the Perl language
to populate, synchronize, and otherwise manage information in directories. These
examples require a modern version of Perl (at least 5.005 is required, but 5.6 or

xx GETTING STARTED
 higher is recommended) and the Perl-LDAP module. This is not to be confused with
PerLDAP, which is the module previously released by Netscape and the author of this
book. Although both modules do the same job, Perl-LDAP is becoming more widely
used; and, because it is completely written in Perl, it is portable to any platform where
Perl is available.
The Perl-LDAP module is written and maintained by Graham Barr and can be
found at perl-ldap.sourceforge.net along with detailed installation instructions.
Active State Perl users can use these commands to install the necessary module
automatically:
C:\ >ppm
PPM interactive shell (2.1.6) - type 'help' for available commands.
PPM> install perl-ldap

Users of other versions of Perl can access the module on the Comprehensive Perl
Archive Network (CPAN) (http://www.cpan.org).

JAVA
Java is used extensively throughout part 3 of this book. We use core Java functional-
ity found in J2SE as well as extensions for communicating with LDAP and parsing
XML/DSML.

Java LDAP Access

There are two primary ways to access LDAP in Java:
• Java Naming and Directory Interface (JNDI)—You can use this generalized inter-
face to access LDAP and non-LDAP directory and naming services.
• Netscape Java SDK—This set of Java classes was created specifically to talk to
directory servers via the LDAP protocol.
This book uses JNDI. JNDI comes standard as part of Java development kits and
runtimes at or above the 1.3 version. It is available for download at java.sun.com for
earlier Java development kits.
DSML/XML
The examples in chapter 12 use both JNDI and the Java API for XML (JAXP). The
JNDI examples that read DSML files require the DSML provider for JNDI. This pro-
vider is a preview technology on java.sun.com at the time of publication. The JAXP
reference implementation from Sun is included with Java 1.4 and available for earlier
Java releases from Sun’s Java site at http://java.sun.com/.

GETTING STARTED xxi

about the cover illustration
The figure on the cover of LDAP Programming, Management and Integration is called
an “Aga de los Genizaros,” an officer in the Turkish infantry. The illustration is taken
from a Spanish compendium of regional dress customs first published in Madrid
in 1799. The title page of the Spanish volume states:
Coleccion general de los Trages que usan actualmente todas las Nacionas del Mundo des-
ubierto, dibujados y grabados con la mayor exactitud por R.M.V.A.R. Obra muy util y en
special para los que tienen la del viajero universal
which we translate, as literally as possible, thus:
General Collection of Costumes currently used in the Nations of the Known World,
designed and printed with great exactitude by R.M.V.A.R. This work is very useful espe-
cially for those who hold themselves to be universal travelers.
Although nothing is known of the designers, engravers, and workers who colored this
illustration by hand, the “exactitude” of their execution is evident in this drawing. It
is just one of many figures in this colorful collection. Their diversity speaks vividly of
the uniqueness and individuality of the world’s towns and regions just 200 years ago.
This was a time when the dress codes of two regions separated by a few dozen miles
identified people uniquely as belonging to one or the other. The collection brings to
life a sense of isolation and distance of that period and of every other historic period
except our own hyperkinetic present. Dress codes have changed since then and the
diversity by region, so rich at the time, has faded away. It is now often hard to tell the
inhabitant of one continent from another. Perhaps, trying to view it optimistically, we
have traded a cultural and visual diversity for a more varied personal life. Or a more
varied and interesting intellectual and technical life.
We at Manning celebrate the inventiveness, the initiative, and the fun of the com-
puter business with book covers based on the rich diversity of regional life of two cen-
turies ago brought back to life by the pictures from this collection.

xxii
 P A R T
1
Fundamental
LDAP concepts
The Lightweight Directory Access Protocol (LDAP) has emerged as the standard for
accessing directory services over networks. In this first part of the book, we will look
at everything you need to know about LDAP.
Chapter 1 begins with an exploration of the many uses and benefits of LDAP, as
well as its origin. From there we move on to an overview of current directory man-
agement and interoperability issues. At the end of chapter 1, we glance at the available
and emerging tools that allow for easier integration between different data sources.
Information is exchanged between LDAP clients and servers using containers called
entries. These containers are formed based on a particular information model that we
discuss in chapter 2.
Entries in a directory are given unique, hierarchical names in an LDAP directory.
In chapter 3, we look at how these names are formed, naming issues, and best practices.
Chapter 4 covers LDAP search criteria. The focus here is on simplifying the some-
times complicated combination of search filters, scopes, and bases that make up an
LDAP search request.
You will get your first look at Directory Services Markup Language (DSML), the
latest standard for representing directory information and operations in XML, in chap-
ter 5. Chapter 5 also formally introduces the LDAP Data Interchange Format (LDIF),
which is a commonly used format for sharing and storing directory information.
 C H A P T E R 1

Introduction to LDAP
1.1 What LDAP is 4 1.6 Directory management 23
1.2 What LDAP is not 7 1.7 Directory integration 24
1.3 Current applications 10 1.8 Integration and federation via virtual
1.4 Brief history 15 directory technology 30
1.5 LDAP revisions and other 1.9 Why this book? 31
standards 18 1.10 Summary 32

In this chapter, we introduce the Lightweight Directory Access Protocol (LDAP) and
attempt to answer the following questions:
• What is LDAP? Who needs it? How is it used?
• What are directory services? Where do they fit in the grand scheme of things?
Which ones exist? What is their relation to LDAP?
• What are common issues in planning and deploying directory services?
• Where do metadirectories, provisioning tools, and virtual directories fit
with LDAP?
• What standards organizations and industry consortia are responsible for further
development of directory services and LDAP standards?

3
1.1 WHAT LDAP IS
LDAP is a standard that computers and networked devices can use to access common
information over a network. The ability to provide network access to data in itself
does not make LDAP stand out from dozens of other protocols defined for data
access, such as Hypertext Transfer Protocol (HTTP). As you will see in this chapter
and those following, a number of features and vendor efforts make LDAP very well-
suited for access and updates to many types of common information.
For example, information about employees might be stored in a directory so that
people and applications can locate their contact information. Such contact informa-
tion might include email addresses and fax numbers, or even additional data that
unambiguously identifies employees’ attempts to access enterprise applications.
1.1.1 Directory services and directory servers
A directory is simply a collection of information. For example, the telephone book is a
directory used by virtually everyone to find telephone numbers.
Directory services provide access to the information in a directory. A simple direc-
tory service that most people use from time to time is the directory assistance offered
by most telephone companies. By dialing a telephone number, anyone can receive
instant access to information in the telephone directory.
In the computer world, directories exist everywhere. The Unix password file can
be considered a directory of computer accounts. The Domain Name Service (DNS)
acts as a directory service providing information about network hosts.
Computer applications often have their own directories. The Apache web server
can store usernames and passwords in a data file, which is thus a directory of users.
Customer information stored in a database can also be considered directory informa-
tion if it is of a common nature with applications outside a single program or system.
Directory servers are applications that primarily act as directory services, providing
information from a directory to other applications or end users. This functionality is
most applicable in client/server environments, where the service may be located
remotely from the calling application or system. For example, on Unix or Linux com-
puters running the Network Information Service (NIS), the ypserv program can be
considered a directory server.
1.1.2 LDAP and directory services
LDAP provides client-server access to directories over a computer network and is
therefore a directory service. In addition to offering the ability to search and read
information, it defines a way to add, update, and delete information in a directory.
Two general types of directory server software implement the LDAP standards:
• Stand-alone LDAP servers
• LDAP gateway servers

4 CHAPTER 1 INTRODUCTION TO LDAP

 Stand-alone LDAP servers focus exclu-
Local
sively on LDAP as their only access
Data mechanism; their proprietary internal
data stores are tuned for LDAP access.
LDAP Directory These are typically what people mean
when they use the words LDAP server.
Instead of being tied to a local data
store, LDAP gateway servers translate
Data between LDAP and some other native
LDAP Gateway network protocol or application pro-
gram interface (API) to provide access to
directory information that is more
directly available via other means. One
Data example is the original use of LDAP: to
gateway to other directory services sup-
LDAP-Enabled porting the X.500 standards. Another
Directory Service
more modern example of such an LDAP
Figure 1.1 LDAP directories and LDAP gate- gateway is a server that provides LDAP
ways are different types of products that access to information residing in Oracle
provide LDAP-enabled directory services.
database tables.
Figure 1.1 illustrates the two types of services that can be used to provide LDAP-
enabled directory services.
The examples throughout this book will not address one type of server over the
other—the idea behind LDAP is that it shouldn’t matter where the end data is stored,
as long as the client and server can use LDAP to communicate that information in a
standard way understood by both sides.
In addition, we will focus primarily on accessing and managing information and
services through the LDAP protocol. Each directory server product is installed and
configured differently, usually in ways that are well-documented in product manuals.
It would be of little use to duplicate such information, because installation and con-
figuration of the software is relatively trivial.
1.1.3 Other directory services
LDAP is not alone in providing computerized directory services. It is also not the first
or even the most completely defined directory service.
Other directory services that have been popular in the past, and that are still in use
in many organizations, include those based on standards such as X.500, WHOIS,
NIS, PH/QI, and various proprietary directories from companies such as Novell, Ban-
yan, and others.
X.500 is a set of standards that originated in the late 1980s, with significant updates
as late as 2001. The standards are extensive and cover everything from access to rep-
lication. In many respects, X.500 is more mature as a protocol than LDAP, including
such technologies as multimaster replication and access control, but its relative

WHAT LDAP IS 5
 complexity has made it less popular for access. However, it is still very popular, and
a number of vendors sell servers that support these standards. These vendors tend to
focus on X.500-based protocols for interoperability between servers, while exposing
the data using an LDAP gateway.
WHOIS was an early attempt at a simple protocol for Internet-accessible white
pages. The services supporting this protocol took a simple string and returned free-
form text in response. A WHOIS server could be written on most operating systems in
a short amount of time, but lack of standard data representation made it difficult to do
anything but display the results as they arrived. Unfortunately, this limitation makes
programmatic use of the resulting data in non–white pages applications very difficult.
NIS, originally called Yellow Pages (YP), was Sun’s remote procedure call (RPC)-
based operating system directory. Most Unix-based servers support some variant of
this protocol. With a relatively simple replication model and access protocol, as well
as the ability to discover servers on a local network, its creation was necessary due to
the growth in client-server computing where users might exist on a number of serv-
ers. However, it was not well-suited for wide area networks (WANs) offered little in
the way of security, and was not easily extensible for storing additional information
in existing maps.
PH/QI was very popular at about the time HTTP became widely used. It was a
multipurpose client-server directory service developed by Paul Pomes at the University
of Illinois at Urbana-Champaign (UIUC). It was especially popular at universities in
North America and was used to store not only white pages information, but also infor-
mation that could be used for security, such as logins and credentials. One of the ear-
liest applications to take advantage of the Common Gateway Interface (CGI) that
shipped with the original National Center for Supercomputing Applications (NCSA)
HTTP server was a gateway that presented an HTML interface to a PH server. Some
mail applications, such as Eudora, were also able to perform PH queries for address
books. LDAP’s acceptance in the industry curtailed any serious move to PH/QI; in
addition, the service was somewhat limited. The protocol was relatively simple and
text-based; it was easy to access programmatically but designed to run on a central
server, limiting its scalability and scope.
Banyan was an early leader in MS-DOS/Windows operating system directories,
but it didn’t fare well as Microsoft and Novell became more directory-aware. Banyan
eventually changed its name to ePresence and is currently one of the larger integrators
focused on directory services.
Novell based the proprietary directory service for its Netware Network Operating
System (NOS) on the X.500 standards. Netware’s directory has long been regarded
as one of the more solid operating system directories, and Novell has a long history
of directory integration in its products. As LDAP picked up steam, Novell separated
the NOS from the directory and created eDirectory; it is now a popular LDAP-
enabled directory service with the broadest platform support of any directory services
vendor’s product.

6 CHAPTER 1 INTRODUCTION TO LDAP

1.2 WHAT LDAP IS NOT
LDAP is an access protocol that shares data using a particular information model. The
data to which it provides access may reside in a database, in memory, or just about
anywhere else the LDAP server may access. It is important that the data be presented
to an LDAP client in a way that conforms to LDAP’s information model.
LDAP is being used for an increasing number of applications. Most of these appli-
cations are appropriate—but some aren’t. To get a better idea what LDAP should and
shouldn’t be used for, we begin this section with an overview of LDAP limitations that
make it a bad choice for certain types of applications.
LDAP is not:
• A general replacement for relational databases
• A file system for very large objects
• Optimal for very dynamic objects
• Useful without applications
1.2.1 LDAP is not a relational database
LDAP is not a relational database and does not provide protocol-level support for rela-
tional integrity, transactions, or other features found in an RDBMS. Applications that
require rollback when any one of multiple operations fails cannot be implemented
with the current version of LDAP, although some vendors implement such function-
ality when managing their underlying datafiles. LDAP breaks a number of database
normalization rules. For example, 1NR states that fields with repeating values must be
placed into separate tables; instead, LDAP supports multi-valued data fields.
Some LDAP server vendors proclaim that directories are somehow faster than rela-
tional databases. In some cases, this is true. In other cases, databases are both faster and
more scalable. Nothing inherent in the LDAP protocol makes it in any way faster than
other data access mechanisms, such as Open Database Connectivity (ODBC). Every-
thing depends on how the underlying data store is tuned.
LDAP lacks features found in relational databases even in cases where LDAP sits
on top of a relational data store, as is true with Oracle and IBM directory server prod-
ucts. The LDAP protocol currently has no standard for transmitting the type of infor-
mation necessary to take advantage of the powerful relational and transactional
capabilities present in the underlying data store.
1.2.2 LDAP is not a file system for very large objects
LDAP provides a hierarchical way of naming information that looks remarkably like
that found in most file systems. Many people see this aspect of LDAP as an indica-
tion that it might be a great way to centrally store files to make them accessible over
a network.

WHAT LDAP IS NOT 7

 In fact, LDAP is not a great way to do network file sharing. Although it allows
information (including binary data) to be transmitted and stored, it does not have the
locking, seeking, and advanced features found in most modern file-sharing protocols.
Figure 1.2 shows some of the disadvantages of using LDAP in this manner.

Big File LDAP

Figure 1.2
LDAP Client LDAP is not a network file system. Here you
P
LDA LDAP Server see that if you stored a large file using
LDAP, clients would need to read the entire
file via LDAP rather than page through the
Entire Big File applicable sections. If either client died in
midtransfer, it would need to start again
LDAP Client from scratch.

The Network File System (NFS) and similar file-sharing protocols have this
advanced functionality and are well-tested and accepted for use on local intranets.
Web protocols such as the HTTP and File Transfer Protocol (FTP) are more appro-
priate when you’re providing Internet access to data on local file systems.
In a similar vein, LDAP is often only marginally useful to store serialized objects,
large structured documents (such as XML), and similar types of data in the directory.
Because the LDAP server may not know how to parse these blobs of data, it will not
be able to search on attributes within them.
For example, if you store XML documents in the directory, you will not be able
to search for all XML documents in the directory that implement a particular docu-
ment type unless you also store the document’s type in the directory. Such a process
involves duplicating information already stored in the XML document.
Without storing this metadata, the XML document is an opaque object that can
only be stored and retrieved in full. By contrast, a good file-based XML parser has the
ability to seek through parts of the XML document and retrieve or manipulate only
those sections that are pertinent to the current operation. This situation may be chang-
ing as LDAP vendors become increasingly XML savvy and begin supporting such
functionality as XPath searching.
Note that because the LDAP protocol is separate from the data to which it pro-
vides access, it is possible for a particular LDAP server to be extended to handle par-
ticular types of objects more intelligently. For example, the server might include an
XML parser that indexes XML documents for easier search and retrieval with LDAP.
We’ll explore this process briefly in the context of attribute syntax and matching rules
in chapter 2.

8 CHAPTER 1 INTRODUCTION TO LDAP

1.2.3 LDAP is not optimal for very dynamic objects
Generally speaking, LDAP is not the place to store very dynamic information. For
example, there are a number of reasons it would be unwise to write extensive audit
logs to an LDAP entry each time a user accesses a system.
First, most LDAP servers optimize for search performance at considerable cost in
write performance. Updating a single attribute in some LDAP environments generally
takes a longer time than comparable updates to a well-designed database.
Second, even with high write performance, LDAP as a protocol does not have facil-
ities to ensure that a set of transactions will happen in the right order. This complicates
even the simplest updates to dynamic information involving multiple applications or
threads. Even a simple counter can get corrupted when two applications try to update
it simultaneously.
Finally, even if a particular server supports tuning for updates and adds proprietary
protocol extensions to support better locking that allows for better multiapplication
updates, using these special features may avoid a major benefit of LDAP. This benefit
is the ability of application developers to use LDAP without having to take note of the
server implementation being used.
1.2.4 LDAP is not useful without applications
LDAP lacks an SQL-like general reporting language of the kind found with most
general-purpose databases. Such reporting languages can often be used to generate
sophisticated reports from a database. Because directories are used for more generally
useful information, such as account information usable by many applications, this
lack of report generation support is insignificant.
Lack of generalized report generation makes it even more important that LDAP
directories be built around the notion that applications will be using them. In addi-
tion, it’s important that LDAP directory services be designed and deployed with full
cooperation from the application developers who will use the service.
Although it lacks a general report-generation language, LDAP offers a number of
powerful APIs. Many of these APIs are based on well-documented industry standards
whose wide acceptance has been one of the strongest drivers of early LDAP adoption.
Unlike databases, directories using LDAP have a wire protocol that can be used with-
out using special vendor drivers, making directories important for information that
can benefit many applications that otherwise have nothing in common.
Thanks to the ease with which these APIs can be used, a large number of applica-
tions now provide native support for LDAP where it makes sense. You can find some
of these LDAP-enabled applications, such as those providing shared address book or
white pages functionality, on the Internet and in nearly all modern email and web
browser software.

WHAT LDAP IS NOT 9

 LDAP is now mature technology used by a wide variety of applications for many
critical purposes. These applications include everything from authentication, autho-
rization, and management of application and operating system users to routing of bil-
lions of email messages around the world. New applications are developed every day
that ensure that LDAP’s importance will continue to grow.

1.3 CURRENT APPLICATIONS

As we just discussed, successful directory services depend on application support. In
this section we begin to examine the types of applications that normally leverage
LDAP-enabled directories.
1.3.1 White pages
One of the first uses of enterprise directories was to provide electronic shared address
books, called white pages (see figure 1.3). LDAP has long been used to provide access
to information that enables white pages functionality. In fact, white pages applica-
tions are the most widely deployed and visible LDAP-enabled applications.

Figure 1.3 This screen from the Outlook Express email client is an example of a
white pages application.

Both Netscape and Internet Explorer have built-in support for searching LDAP
directories and presenting the results in the form of an address book. Most email
applications released in the past few years provide this same functionality, although
some still support their own proprietary standards to remain compatible with legacy
workgroup-oriented directories. Figure 1.4 shows how such a client might talk to a
directory to retrieve this information.
A quick chat with most corporate intranet webmasters would reveal that the most
frequently accessed application on an intranet is usually a corporate contact database.
Everyone from the mailroom clerk to the CEO needs to be able to locate their peers;

10 CHAPTER 1 INTRODUCTION TO LDAP

 Data

LDAP
Address Book
Client LDAP Server

Figure 1.4 An address book client talks directly to an LDAP server.

therefore, it is the simplest application available to demonstrate the power and sim-
plicity provided by directory access.
Web-based white pages applications are useful for extending LDAP information to
points beyond an intranet environment when firewalls or a lack of installed clients pre-
vent pure LDAP communication. Figure 1.5 shows how a web server might act as a
gateway for white pages requests from an end-user’s web browser.

Data

HTTP LDAP

Browser
LDAP Server
Web Server

Figure 1.5 The same directory shown in figure 1.4, with a web application rather than the
end-user’s client communicating via LDAP

Most people already have an LDAP-enabled browser or email client, or can access
white pages via a web interface. This simplifies deployment and allows for more wide-
spread access.
In fact, creating an application that can search for information in LDAP is not par-
ticularly difficult. The following is a full code listing in Java using the Java Naming
and Directory Interface (JNDIJ) for a program that can search for information in an
LDAP-enabled directory service:
import javax.naming.directory.*;
import javax.naming.*;
import java.util.Vector;
import java.util.Enumeration;
import java.util.Properties;

public class SearchLDAP {

public static void main(String[] args) {

String base = "";
String filter = "(objectclass=*)";

CURRENT APPLICATIONS 11
 Properties env = new Properties();
env.put(DirContext.INITIAL_CONTEXT_FACTORY,
"com.sun.jndi.ldap.LdapCtxFactory");
env.put(DirContext.PROVIDER_URL,"ldap://localhost:389");

try {
DirContext dc = new InitialDirContext(env);

SearchControls sc = new SearchControls();

sc.setSearchScope(SearchControls.OBJECT_SCOPE);

NamingEnumeration ne = null;
ne = dc.search(base, filter, sc);

while (ne.hasMore()) {
SearchResult sr = (SearchResult) ne.next();
System.out.println(sr.toString()+"\n");
dc.close();
}

} catch (NamingException nex) {

System.err.println("Error: " + nex.getMessage());
}
}
}

The results of this code are not pretty, but they show how easy it is to tie LDAP into
a new or existing application for white pages or other lookup functionality.
Another benefit of using a web-based white pages application is that whereas most
browsers and email clients enable LDAP searches, a web-based application can offer
a point of self-administration for contact information. Information such as phone
numbers and mailing addresses can be managed using a simple interface that is inte-
grated with the search tools. This approach makes it easy for someone to change his
or her information quickly when necessary.
1.3.2 Authentication and authorization
It is virtually impossible to discuss user access and system security today without
LDAP being part of the conversation. Although it isn’t as visible to the casual user,
LDAP is emerging as the de facto way to access the identity information and creden-
tials needed to support authentication. Authentication is the process of validating the
identity of a user (or any other object, such as an application).
This process allows identity information to be managed and distributed much
more easily than via traditional means. Information stored in an LDAP-enabled data
store can be segmented for simpler management while presenting a unified view to
applications and authentication services.
Using LDAP also has the benefit of reusing identity information. This approach
offers a significant advantage over authentication processes that use an operating
system or proprietary mechanism. For example, using LDAP allows both Unix- and

12 CHAPTER 1 INTRODUCTION TO LDAP

 Windows-based servers running a particular application to authenticate users in the
same manner and from the same repository. In effect, application development time
is reduced, authentication code is relatively static between platforms, and the admin-
istrative cost of managing two identity repositories is removed. Figure 1.6 shows how
an application might use LDAP to authenticate a user.

Login as: Bob Smith

Password: abc123

Browser
Bob Smith HTTP

Figure 1.6
Bob Smith uses a browser
LDAP (bind) to access information on a
protected web server. The
SUCCESS! web server first binds to
LDAP-enabled LDAP the LDAP directory to
Web Server Directory authenticate him.

After authenticating, it is possible to use other available information about the

authenticated user (such as department, company, age, and so on) to determine
whether he or she is authorized to perform a particular action on resources within a
particular computing environment or application.
We will cover the use of LDAP as an authentication and authorization resource in
chapter 13. This discussion will include more sophisticated authentication mecha-
nisms, single sign-on issues, and many other related security concerns.
1.3.3 Personalization
Once a person has been identified through authentication, it is useful to personalize
the user’s experience based on their identity and preferences. In some cases, personal-
ization may simply mean placing the current user’s name at the top of a web page. A
more sophisticated use might be to pull the customer’s location information from the
directory to prepopulate an order form.
In a complex web environment with a variety of features, LDAP-enabled directo-
ries are a useful place to store information about users’ preferences. For example, you
might allow users to choose a particular product line as their primary interest when a
site covers a large number of products.
Capturing this information and enabling access to it via LDAP allows a variety
of applications to customize users’ experiences based on their interests. Doing so
offers an important benefit: personalized content can be consistent between multi-
ple applications.

CURRENT APPLICATIONS 13
 LDAP has been gaining wide acceptance as a place to store and retrieve personal-
ization information in enterprise applications. For example, most enterprise portals
support LDAP as a means of obtaining the information needed for personalization.
1.3.4 Roaming profiles
Closely related in many respects to personalization, but focused more on operational
preferences than content preferences, is the concept of roaming profiles. Roaming
profiles allow users to authenticate to an application on any machine and get an
identical environment. You do so by storing considerable individual configuration
options in a directory.
In addition to enabling roaming, directory-based security also offers the potential
to lock down certain configuration items or create organizational or group defaults.
In environments with less-sophisticated users, doing so makes it possible to update
user configurations without a system administrator needing to make a trip to each
cubicle or spend time on the phone walking a user through complicated steps within
an application.
Few stand-alone applications provide roaming profiles. Part of the reason is that
most applications vary widely in their configuration. Thus each application may
require additional information in the directory server to enable storage of that appli-
cation’s configuration values.
This requirement showcases a common conflict between application developers,
who often want to change schema to meet their applications’ needs, and system
administrators, who realize that changes in schema require a great deal of administra-
tive effort. The challenge is deciding where to draw the line between generally useful
information that belongs in a directory and application specific information that
belongs elsewhere. We will discuss this conflict further in chapter 2.
1.3.5 Public Key Infrastructure
Traditional authentication and encryption systems use secret keys. Generally speak-
ing, a secret key system requires both ends of a communication to know a secret pass-
word that will be used to hide the communication. The right secret password
produces a legible message, which both protects the message in transit and proves that
the message must have been written by the other party, because they were the only
other ones with knowledge of the secret. This approach works well as long as the
secret isn’t compromised and you communicate with few enough people that you can
remember a shared secret with each one.
Public key technology changes all this and makes the process more scalable. In this
system, two keys are produced. One key, called the private key, is still secret. However,
unlike the secret key in a shared-secret system, the private key is never shared with any-
one. Instead, a second key called the public key is distributed. A public key can be
placed in a digitally signed container called a digital certificate. Such certificates are
commonly used to distribute public keys.

14 CHAPTER 1 INTRODUCTION TO LDAP

 A successful deployment of public key infrastructure is highly dependent on a well-
designed directory services infrastructure. An LDAP-enabled directory answers the
question of where to store and locate digital certificates. Centrally storing digital cer-
tificates in a directory allows people and applications to find certificates on demand
for business partners and peers with whom they need to communicate securely.
In addition to helping you locate certificates for encryption, directories let you find
a list of certificates that have been revoked prior to their expiration time. These cer-
tificate revocation lists (CRLs) are commonly stored in LDAP-enabled directories.
This book is not specifically about Public Key Infrastructure (PKI), but PKI is one
common application that uses directories. We discuss the use of directories with PKI
in much more detail in chapter 13.
1.3.6 Message delivery
On the Internet, messages are routed based on the fully qualified host name to the
right of the at sign (@). Such routing is typically done by using the DNS to identify
the IP address associated with the human-readable fully qualified host name.
Once a message has been routed to the correct machine, it is delivered on that
machine based on the username to the left of the @. Many mail systems now support
the use of LDAP to determine how to deliver a message.
The delivery process can include advanced operations, such as locating the exact
mail drop for the user in a cluster of mail servers. However, the most common usage
is for allowing full-name email aliases and implementing email lists.
As mentioned in section 1.3.3, directories can help you target mailings based on
information associated with identities. In an LDAP directory, users are often placed
together in groups, either as a list of users or as a dynamic specification (such as all
users in department A). These groups can be used for authorization, personalization,
and even mailing lists.
We discuss group schemas in chapter 2. Examples of managing groups appear in
chapter 7.

1.4 BRIEF HISTORY

The previous section makes it obvious that there are a wide variety of uses for LDAP-
enabled directory services. Many of these uses first came about with earlier stan-
dards—particularly X.500, which we mentioned briefly earlier in this chapter. In this
section we will take a quick look at how LDAP came to its latest incarnation.
1.4.1 X.500 and DAP
LDAP is a TCP/IP-based client/server directory access protocol originally based on a
subset of the X.500 Directory Access Protocol (DAP). X.500 is a comprehensive set
of standards from the ITU Telecommunication Standardization Sector (ITU-T) that
describes all aspects of a global directory service. X.500, like many standards, has

BRIEF HISTORY 15
 gone through many revisions; work is still in progress to update it further. As shown
in figure 1.7, a client originally talked to an X.500 server using the DAP protocol.
Designed to be the standard directory service for the Open Systems Interconnec-
tion (OSI) world, X.500’s fortune has risen and fallen over the years, but it still has a
substantial following. Early on, X.500 was accepted by many large information tech-
nology (IT) organizations as the direction for global directory services. Although early
products had their problems, they also showed a great deal of promise. Many large
companies and universities implemented pilot projects, usually involving the hosting
of white pages.

Figure 1.7
P The X.500 client uses
DS X.500 DSA
DAP to communi-
cate with the X.500
X.500 Client DAP Directory System
X.500 DSA Agent (DSA).

One big issue arose very quickly with X.500: the fact that its access protocol required
an OSI protocol stack and complex binary encoding of structures represented in a
language called Abstract Syntax Notation One (ASN.1). Most desktop computers at
the time were ill equipped to deal with DAP.
As Internet Protocol (IP) became the dominant networking standard, DAP’s OSI
origins made it less attractive. Many of the organizations piloting X.500 directories
had already adopted IP and were looking for a protocol with less baggage for client
access. Even worse, X.500’s complexity and the lack of freely available standards doc-
uments or easy-to-use APIs made it difficult to develop clients without paying fees to
the ITU-T.
As we’ve stated since the beginning of this chapter, even the best directory is useless
when applications are not available to take advantage of it. Several white pages appli-
cations were available, but an electronic phone book is often not enough to justify the
expense of collecting and cleansing all the information necessary to make a directory
truly useful.
1.4.2 A new standard is born
In 1991, after a few false starts with other potential standards, LDAP was brought
forth as a lightweight means for accessing the DAP-enabled directories of the X.500
world. The first set of standards, LDAPv2, were eventually defined and accepted by
the Internet Engineering Task Force (IETF), an important standards body responsi-
ble for many important Internet standards, as RFCs 1777 and 1778.
These standards provided basic authentication, search, and compare operations, as
well as additional operations for changing the directory. From the start, LDAP made

16 CHAPTER 1 INTRODUCTION TO LDAP

 LDAP DAP
LDAP Client LDAP Server X.500 DAP

Figure 1.8 The X.500 client goes away, replaced by an LDAP client
talking to an LDAP server. Here, the LDAP server acts as a gateway
between LDAP-aware clients and DAP-aware X.500 DSAs.

X.500 more accessible, as intended. Figure 1.8 shows an X.500 server being accessed
by an LDAP gateway service that is forwarding requests from an LDAP client.
Almost as important as the protocol itself was the release of a standard API and the
production of a client development kit. For the first time, it was possible to access
these servers programmatically without wandering knee-deep into an arcane protocol.
1.4.3 LDAP goes solo
As time went by, some people began to wonder what made X.500 so special in the
first place. The University of Michigan, which had developed the reference imple-
mentation of LDAP, released a stand-alone server called Slapd that would allow the
LDAP server to present data from a local data store rather than simply act as a gate-
way to an X.500 server.
Slapd was followed by a second service called Slurpd, which read the changes from
one server and replicated those changes via the LDAP protocol to other Slapd servers.
Figure 1.9 shows a typical stand-alone LDAP environment.

LDAP Replica
AP
LD (Slapd)
P
LDA pd)
l u r
(S

LDAP Client LDAP

LDAP Server
(Slapd)

Figure 1.9 An LDAP client talks to a Slapd server. X.500 is no longer involved.

At this point, Netscape hired most of the original developers from the University of
Michigan Slapd server to develop the Netscape Directory Server. Netscape, which was
riding high with an incredible share of the Internet browser market, decided that net-
works would require directories and that LDAP, not X.500, should be the standard.
Nearly 40 other companies announced support at that time, bringing LDAP the focus
and support it needed to become the de facto standard for directory services.

BRIEF HISTORY 17
1.4.4 LDAPv3
LDAP may have gained acceptance as a stand-alone service, but it was far from com-
plete. Due primarily to its reliance on X.500 servers to provide the server-to-server
communications, access control, and other functionality, LDAP was still only a skele-
ton of a full directory service by the mid-1990s.
Many interested parties pushed forward with the development of the next gener-
ation of the LDAP standards. In December 1996, the new version was published as
RFCs 2251 to 2256. These new specifications covered items including the protocol
itself, mandatory and optional schema, and LDAP URLs. A set of standard authenti-
cation mechanisms and a standard for session encryption were added to the list of core
specifications in 2000. Figure 1.10 shows the core specifications that make up the
LDAP standard.

Core LDAP Standards

Protocol
(RFC 2251)

Mandatory Schema User Schema

(RFC 2252) (RFC 2256)

Distinguished Names Authentication Methods

(RFC 2253) (RFC 2829)

LDAP URLs Transport Layer Security

(RFC 2254) (RFC 2830)
Figure 1.10
The IETF has been the primary stan-
Search Filters Digest Authentication dards body for most of the existing
(RFC 2255) (RFC 2830) LDAPv3 specifications. This figure
shows a list of published RFCs that are
considered the core LDAP standards.

1.5 LDAP REVISIONS AND OTHER STANDARDS

LDAPv3 was considered a great leap forward in several key areas, but it takes more
than a protocol to make a directory service successful. It is now up to several stan-
dards bodies and industry consortia to enhance the LDAP core specifications and
build a framework that allows directories from different vendors to interoperate, or at
least share some of the most crucial information in a standard way, and play a more
pivotal role in e-business. Figure 1.11 shows some of the many standards bodies and
industry consortia that shape directory standards and define best practices in deploy-
ment and management.

18 CHAPTER 1 INTRODUCTION TO LDAP

 Distributed Management
OASIS
Task Force (DMTF)
Directory Services Markup
Common Information Model
Language (DSML)
(CIM)

Internet Engineering Task Force (IETF)

LDAP Standards

Figure 1.11
Open Group
Network Applications Many industry consortia and
Directory Interoperability
Consortium (NAC) standards bodies are
Forum (DIF)
Users Group involved with LDAP and
LDAP2000 Interoperability
related standards, but most
have a narrow focus.

1.5.1 Replication and access control

Version 3 of the LDAP protocol was greatly improved from version 2, but lacked two
important items: replication and access control. The IETF has created workgroups to
deliver these missing pieces and others, as shown in figure 1.12.

LDAPExt Workgroup LDUP Workgroup

Access Control Replication

Controls
LDAPbis Workgroup
Figure 1.12
APIs LDAPv3 Protocol IETF workgroups are trying to fill
Revisions in the gaps left after the initial
publication of LDAPv3.

Lack of a standard replication process has since become an interoperability nightmare

as each LDAP server vendor implemented its own proprietary solution. Many prod-
ucts use simple LDAP protocol operations to distribute data as shown in figure 1.13.
However, even those solutions using the LDAP protocol sometimes require propri-
etary controls or attributes.
Many parties recognized that replication was critical to obtaining scalability,
redundancy, and other important benefits. To resolve this issue, the Lightweight
Directory Update Protocol (LDUP) working group was created within the IETF. At
the time of this writing, the group has completed draft documents detailing require-
ments, a model for meeting those requirements, conflict resolution processes, and a
protocol specification. The use of replication is discussed further in chapter 6.

LDAP REVISIONS AND OTHER STANDARDS 19

 LDA
New Entry
P LDAP

Supplier Consumer
Directory Directory

Figure 1.13 Supplier-to-consumer replication exists in some products

using the LDAP protocol. Unfortunately, most need to use proprietary
attributes or controls to get around current limitations in the specifications.

In addition to the supplier-consumer model of replication available in most existing

directory servers, LDUP was chartered with allowing for multiple directory masters
for the same information, which is shown in figure 1.14. It also documents a process
for resolving conflicts that may arise when different and potentially conflicting
changes are made independently to the same entry on each master. In addition,
LDUP defines a protocol that can be used for both supplier-initiated and consumer-
initiated replication.
Security was further along in some respects. The Simple Authentication and Secu-
rity Layer (SASL), originally developed for the Internet Mail Access Protocol (IMAP),
was added as a core LDAP standard early on as a way to negotiate an appropriate type
of client and/or server authentication and even session encryption.
Developing a standard for access control has proven to be much more time con-
suming and has produced fewer results. As shown in figure 1.15, such a standard will
allow a server to determine if an authenticated entity should be able to read or update
a particular entry or an entire portion of the directory.

LD
New AP AP
Entry LD Another
New Entry
LDUP
Multimaster Replication
Master Master
Directory LD Directory
UP

Read-Only
Replica

Figure 1.14 Multimaster replication will allow changes to the same directory
tree in multiple directories.

20 CHAPTER 1 INTRODUCTION TO LDAP

 Bob Smith Can Bob Smith Add Entries to XYZ, Inc.? ACLs

YES
LDAP-enabled LDAP
Application Directory

Figure 1.15 LDAP access control standards will include a mechanism for determining in
advance whether an operation will be permitted.

The task of creating such a standard fell into the hands of the LDAP extensions
(LDAPEXT) workgroup within the IETF. This workgroup was formed to handle any
extensions needed to the LDAPv3 standards outside of replication. As this book is
being written, most activities of the LDAPEXT workgroup have been moved to indi-
vidual submissions and will likely become an informational RFC rather than a full
standard. Some aspects of access control may be pursued as part of the interoperabil-
ity requirements for replication.
To understand why access control might be bundled with the replication work-
group, think about the fact that any replication of information outside a vendor’s
products will render that data insecure—other vendors will not know the access con-
trol rules of the source data. Any practical solution for replication is dependent on a
standard for access control. We will look at access control further in chapter 13 when
we discuss directory security in more detail.
1.5.2 Directory Enabled Networking
As computer networks evolve to support more variety and depth of services, the com-
plexity of network management increases accordingly. Most network devices, includ-
ing routers and switches, have traditionally been configured using command-line
shells. Although this configuration enables relatively consistent management of a sin-
gle device, it does nothing to simplify the coordination of configurations across large
numbers of devices. Such coordination is critical when you’re enabling guaranteed
quality of service and other offerings that span multiple devices.
Directory Enabled Networking (DEN) provides a way for devices to configure
themselves based on information in a directory. Originally an initiative from
Microsoft and Cisco, DEN is now part of the CIM defined by the DMTF.
CIM is a set of object-oriented, implementation-neutral schemas that represents
logical and physical attributes of hardware and software. The DMTF, rather than
being protocol architects like the IETF, focused primarily on creating common
object definitions that allow two CIM-aware applications to store and use informa-
tion consistently.
Contrary to popular belief, CIM and DEN are not LDAP-specific information
models, but are instead “meta” models that can be specialized for a number of

LDAP REVISIONS AND OTHER STANDARDS 21

 environments, of which LDAP is one. XML is an example of another way that CIM
objects can be represented.
Momentum behind DEN as the killer application that would drive directories has
died down to an extent over the last few years, and most of the work around directories
has moved to identity management solutions. In this book, we will not focus on DEN
as a specific application due to the current lack of software and hardware that can truly
exploit this technology.
1.5.3 XML and directories
The eXtensible Markup Language (XML) is an industry standard language used to
define structured documents. It offers a set of common tags for defining data about
data, or metadata. This metadata can be used to describe particular document types.
Instances of documents implementing these types can then be shared and used by
XML-aware applications.
DSML is an XML document type that can be used to create structured documents
representing information in a directory service. This information represented in
DSML can include both directory entries and schema information. DSMLv2 extends
the specification to cover the representation of directory operations. Documents con-
forming to these standards can be exchanged using non-directory protocols like
HTTP, as shown in figure 1.16. Many new services that support DSML are becoming
available from both large vendors (Sun and Microsoft) and startups.

LDAP Entry

AP
DSML File LD LDAP Server
HTTP/FTP/
SMTP/etc.
DSML-Enabled DSML
Application Service

Figure 1.16 Here a DSML-enabled application talks to a DSML service that acts
as an intermediary between an LDAP server and the DSML-enabled application.

DSML is most useful in applications that are already XML enabled. These include
most modern application servers. DSML is especially useful in cases where direct
access to the directory would normally not be permitted. For example, consider a sit-
uation in which a firewall is blocking all traffic except HTTP. To get around this lim-
itation, a DSML encoding of a directory entry can be transmitted over the HTTP
protocol for interpretation and presentation. Such a situation is shown in figure 1.17.

22 CHAPTER 1 INTRODUCTION TO LDAP

 Firewall

LDAP Entry

AP
DSML File LD LDAP Server
HTTP/FTP/
SMTP/etc.
DSML-Enabled DSML
Application Service

Figure 1.17 DSML is useful for sharing directory information across fire-
walls that might limit direct access to directories.

Emerging standards like Simple Object Access Protocol (SOAP) make it clear that
LDAP will not be the only standard for sharing directory information in the future.

1.6 DIRECTORY MANAGEMENT

Despite the importance of having well-defined standards, it is rarely the reason for a
directory services–related project to fail. Rather, the biggest headache with most new
directory deployments is proper management of information in the directory. In the
days when enterprise directories were used primarily for storing white pages informa-
tion, it was often adequate to simply import information into the directory periodi-
cally from other, more authoritative data sources. Due to the lack of sophisticated
management tools, there wasn’t much choice.
Today, directory management tools for users and groups are much more sophisti-
cated. In addition to giving a central administrator the ability to change information
about objects in a directory, these tools typically allow for delegation of administrative
duties and even user self-management, where appropriate.
This ability to distribute administration works well in intranet and Internet envi-
ronments, but it is especially critical in extranet environments where multiple organi-
zations are working together, potentially using the same applications and data. In such
environments, the segmentation of administration and access is very important (see
figure 1.18).
For example, a car manufacturer with just-in-time manufacturing facilities needs
to give its business partners access to certain systems in its extranet. Access to appli-
cations on the extranet is controlled based on identities in each of its distributors and
component suppliers. Tracking by identity offers audit trails, which will deter a ran-
dom individual from anonymously ordering unauthorized parts.
The problem is, in addition to the employees at the company, such an extranet
environment including suppliers and distributors may include hundreds of thousands,

DIRECTORY MANAGEMENT 23
 Directory with Delegated
Administration

Manufacturer
Employees

Supplier
Manufacturer Employees

Supplier
Distributor
Employees

Distributor

Figure 1.18 Directories can be segmented such that administration

can be delegated to business partners. Such separation may be logical
rather than physical.

if not millions, of users. Trying to manage all these users centrally would be an incred-
ible effort.
By segmenting users by company and other means, you can push administration
of identities to primary contacts within each of the business partners, thereby reducing
administrative overhead. Aside from reducing administration costs, this approach also
ensures better accuracy by pushing identity management closer to the identities being
managed.
Information that is not related to identities and groups can still be difficult to man-
age with off-the-shelf products. This is the case primarily because little attention has
been paid to other advanced uses of directories, such as DEN, which require manage-
ment of more exotic information.
In chapter 7, we will look at managing all types of directory entries, complete
with example applications to reduce manual data entry and allow some degree of user
self-management.

1.7 DIRECTORY INTEGRATION

Many organizations spend months designing the schema, entry naming, and other
related aspects of an enterprise directory service without considering the need for
integration with existing information repositories. What usually results is a

24 CHAPTER 1 INTRODUCTION TO LDAP

 well-designed, standards-based directory service that contains stale information and is
nearly useless.
Meanwhile, legacy data stores that contain mission-critical information continue
to thrive because they contain fresh information, although in a way that is often incon-
venient to access from new applications and nearly impossible to access from off-the-
shelf applications without substantial custom development. Figure 1.19 shows how
this typical scenario plays out.

User

Spoiled No Value! Useful! Important

Data Business
Data

Well Designed, Awful, Proprietary,

Standards-Based Legacy Directory
Directory Service

Figure 1.19 Data in legacy systems is nearly always more useful than data in poorly
integrated new systems.

By designing and implementing an appropriate level of directory integration between

legacy data stores and the new directory service, you can dramatically increase the
value of the new directory (see figure 1.20).

Directory Integration

User

Important Okay!
Business Important
Data Business
Data

Well Designed, Awful, Proprietary,

Standards-Based Legacy Directory
Directory Service

Figure 1.20 Some level of directory integration is important in increasing the value of
applications using new directory services.

Directory integration is far more complicated than simply synchronizing everything

from a legacy data store into a newly created directory. It demands that you evaluate
the needs of applications that depend on both new and legacy data stores. In many
cases, both new and legacy applications that utilize the respective data stores. Very
often, these applications need access to some set of the same information.

DIRECTORY INTEGRATION 25
 Without any directory integration, it is often difficult to get more than a small
group of pioneers to quickly adopt the new applications. A new application may have
substantially better functionality, but without the proper data it will be difficult to
move the masses that use the legacy applications to the new environment. This issue
is demonstrated in figure 1.21.

Standard New Legacy Legacy,

Directory Application Pioneers The Masses Application Proprietary
Directory

Figure 1.21 It is difficult to move the masses to new applications based around a standards-
based directory when important information still resides only in a legacy directory.

By using integration techniques, such as synchronization, you can create a high

degree of interoperability between the two environments. This approach, shown in
figure 1.22, provides the necessary data flow between the two directories, offering a
relatively easy migration path to the new environment. It also ensures that the infor-
mation in both environments is consistent.

Bi-Directional
Directory Integration

Interoperability!
Migration Path!

Standard New Legacy Legacy,

Directory Application Pioneers The Masses Application Proprietary
Directory

Figure 1.22 Synchronization is often necessary to offer a migration path from legacy to
new applications or interoperability where legacy applications will not be migrated.

Consolidating these two environments can vastly simplify management. For example,
you may find a way for a Unix-based system to use the same directory as your white
pages application to store password information.
However, not every connected data store is a candidate for consolidation. Take,
for example, a human resources application that relies on a set of database tables to
store information. It may not make sense from an application functionality perspec-
tive for that particular application’s data store to be consolidated into an enterprise
directory. Some of the information may fit better in relational databases for the rea-
sons we stated in section 1.2.1, whereas other information may not be a good

26 CHAPTER 1 INTRODUCTION TO LDAP

 candidate for synchronization because of privacy concerns. So, instead of attempting
to directly replicate everything from human resources into the directory, you need a
form of intelligent synchronization.
In the area of identity management, directory integration almost always seems like
a great idea in theory. For example, the management of users’ computer accounts in
a particular organization from hire to fire demonstrates the value of synchronization
and other advanced integration technology.
Today, it is often necessary to touch multiple data repositories to commit a single
change uniformly to all the places that store information about a person. These
changes are usually performed by different application and system administrators. In
more mature environments, changes may be synchronized with scripts to facilitate this
process. When administrators do not coordinate their changes, or if an automated syn-
chronization script fails, the data repositories are no longer synchronized, and at least
one of the repositories will contain stale data.
If this stale data is simply a telephone number, the impact is probably minimal.
However, if an account must be deleted or suspended due to an employee’s termina-
tion, the data repository with stale data is at risk from the terminated employee. If the
stale data resides in an enterprise directory that is used for authenticating and autho-
rizing users to all non-legacy systems and applications, this one failed change can
potentially put the organization’s entire intranet at risk. Proper directory integration
is key to reducing these types of risks. For this reason, it is important to spend an ade-
quate amount of time planning for integration.
A general integration planning process entails identifying which data elements exist
in each existing data source, selecting those that should be shared, and mapping
between the source and destination schema (see figure 1.23).
This process and ways of implementing it are described in detail in chapter 7.
1.7.1 Integration via metadirectories
We cannot emphasize enough that the consolidation of all data repositories into a sin-
gle enterprise directory within even the smallest of organizations is not likely to hap-
pen in our lifetimes. Even if it were possible to rewrite every legacy application to use
a single standard, different directory and database software is better for different
tasks. As shown in figure 1.24, this leads to many different environments within an
organization that have different variations of the same user.
In the past few years, a new breed of applications called metadirectories has come
to market to remove some of the burden associated with directory integration.
Although it may sound like yet another directory, a metadirectory is really a sophis-
ticated directory integration toolkit.
You can use metadirectories to connect and join information between data sources,
including directories, databases, and files. The connection process usually involves
identifying changes in each data source. Such a connection may be real-time moni-
toring of changes using a direct access method into the connected data store, an occa-

DIRECTORY INTEGRATION 27
 1
2 Oracle Normalized
Database View
sjones

3
White Pages 1 2
Integration 3 4
Directory 5
sam.jones

4
5 HR Sam Jones

Database
sam jones

Attributes
1 Password 4 Department
2 Telephone 5 Manager
3 Email

Figure 1.23 Multiple data repositories typically store information about a person.
Deciding which attributes come from where and mapping them to a normalized
schema is an important part of any directory integration process. Note that the
word normalized here should not be confused with database normalization rules.

sional scan of a file-based list of changes, or a review of a full export from the connected
data store.
The join process is much more complicated and usually involves several steps. Its
most important job is determining that an object in one data source is the same as an
object in a second data source. This aggregation of information from multiple data
sources is one of the most important features of a metadirectory and the heart of the
join process. Other tasks performed by a metadirectory may include unification or
mapping of schema and object names, filtering unwanted information, and custom
processing and transformation of data. Figure 1.25 shows a relatively logical view of
how a metadirectory might work to provide a linkage between key enterprise infor-
mation repositories.
With careful planning, you can create an environment in which users can be cre-
ated at a single point. Then, the metadirectory service will instantiate a subset of the

28 CHAPTER 1 INTRODUCTION TO LDAP

Exploring the Variety of Random
Documents with Different Content
 DR. T. S. WILLIAMSON.
The father of the Dakota Mission has gone. Thomas Smith
Williamson died at his residence in St. Peter, Minn., on Tuesday, the
24th of June, 1879, in the eightieth year of his life. My own
acquaintance with this life-long friend and companion in work
commenced when I was yet a boy, just fifty years ago in July. We
were new-comers in the town of Ripley, Ohio, where Dr. Williamson
was then a practising physician of some five years’ standing. My
mother was taken sick and died. In her sick-chamber our
acquaintance commenced, which has continued unbroken for half a
century.
The silver wedding of the Dakota Mission was celebrated at
Hazelwood, in the summer of 1860. Dr. Williamson himself furnished
a sketch of his life and ancestry for that occasion which has never
been published. From this document, as well as from articles written
by his son, Prof. Andrew Woods Williamson, and published in the St.
Peter Tribune and the Herald and Presbyter, much of this life-sketch
will be taken.
Thomas Smith Williamson, M.D., was the son of Rev. William
Williamson and Mary Smith, and was born in Union District, South
Carolina, in March, 1800.
William Williamson commenced classical studies when quite
young; but the school he attended was broken up by the
appointment of the teacher as an officer in the Revolutionary army.
When about sixteen years of age, while on a visit to an uncle’s on
the head-waters of the Kanawha, in Virginia, several families in the
neighborhood were taken captive by the Indians, and he joined a
company of volunteers which was raised to go in pursuit. After more
than a week’s chase, they were entirely successful, and lost only one
of their own number.
 When not yet eighteen years old, he was drafted into the North
Carolina militia, and accompanied Gates in his unfortunate
expedition through the Carolinas. After the war was over and the
family had removed to South Carolina, William resumed his studies
and was graduated at Hampton Sidney College—studied theology,
and was ordained pastor of Fair Forest Church, in April, 1793.
The grandfather of Thomas Smith Williamson was Thomas
Williamson, and his grandmother’s maiden name was Ann Newton, a
distant relative of Sir Isaac and Rev. John Newton. They were both
raised in Pennsylvania, but removed first to Virginia and then to the
Carolinas, where they became the owners of slaves, the most of
whom were purchased at their own request to keep them from
falling into the hands of hard masters.
Thus Rev. William Williamson was born into the condition of
slaveholder. By both his first and second marriage also, he became
the owner of others, which, by the laws of South Carolina, would
have been the property of his children. For the purpose of giving
them their liberty, he removed, in 1805, from South Carolina to
Adams County, Ohio. Before her marriage, Mary Smith had taught a
number of the young negroes to read. And of their descendants
quite a number are now in Ohio. It should be remembered that the
Smiths and Williamsons of the eighteenth century thought it right,
under the circumstances in which they were, to buy and hold slaves,
but not right to sell them. They never sold any.
Thomas Smith Williamson inherited from his father a love for
the study of God’s Word, and a practical sympathy for the down-
trodden and oppressed, which were ever the distinguishing
characteristics of his life. He was also blessed with a godly mother
and with five earnest-working Christian sisters, four of whom were
older than himself. He was converted during his stay at Jefferson
College, Cannonsburg, Pa., where he graduated in 1820. Soon after,
he began reading medicine with his brother-in-law, Dr. William
Wilson of West Union, Ohio, and, after a very full course of reading,
considerable practical experience, and one course of lectures at
Cincinnati, Ohio, completed his medical education at Yale, where he
graduated in medicine in 1824. He settled at Ripley, Ohio, where he
soon acquired an extensive practice, and April 10, 1827, was united
in marriage with Margaret Poage, daughter of Col. James Poage,
proprietor of the town. Perhaps no man was ever more blessed with
a helpmeet more adapted to his wants than this lovely, quiet,
systematic, cheerful, Christian wife, who for forty-five years of
perfect harmony encouraged him in his labors.
They thought themselves happily settled for life in their pleasant
home, but God had better things in store for them. His Spirit began
whispering in their ears the Macedonian cry. At first, they excused
themselves on account of their little ones. They felt they could not
take them among the Indians, that they owed a duty to them. They
hesitated. God removed this obstacle in his own way—by taking the
little ones home to himself. As this was a great trial, so was it a
great blessing to these parents. This was one of God’s means of so
strengthening their faith that, having once decided to go, neither of
them ever after for one moment regretted the decision, doubted that
they were called of God to this work, or feared that their life-work
would prove a failure.
In the spring of 1833, Dr. Williamson placed himself under the
care of the Chillicothe Presbytery, and commenced the study of
theology. In August of that year he removed with his family to
Walnut Hills, and connected himself with Lane Seminary. In April,
1834, in the First Presbyterian Church of Red Oak, he was licensed
to preach by the Chillicothe Presbytery.
Previous to his licensure, he had received from the American
Board an appointment to proceed on an exploring tour among the
Indians of the Upper Mississippi, with special reference to the Sacs
and Foxes, but to collect what information he could in regard to the
Sioux, Winnebagoes, and other Indians. Starting on this tour about
the last of April, he went as far as Fort Snelling, and returned to
Ohio in August. At Rock Island he met with some of the Sacs and
Foxes, and at Prairie du Chien he first saw Dakotas, among others
Mr. Joseph Renville of Lac-qui-parle. On the 18th of September he
was ordained as a missionary by the Chillicothe Presbytery, in Union
Church, Ross County, Ohio.
A few months afterward he received his appointment as a
missionary of the A. B. C. F. M. to the Dakotas; and on the first day
of April, 1835, Dr. Williamson, with his wife and one child,
accompanied by Miss Sarah Poage, Mrs. Williamson’s sister, who
afterward became Mrs. Gideon H. Pond, and Alexander G. Huggins
and family, left Ripley, Ohio, and on the 16th of May they arrived at
Fort Snelling. At this time, the only white people in Minnesota, then
a part of the North-west Territory, were those connected with the
military post at Fort Snelling, the only post-office within the present
limits of the State; those connected with the fur-trade, except Hon.
H. H. Sibley, were chiefly Canadian French, ignorant of the English
language; and Messrs. Gideon H. and Samuel W. Pond, who came
on their own account as lay teachers of Christ to the Indians in
1834.
While stopping there for a few weeks, Dr. Williamson presided at
the organization, on the 12th of June, of the First Presbyterian
Church—the first Christian church organized within the present limits
of Minnesota. This was within the garrison at Fort Snelling, and
consisted of twenty-two members, chiefly the result of the labors of
Major Loomis among the soldiers.
Having concluded to accompany Mr. Joseph Renville, Dr.
Williamson’s party embarked on the fur company’s Mackinaw boat on
the 22d of June; reached Traverse des Sioux on the 30th, where
they took wagons and arrived at Lac-qui-parle on the 9th of July.
There, on the north side of the Minnesota River, and in sight of the
“Lake that speaks,” they established themselves as teachers of the
religion of Jesus.
Of the “Life and Labors” pressed into the next forty-four years,
only the most meager outline can be given in this article. It is now
almost two round centuries since Hennepin and Du Luth met in the
camps and villages of the Sioux on the Upper Mississippi. Then, as
since, they were recognized as the largest and most warlike tribe of
Indians on the continent. Until Dr. Williamson and his associates
went among them, there does not appear to have been any effort
made to civilize and Christianize them. With the exception of a few
hundred words gathered by army officers and others, the Dakota
language was unwritten. This was to be learned—mastered, which
was found to be no small undertaking, especially to one who had
attained the age of thirty-five years. While men of less energy and
pluck would have knocked off or been content to work as best they
could through an interpreter, Dr. Williamson persevered, and in less
than two years was preaching Christ to them in the language in
which they were born. He never spoke it easily nor just like an
Indian, but he was readily understood by those who were
accustomed to hear him.
It was by a divine guidance that the station at Lac-qui-parle was
commenced. The Indians there were very poor in this world’s good,
not more than a half-dozen horses being owned in a village of 400
people. They were far in the interior, and received no annuities from
the government. Thus they were in a condition to be helped in many
ways by the mission. Under its influence and by its help, their corn-
patches were enlarged and their agriculture improved. Dr.
Williamson also found abundant opportunities to practise medicine
among them. Not that they gave up their pow-wows and conjuring;
but many families were found quite willing that the white Pay-zhe-
hoo-ta-we-chash-ta (Grass Root Man) should try his skill with the
rest. For more than a quarter of a century his medical aid went hand
in hand with the preaching of the Gospel. By the helpfulness of the
mission in various ways, a certain amount of confidence was
secured. And through the influence of Mr. Renville, a few men, but
especially the women, gathered to hear the good news of salvation.
Here they were rejoiced to see the Word taking effect early. In
less than a year after their arrival, Dr. Williamson organized a native
church, which, in the autumn of 1837, when I joined the mission
force at Lac-qui-parle, counted seven Dakotas. Five years after the
number received from the beginning had been forty-nine. This was a
very successful commencement.
 But in the meantime the war-prophets and the so-called
medicine-men were becoming suspicious of the new religion. They
began to understand that the religion of Christ antagonized their
own ancestral faith, and so they organized opposition. The children
were forbidden to attend the mission school; Dakota soldiers were
stationed along the paths, and the women’s blankets were cut up
when they attempted to go to church. Year after year the mission
cattle were killed and eaten. At one time, Dr. Williamson was under
the necessity of hitching up milch-cows to haul his wood—the only
animals left him.
These were dark, discouraging years—very trying to the native
church members, as well as to the missionaries. As I look back upon
them, I can but admire the indomitable courage and perseverance of
Dr. Williamson. My own heart would, I think, have sometimes failed
me if it had not been for the “hold on and hold out unto the end” of
my earthly friend.
As Mr. Renville could only interpret between the Dakotas and
French, Dr. Williamson applied himself to learning the latter
language. Through this a beginning was made in the translation of
the Scriptures into the Dakota. Late in the fall of 1839 the Gospel of
Mark and some other small portions were ready to be printed, and
Dr. Williamson went with his family to Ohio, where he spent the
winter. The next printing of portions of the Bible was done in 1842-
43, when Dr. Williamson had completed a translation of the book of
Genesis. We had now commenced to translate from the Hebrew and
Greek. This was continued through all the years of his missionary
life. So far as I can remember, there was no arrangement of work
between the doctor and myself, but while I commenced the New
Testament, and, having completed that, turned to the Psalms, and,
having finished to the end of Malachi, made some steps backward
through Job, Esther, Nehemiah, and Ezra, he, commencing with
Genesis, closed his work, in the last months of his life, with Second
Chronicles, having taken in also the book of Proverbs.
Before leaving the subject of Bible translation, let me bear
testimony to the uniform kindness and courtesy which Dr. Williamson
extended to me, through all this work of more than forty years. It
could hardly be said of either of us that we were very yielding. The
doctor was a man of positive opinions, and there were abundant
opportunities in prosecuting our joint work for differences of
judgment. But, while we freely criticised each the other’s work, we
freely yielded to each other the right of ultimate decision.
In the autumn of 1846, Dr. Williamson received an invitation,
through the agent at Fort Snelling, to establish a mission at Little
Crow’s Village, a few miles below where St. Paul has grown up, and
he at once accepted it, gathering from it that the Lord had a work
for him to do there. And indeed he had. During the five or six years
he remained there, a small Dakota church was gathered, and an
opportunity was afforded him to exert a positive Christian influence
on the white people then gathering into the capital of Minnesota. Dr.
Williamson preached the first sermon there.
When, after the treaties of 1851, the Indians of the Mississippi
were removed, he removed with them—or, rather, went before them,
and commenced his last station at Pay-zhe-hoo-ta-zee, Yellow
Medicine. There he and his family had further opportunities “to glory
in tribulations.” The first winter was one of unusual severity, and
they came near starving. But here the Lord blessed them, and
permitted them to see a native church grow up, as well as at
Hazelwood, the other mission station near by. It was during the next
ten years that the seeds of civilization and Christianity took root, and
grew into a fruitage, which, in some good manner, bore up under
the storm of the outbreak in 1862, and resulted in a great harvest
afterward.
Twenty-seven years of labor among the Dakotas were past. The
results had been encouraging—gratifying. Dr. Williamson’s eldest
son, Rev. John P. Williamson, born into the missionary kingdom, had
recently come from Lane Seminary, and joined our missionary
forces. But suddenly our work seemed to be dashed in pieces. The
whirlwind of the outbreak swept over our mission. Our houses and
churches were burned with fire. The members of our native
churches—where were they? Would there ever be a gathering again?
But nothing could discourage Dr. Williamson, for he trusted not in an
arm of flesh, but in the all-powerful arm of God. He found that he at
least had the consolation of knowing that all the Christian Indians
had continued, at the risk of their own lives, steadfast friends of the
whites, that they had succeeded in saving more than their own
number of white people, and that those of them who were unjustly
imprisoned spent much of the time in laboring for the conversion of
the heathen imprisoned with them.
It required just such a political and moral revolution as this to
break the bonds of heathenism, in which these Dakotas were held. It
seems also to have required the manifest endurance of privations,
and the unselfish devotion of Dr. Williamson and others to them in
this time of trouble, to fully satisfy their suspicious hearts that we
did not seek theirs but them. The winter of 1862-63, Dr. Williamson,
having located his family at St. Peter, usually walked up every
Saturday to Mankato, to preach the Gospel to the 400 men in prison.
“That,” said a young man, “satisfied us that you were really our
friends.” Sometimes it seems strange that it required so much to
convince them! History scarcely furnishes a more remarkable
instance of divine power on human hearts than was witnessed in
that prison. For a particular account of this the reader is referred to
the monograph on Rev. G. H. Pond.
Ever since the outbreak, Dr. Williamson has made a home for
his family in the town of St. Peter and its vicinity. For two years of
the three in which the condemned Dakotas were imprisoned at
Davenport, Iowa, he gave his time and strength chiefly to
ministering to their spiritual needs. Education never progressed so
rapidly among them as during these years. They almost all learned
to read and write their own language; and spent much of their time
in singing hymns of praise, in prayer, and in reading the Bible. They
were enrolled in classes, and each class placed under the special
teaching of an elder. This gave them something like a Methodist
organization, but it was found essential to a proper watch and care.
This experience in the prison and elsewhere made it more and more
manifest that, to carry forward the work of evangelization among
this people, we must make large use of our native talent.
The original Dakota presbytery was organized at Lac-qui-parle in
the first days of October, 1844. Dr. Williamson and myself brought
our letters from the presbytery of Ripley, Ohio, and Samuel W. Pond
brought his from an Association in Connecticut. The bounds of this
presbytery were not accurately defined, and so for years it absorbed
all the ministers of the Gospel of the Presbyterian and
Congregational orders who came into the Minnesota country. By and
by the presbyteries of St. Paul and Minnesota were organized; but
the Dakota presbytery still covered the country of the Minnesota
River.
At a meeting of this presbytery at Mankato in the spring of
1865, when our first Dakota preacher, Rev. John B. Renville, was
licensed, an incident took place which illustrates the meekness and
magnanimity of Dr. Williamson’s character. On its own adjournment
the presbytery had convened and was opened with a sermon by Dr.
Williamson, in the evening, in the Presbyterian church. He took
occasion to present the subject of our duties to the down-trodden
races, the African and the Indian. Doubtless some who heard the
discourse did not approve of it. But no exceptions would have been
taken if the Jewett family, out a few miles from the town, had not
been killed that night by a Sioux war-party. Men were so
unreasonable as to claim that the preaching and the preacher had
some kind of casual relation with the killing. The next day, Mankato
was in a ferment. An indignation meeting was held, and a committee
of citizens was sent to the Presbyterian church to require Dr.
Williamson to leave their town. Some of the members of the
presbytery were indignant at this demand; but the good doctor
chose to retire to his home at St. Peter, assuring the excited and
unreasonable men of Mankato that he could have had no knowledge
of the presence of the war-party, and certainly had no sympathy
with their wicked work.
In years after this, I traveled hundreds of miles, often alone
with Dr. Williamson, and while we conversed freely of all our
experiences, and of the way God had led us, I do not remember that
I ever heard him refer to this ill treatment of the people of Mankato.
Like his Master, he had learned obedience by the things he suffered.
Never brilliant, he was yet, by his capacity for long-continued,
severe exertion, and by systematic, persevering industry, enabled to
accomplish an almost incredible amount of labor. His life was a grand
one, made so by his indomitable perseverance in the line of lifting up
the poor and those who had no helper.
From the beginning he had an unshaken faith in his work. He
fully believed in the ability of the Indians to become civilized and
Christianized. He had an equally strong and abiding faith in the
power of the Gospel to elevate and save even them. Then add to
these his personal conviction that God had, by special providences,
called him to this work, and we have a threefold cord of faith, that
was not easily broken.
No one who knew him ever doubted that Dr. Williamson was a
true friend of the red man. And he succeeded wonderfully in making
this impression upon the Indians themselves. They recognized, and,
of late years, often spoke of, his life-long service for them. With a
class of white men, this was the head and front of his offending,
that, in their judgment, he could see only one side—that he was
always the apologist of the Indians—that in the massacres of the
border in 1862, when others believed and asserted that a thousand
or fifteen hundred whites were killed, Dr. Williamson could only
count three or four hundred. He was honest in his beliefs and honest
in his apologies. He felt that necessity was laid upon him to “open
his mouth for the dumb.” They could not defend themselves, and
they have had very few defenders among white people.
In the summer of 1866, after the release of the Dakota
prisoners at Davenport, Dr. Williamson and I took with us Rev. John
B. Renville, and journeyed up through Minnesota and across Dakota
to the Missouri River, and into the eastern corner of Nebraska. On
our way, we spent some time at the head of the Coteau, preaching
and administering the ordinances of the Gospel to our old church
members, and gathering in a multitude of new converts, ordaining
elders over them, and licensing two of the best qualified to preach
the Gospel. When we reached the Niobrara, we found the Christians
of the prison at Davenport and the Christians of the camp at Crow
Creek now united; and they desired to be consolidated into one
church of more than 400 members. We helped them to select their
religious teachers, which they did from the men who had been in
prison. So mightily had the Word of God prevailed among them that
almost the entire adult community professed to be Christians. Rev.
John P. Williamson was there in charge of the work.
For four successive summers, it was our privilege to travel
together in this work of visiting and reconstructing these Dakota
Christian communities. We also extended our visits to the villages of
the wild Teeton Sioux along the Missouri River. Dr. Williamson
claimed that Indians must be more honest than white people; for he
always took with him an old trunk without lock or key, and in all
these journeys he did not lose from a thread to a shoe-string.
For thirty-six years the doctor was a missionary of the American
Board. But after the union of the assemblies, and the transfer of the
funds contributed by the New School supporters of that board to the
Presbyterian Board of Foreign Missions, the question of a change of
our relations was thoughtfully considered and fully discussed. He
was too strong a Presbyterian not to have decided convictions on
that subject. But there were, as we considered it, substantial
reasons why we could not go over as an entire mission. And so we
agreed to divide, Dr. Williamson and his son, Rev. John P.
Williamson, transferring themselves to the Presbyterian Board, while
my boys and myself remained as we were. The division made no
disturbance in our mutual confidence, and no change in the methods
of our common work. Rather have the bonds of our union been
drawn more closely together, during the past eight years, by an
annual conference of all our Dakota pastors and elders and Sabbath-
school workers. This has gathered and again distributed the
enthusiasm of the churches; and has become the director of the
native missionary forces. With one exception, Dr. Williamson was
able to attend all these annual convocations, and added very much
to their interest.
While the synod of Minnesota was holding its sessions in St.
Paul in October, 1877, the good doctor was lying at the point of
death, as was supposed, with pneumonia. Farewell words passed
between him and the synod. But his work was not then done, and
the Lord raised him up to complete it. At the next meeting of the
synod, he presented a discourse on Rev. G. H. Pond; and during the
winter following he finished his part of the Dakota Bible. Then his
work appeared to be done, and he declined almost from that day
onward.
On my way up to the land of the Dakotas, in the middle of May,
1879, I stopped over a day with my old friend. He was very feeble,
but still able to walk out, and to sit up a good part of the day. We
talked of many things. He then expressed the hope that as the warm
weather came on he might rally, as he had done in former years. But
the undertone was that, as the great work of giving the Bible to the
Dakotas in their own language was completed, there was not much
left for him to do here. He remarked that, during the last forty-four
years, he had built several houses, all of which had either gone to
pieces, or were looking old, and would not remain long after he was
gone. But the building up of human souls that he had been
permitted to work for, and which, by the grace of God, he had seen
coming up into a new life, through the influence of the Word and the
power of the Holy Ghost, he confidently believed would remain.
When I spoke of the near prospect of his dissolution to his
Dakota friends, there arose in all the churches a great prayer cry for
his recovery. This was reported to him, and he sent back this
message, by the hand of his son Andrew: “Tell the Indians that
father thanks them very much for their prayers, and hopes they will
be blessed both to his good and theirs. But he does not wish them
to pray that his life here may be prolonged, for he longs to depart
and be with Christ.” And the testimony of Rev. G. F. McAfee, pastor
of the Presbyterian church in St. Peter, who often visited and prayed
with him in his last days, is to the same effect: “He absolutely
forbade me to pray that he might recover, but that he might depart
in peace.”
And so his longing was answered. He died on Tuesday, June 24,
1879, in the morning watch.
He had no ecstasies, but he looked into the future world with a
firm and abiding faith in Him whom, not having seen, he loved. Of
his last days, John P. Williamson writes thus:—

“He seemed to be tired out in body and mind, with as much

disinclination to talk as to move, and apparently as much from
the labor of collecting his mind as the difficulty of articulation. I
think he talked very little from the time I was here going home
from General Assembly (June 1) till his death, and for some
time was perhaps unconscious.
“You may know that father had a special distaste for what
are called death-bed experiences. Still, we thought that
perhaps, at the last, when the bodily pains ceased, there might
be a little lingering sunshine from the inner man, but such was
not the case; and perhaps it was most fitting that he should die
as he had lived, with no exalted feelings or bright imagery of
the future, but a stern faith, which gives hope and peace in the
deepest waters.”

He lived to see among the Dakotas ten native ordained

Presbyterian ministers and about 800 church members, besides a
large number of Episcopalians, a success probably much beyond his
early anticipations.
On the farther shore he has joined the multitude that have gone
before. Of his own family there are the three who went up in
infancy. Next, Smith Burgess, a manly Christian boy, was taken away
very suddenly. Then Lizzie Hunter went in the prime of womanhood.
The mother followed, a woman of quiet and beautiful life. And then
the sainted Nannie went up to put on white robes. Besides these of
his family, a multitude of Dakotas are there, who will call him father.
I think they have gathered around him and sung, under the trees by
the river, one of his first Dakota hymns:—

“Jehowa Mayooha, nimayakiye,

Nitowashta iwadowan.”

“Jehovah, my Master, thou hast saved me,

I sing of thy goodness.”

My friend—my long-life friend—my companion in tribulation and

in the patience of work, I almost envy thee thy first translation.
S. R. R.
 A MEMORIAL.
ELIZA HUGGINS; NANNIE WILLIAMSON; JULIA LA
FRAMBOISE.

ELIZA W. HUGGINS.

The Lord came to his garden, and gathered three fair flowers,
which now bloom in the city of our God. We, who knew their beauty,
come to lay our loving remembrances upon their graves.
Eliza Wilson Huggins was the third child of Alexander G. and
Lydia Huggins. She was born March 7, 1837, and died June 22, 1873.
She early gave herself to Jesus, and her lovely life was like a
strain of sacred music, albeit its years of suffering brought out
chords of minor harmony.
This young girl, in the dawn of womanhood, with gentle step
and loving voice, was a revelation to us who were younger than she.
Huguenot blood ran swiftly in her veins, and grief and joy were keen
realities to her sensitive soul. But she quieted herself as a child
before the Lord, and he gave her the ornament which is without
price. Though she wist not, her face shone, and we, remembering,
know that she had been with Jesus.
Her sister, Mrs. Holtsclaw, writes: “We are of Huguenot descent
on our father’s side. Our great-great-grandfather was born at sea in
the flight from France to England. Two brothers (in that generation
or the one following) came to America, one settling in North
Carolina, the other in New England. Our grandfather left North
Carolina when father was a small boy, because he thought slavery
wrong, and did not wish his children exposed to its influences.
“Grandmother Huggins was a sister of Rev. James Gilliland of
Red Oak, Ohio. She was a very earnest Christian, and often prayed
that her descendants, to the latest generation, might be honest,
humble followers of Jesus.
“Eliza was converted, and united with the church in Felicity,
Ohio, under the pastorate of Rev. Smith Poage. She was, I think,
about twelve years of age.”
She was a most loving daughter, sister, and friend, because she
had given herself unreservedly to Him who yearns to be more than
friend, mother, or brother to us all. When heavy bereavements came
upon the family, Jesus kept their hearts from breaking. The dear
father went the way of all the earth. Then a brother-in-law, who was
a brother indeed; then the elder brother, tried and true, in an instant
of time, speeds home to heaven; and again a younger brother, in his
bright youth; these three were the family’s offering upon the altar of
freedom. A costly offering! A heavy price paid! “Though he slay me,
yet will I trust in him.”
For seven years Miss Huggins taught school as continuously as
her health permitted. Her methods as a teacher were followed by
peculiar success. She loved children, and had a most earnest desire
to help them up to all that is best and wisest in life. Children know
by instinct whose is the firm yet loving hand stretched out to lead
them in the paths of pleasantness and peace. Some of this time she
taught in the mission school. Her sister says:—
“I cannot write of her long sickness, her intense suffering, her
patient waiting to see what the Lord had in store for her; all this is
too painful for me. St. Anthony, where she first came with such
bright hopes of finding health, was the place from which she went to
her long rest. It was the place where she found cure.
“The Dakota text-book, which she and Nannie prepared, was a
labor of much thought and prayer. It was not published until after
she had gone home.”
Mignonette and sweet violets may well be emblem flowers for
this lovely sister. Would that I might strew them on her grave, in the
early summer-time, as a farewell till we meet again.

NANCY JANE WILLIAMSON.

 BY M. R. M.

When an army marches on under fire, and one after another

falls by the way, the ranks close up that there may ever be an
unbroken front before the foe. So in life’s battle, as one by one
drops out of the ranks, we who are left must needs march on. Yet, if
we stop a little to think and talk of the ones gone, it may help us as
we press forward. Then, to-day let us bring to mind something of
the life of a sister departed.
Nannie J. Williamson was born at Lac-qui-parle, Minn., on the
28th of July, 1840. From her birth she was afflicted with disease of
the spine, so that she was almost two years old before she walked
at all, and then her ankles bent and had to be bound in splints.
“Aunt Jane” mentions that Nannie was in her fourth year when she
first saw her, and at that time, when the children went out to play,
her brother John either carried her or drew her in a little wagon, to
save her the fatigue of walking. So she must have truly borne the
yoke in her youth. That the burden was not lifted as the years went
by, we may judge from the facts that when away at school, both in
Galesburg, Ill., and Oxford, Ohio, she was under the care of a
physician; and she almost always studied her lessons lying on her
back.
Though her days were stretched out to her 38th year, her body
never fully ripened into womanhood, and her heart never lost the
sweetness and simplicity of the child. It was not so with her mind.
Overleaping the body, with a firm and strong grasp, it took up every
object of thought, and filled its storehouse of knowledge.
“The date of her conversion is not known. She loved Jesus from
a child.”
In the fall of 1854 our family moved to within two miles of Dr.
Williamson’s new station of Pay-zhe-hoo-ta-zee, or Yellow Medicine.
From that time we were intimately associated, and many delightful
memories are connected with those days. In September, 1857,
Nannie went to the W. F. Seminary at Oxford, Ohio. She made many
friends among her school-mates, and all respected her for her
consistent character, her faithfulness in her studies, and her
earnestness in seeking to bring others to Christ. One with more
thankful humility never lived. She was always so very grateful for the
least favor or kindness done her, and seemed ever to bear them in
mind. She was exceedingly thoughtful for other people, never
seemed to think evil of any one, and never failed to find kindly
excuses for one’s conduct if excuses were possible. After the burning
of the seminary building, the senior class, of which Nannie was one,
finished their studies in a house secured for that purpose. Then
followed the sorrowful days of ’62, that broke up so many homes,
ours among others. Some time after, Nannie wrote this: “It is a little
more than a year since we left our dear old homes. I wonder if our
paths will ever lie so near together again as they have in times past.
Who can tell? But though we may seem to be far apart, we trust we
are journeying to the same place, and we shall meet there.”
During the months that Nannie’s mother waited to be released
from earthly suffering, the daughter spared none of her strength to
do what she could for the faithful, patient mother. After there was
nothing more to do on earth for that mother, then indeed Nannie felt
the effects of the long strain on body and mind. Even then her
nights were painful and unresting. But, after recruiting a little, she
entered upon the work to which her thoughts had often turned, that
of uplifting the Dakota women and children. In 1873, “she joined her
brother, Rev. J. P. Williamson, in missionary labor, at Yankton agency,
Dakota Territory, under the Presbyterian Board of Foreign Missions,
and continued in it until her death, November 18, 1877.”
“Her knowledge of the Scriptures was such that the minister
scarcely needed any other concordance when she was by, and
during her last illness every conversation was accompanied with
Scripture quotations.
“Notwithstanding her physical weakness, she taught school and
did much other work; and, as all was consecrated to the Lord, we
are sure she has much fruit in glory. Many in the Sabbath-schools of
Traverse and St. Peter received lessons from her, whose impression
will last to eternity.”
 In the spring of 1876, she went to Ohio on the occasion of a
reunion of the first five graduating classes of the W. F. Seminary,
Oxford, Ohio. She desired with great desire to meet her class-mates,
and the beloved principal, Miss Helen Peabody; and also to visit
relatives, among them two aged aunts, one of whom crossed over to
the other side a little before her. She took great delight in her visit,
and yet her nights were wearisome, and she was probably not
entirely comfortable at any time. But she did not complain.
On her last visit home her face bore the impress of great
suffering. It was with difficulty she could raise either hand to her
head, and could only sleep with her arms supported on pillows. They
would fain have kept her at home, but she longed to do what she
could as long as she could. So she went back, taught in the school,
visited the sick, read from the Bible in the tents, and prayed. In her
last illness some of these women came and prayed with her, and so
comforted her greatly. She did not forget her brother’s children, in
her anxiety for the heathen around them, and they will long
remember Aunt Nannie’s prayerful instructions.
With so little strength as she had, it was not strange that, when
fever prostrated her, she could not rally again. So she lay for nearly
eight weeks, suffering much, but trusting much also. At times she
hoped to be able to work again for the women, if the Lord willed.
But when she knew that her earthly life was nearly ended, she sent
this message to her aunt: “Do not grieve, dear aunt, Though I had
desired to do much for these women and girls, the prospect of
heaven is very sweet.” For a while she had said now and then: “I
wonder how long I shall have to lie here and wait,” but one day she
remarked, “I do not feel at all troubled now about how long I may
have to wait: Jesus has taken that all away.” When any one came in
to see her, she said a few words, and as the school children were
gathered around her one day she talked to them a little while for the
last time. Two days before her death, she dictated a letter to her
father, who had himself been very near death’s door, but was
recovering: “I do rejoice that God has restored you to health again. I
trust that years of usefulness and happiness may still be yours. I am
gaining both in appetite and strength. I feel a good deal better.” But
the night that followed was a sleepless one, and the next day she
suffered greatly. About dark her brother said to her, “You have
suffered a great deal to-day.” She answered, “Yes, but the worst is
over now.” He said, “Jesus will send for you,” and she replied, “Yes, I
think he will, for he says, ‘I will that they also, whom thou hast given
me, be with me where I am.’”
She spoke now and then to different ones, a word or two, asked
them to read some Scripture texts from the “Silent Comforter” that
hung where she could always see it, wanted it to be turned over,
and, with her face to the wall, she seemed to go to sleep. She so
continued through the night, her breath growing fainter and fainter.
And at day-break on the morning of the Sabbath the other life
began. “That is the substance, this the shadow; that the reality, this
the dream.”

JULIA LA FRAMBOISE.

Julia A. La Framboise was the daughter of a French trader and

of a Dakota mother. When nine years of age, her father placed her in
Mr. Huggins’ family. In that Christian home she learned to love her
Saviour, and, one year later, covenanted forever to be his. Her father
was a Catholic, and would have preferred that his daughter remain
in that church, but allowed her to choose for herself. His affection for
her and hers for him was very strong.
After her father’s death, Julia determined to use her property in
obtaining an education. She spent two years in the mission school at
Hazelwood, then going to the W. F. Seminary, Oxford, Ohio, and for
a short time to Painesville, Ohio, and afterward to Rockford, Ill.
Having taken a full course of study there, she returned to Minnesota
as a teacher.
Our mother had a warm affection for Julia, as indeed for each of
the others of whom we write. Julia called our house one of her
homes, and, whenever with us, she took a daughter’s share in the
love and labor of the household.
 A story of my mother’s childhood illustrates the spirit of
benevolence by which she influenced Miss La Framboise among
others. Her surviving sister, Mrs. Lucretia S. Cooley, writes:—
“When the first missionaries from the vicinity of my early home,
Mr. and Mrs. Richards of Plainfield, went to the Sandwich Islands,
sister Mary was a little girl. She was deeply impressed by the story
of the wants of the children, as portrayed by Mr. Richards, and
expressed a strong desire to accompany him. She had just learned
to sew quite nicely. Looking up to mother, she said, ‘I could teach
the little girls to sew.’ Here was the missionary spirit. Those who go
to the Indians, to the islands of the sea, to Africa, must needs be
ready to teach all things, doing it as to the Lord.”
When the call to teach among her own people came, Miss La
Framboise gladly embraced the opportunity, laboring for them in
season and out of season for two short years. Her health failing, she
was taken to her old home in Minnesota, where she died, September
20, 1871, but twenty-eight years of age.
Mrs. Holtsclaw, one of her girlhood friends, went to her in that
last sickness. She wrote: “I was with her when she died. It was
beautiful to see the steady care and gentle devotion of her step-
mother, of the rest of the family, and of the neighbors.”
Miss La Framboise was thoroughly educated, thoroughly the
lady; always loyal to her people, even when they were most hated
and despised; always generous in her deeds and words; always to
be depended upon.
Oh, could we but have kept her to work many years for the
ennobling and Christianizing of the Dakotas!
Bring lilies of the prairie for this grand-daughter of a chieftain—
ay, more, this daughter of the King!
I. R. W.
 THE FAMILY REUNION.—1879.
Eighteen years had gone by since the family were all together
on mission ground. That was in the summer of 1861. In the summer
of 1858, Alfred had graduated at Knox College, Illinois; and Isabella
returned with him from the Western Female Seminary, Ohio. They
gladly arrived at home, in borrowed clothes, having trod together
“the burning deck” of a Mississippi River steamboat. All were
together then. That fall, Martha went to the Western Female
Seminary, and was there when the school building was burned in
1860. After that she came home, and Isabella went back to
graduate. In the meantime, Alfred had become a member of the
Theological Seminary of Chicago. And so it happened that all were
not at home again together until the summer of 1861. Then came
the Sioux outbreak, and the breaking-up of the mission home.
Though a new home was made at St. Anthony, and then at Beloit, it
never came to pass that all were together at any one time.
Then new home centres grew up. Alfred was married in June,
1863. Isabella was married in February, 1866, and very soon sailed
for China. Martha was married in December of the same year, and
went to live in Minnesota. The dear mother went to the Upper Home
in March, 1869. Alfred moved to the mission field at Santee Agency,
Nebraska, in June, 1870. Anna was married in October of the same
year and moved to Iowa. While Martha, the same autumn, removed
to open the Missionary Home at the Sisseton Agency. In May, 1872,
a new mother came in, to keep the hearthstone bright at the Beloit
home. In February of 1872, Thomas went to Fort Sully to commence
a new station, and was married in December of the same year.
Meanwhile Henry, Robert, and Cornelia were growing up to manhood
and womanhood, and getting their education by books and hard
knocks. Henry was married in September, 1878, and Robert was
tutor in Beloit College, and Cornelia a teacher in the Beloit city
schools.
At these new home centers children had been growing up. At
Kalgan, China, there were six; at Santee, Neb., five; at Sisseton, D.
T., four; at Vinton, Iowa, three, and at Fort Sully, D. T., one. Another
sister had also come at the Beloit home.
And now the Chinese cousins were coming home to the America
they had never seen. So it was determined that on their arrival there
should be a family meeting. But where should it be? Every home
was open and urged its advantages. But Santee Agency, Nebraska,
united more of the requisite conditions of central position and roomy
accommodations. And, besides, it was eminently fitting that the
meeting should be held on missionary ground. And so from early in
July on to September the clan was gathering.
First came Rev. Mark Williams and Isabella, with their six
children, fresh from China, finding the Santee Indian reservation the
best place to become acclimated to America gradually. Father Riggs
and Martha Riggs Morris, with three of her children, from Sisseton
Agency, arrived the 18th of August. On the 27th came Anna Riggs
Warner, with her three children, from Vinton, Iowa. Mother Riggs
with little Edna arrived on the 29th, from Beloit, Wis. Mr. Wyllys K.
Morris and Harry, their eldest son, came across the country by
wagon, and drove in Saturday evening, the 30th of August. Thomas
L. Riggs and little Theodore, with Robert B. Riggs, and Mary Cornelia
Octavia Riggs, and their caravan, did not arrive from Fort Sully until
Tuesday afternoon of the 2d of September. Alfred L. and Mary B.
Riggs, and Henry M. and Lucy D. Riggs were of course already there,
as they were at home, and the entertainers of the gathering.
Now the family were gathered, and this is the Roll:—
Stephen Return Riggs, born in Steubenville, Ohio, March 23,
1812; married, February 16, 1837, to Mary Ann Longley, who was
born November 10, 1813, in Hawley, Mass., and died March 22,
1869, in Beloit, Wis.
I. Alfred Longley Riggs, born at Lac-qui-parle, Minn., December
6, 1837; married June 9, 1863, to Mary Buel Hatch, who was born
May 20, 1840, at Leroy, N. Y.
Children: Frederick Bartlett, born at Lockport, Ill., July 14, 1865;
Cora Isabella, born at Centre, Wis., August 19, 1868; Mabel, born at
Santee Agency, Nebraska, September 11, 1874; Olive Ward, born at
Santee Agency, Nebraska, June 13, 1876; Stephen Williamson, born
at Santee Agency, Nebraska, April 28, 1878.
II. Isabella Burgess Riggs, born at Lac-qui-parle, Minn.,
February 21, 1840; married February 21, 1866, to Rev. W. Mark
Williams, who was born October 28, 1834, in New London, Ohio.
Children: Henrietta Blodget, born at Kalgan, China, September
25, 1867; Stephen Riggs, born at Kalgan, China, August 22, 1870;
Emily Diament, born at Kalgan, China, May 26, 1873; Mary Eliza,
born at Kalgan, China, August 3, 1875; Margaret and Anna, born at
Kalgan, China, May 30, 1878.
III. Martha Taylor Riggs, born at Lac-qui-parle, Minn., January
27, 1842; married December 18, 1866, to Wyllys King Morris, who
was born in Hartford, Conn., September 11, 1842.
Children: Henry Stephen, born at Sterling, Minn., June 21, 1868;
Philip Alfred, born at Good Will, D. T., August 4, 1872, and died at
Binghamton, N. Y., August 18, 1873; Mary Theodora, born at Good
Will, D. T., July 31, 1874; Charles Riggs, born at Good Will, D. T.,
June 21, 1877; Nina Margaret Foster, born at Good Will, D. T., May
30, 1879.
IV. Anna Jane Riggs, born at Traverse des Sioux, Minn., April 13,
1845; married October 14, 1870, to Horace Everett Warner, who was
born January 10, 1839, near Painesville, Ohio.
Children: Marjorie, born at Belle Plaine, Iowa, September 29,
1872; Arthur Hallam, born in Vinton, Iowa, October 28, 1875;
Everett Longley, born in Vinton, Iowa, July 15, 1877.
V. Thomas Lawrence Riggs, born at Lac-qui-parle, Minn., June 3,
1847; married December 26, 1872, to Cornelia Margaret Foster, who
was born in Bangor, Me., March 19, 1848, and died August 5, 1878,
at Fort Sully, D. T.
Child: Theodore Foster, born near Fort Sully, D. T., July 7, 1874.
 VI. Henry Martyn Riggs, born at Lac-qui-parle, Minn., September
25, 1849; married September 24, 1878, to Lucy M. Dodge, who was
born at Grafton, Mass., February 29, 1852.
VII. Robert Baird Riggs, born at Hazelwood, Minn., May 22,
1855.
VIII. Mary Cornelia Octavia Riggs, born at Hazelwood, Minn.,
February 17, 1859.
Stephen R. Riggs married, May 28, 1872, Mrs. Annie Baker
Ackley, who was born March 14, 1835, in Granville, Ohio.
IX. Edna Baker Riggs, born at Beloit, Wis., December 2, 1874.
The sons and daughters brought into the original family by
marriage contributed much to the success of the reunion. The
cousins will not soon forget the inimitable stories of Uncle Mark.
Horace E. Warner wrote a charming letter, proving conclusively that
he was really present; while Uncle Wyllys must have gained the
perpetual remembrance of the boys by taking them swimming. Mary
Hatch Riggs was the unflagging main-spring of the whole meeting.
Lucy Dodge Riggs presided hospitably at the “Young men’s hall,”
where many of the guests were entertained; and the new mother,
Annie Baker Riggs, won the love of all.
It would not have been a perfect meeting without seeing the
face of John P. Williamson, the elder brother of the mission. Then,
too, there was our friend Rev. Joseph Ward, whose home at Yankton
has so often been the “House Beautiful” to our missionary pilgrims.
We were also favored with the presence of many of our missionary
women: Mrs. Hall of Fort Berthold, Misses Collins and Irvine, from
Fort Sully, and Misses Shepard, Paddock, Webb, and Skea, of
Santee. The children will long remember the party given them by
Miss Shepard in the Dakota Home, and the picnic on the hill.
It is impossible to give any adequate report of such a reunion.
The renewal of acquaintance, taking the bearings of one another’s
whereabouts in mental and spiritual advance, is more through chit-
chat and incidental revelations than in any of the things that can be
told.
 And so we gather in as memorials and reminders some of the
papers read at the evening sociables, and some paragraphs from
reports of the reunion published in the Word Carrier and Advance.
First, we will have Isabella’s paper, the story of that long journey
home—By Land and by Sea:—

“Ding lang, ding lang, ding lang! Hear the bells. The litters
are packed, the good-bys spoken. Thirteen years of work in
sorrow and in joy are over. ‘Good-by. We will pray for you all; do
not forget us.’
“Down the narrow street, past the closely crowded houses
of more crowded inmates, beyond the pale green of the
gardens, on the stony plain, and our long journey is begun.
“Eight hours and the first inn is reached, we having made a
twenty-five-mile stage. Over rocks and river, fertile lake-bed;
desert plain, and through mountain-gorge, we creep our way,
till, on the fifth day, the massive walls of Peking loom up before
us.
“Here there are cordial greetings from warm hearts, and
willing hands stretched out to help. Best of all is the inspiration
of mission meeting, with its glad, good news from Shantung
Province.
“By cart and by canal boat again away. At Tientsin we ride
by starlight, in jinrickshas, to the steamer. How huge the
monster! How broad seems the river, covered here and yonder,
and again yonder, with fleets of boats!
“We ensconce ourselves in the assigned state-rooms, and
little Anna’s foster-mother keeps a vigil by the child so soon to
be hers no more. ‘Farewell, farewell.’
“Gray morning comes, and the ponderous engine begins his
work. We move past boats, ships, steamers, past the fort at
Taku, out on the open sea. No one sings, ‘A Life on the Ocean
Wave,’ or ‘Murmuring Sea,’ for our ‘day of youth went yesterday.’
The enthusiasm of early years is gone. Instead, I read
reverently the 107th Psalm, verses 23, 31. Then with the
strong, glad, spray-laden breeze on one’s face, it is fitting to
read, ‘The Lord on high is mightier than the noise of many
waters, yea, than the mighty waves of the sea.’ ‘Let the sea
roar, and the fullness thereof. Let the floods clap their hands ...
before the Lord.’ ‘The sea is his and he made it.’ ‘The earth is
full of thy riches. So is this great and wide sea. There go the
ships: there is that leviathan, whom thou hast made to play
therein.’
“Five days, and we steam up through the low, flat, fertile
shores of Woo Sung River to Shanghai.
“Ho for the land of the rising sun! Two days we sail over a
silver sea; yonder is Nagasaki, and now a heavy rain reminds us
that this is Japan. On through the Inland Sea. How surpassingly
beautiful are the green hills and mountains on every side.
“At Kobe we receive a delightful welcome from Mr. C. H.
Gulick’s family, and on the morrow we meet our former co-
laborer in the Kalgan work, Rev. J. T. Gulick. Ten days of rest,
and our little Anna is herself again. She is round and fair and
sweet, and every one laughingly says she is more like our
hostess than like me.
“Again away, in a floating palace, fitly named City of Tokio.
We glide out of sight of Japan, with hearts strangely stirred by
God’s work in that land.
“One sail after another disappears, until we are alone on
the great ocean. Water, water, water everywhere.
“Our days are all alike. Constant care of the children and
thoughts of home and beloved ones keep hand and heart busy.
The events of each day are breakfast, tiffin, and dinner, daintily
prepared, and faultlessly served by deft and noiseless waiters.
We think it a pleasant variety when a stiff breeze makes the
waves run high. The table racks are on, yet once and again a
glass of water or a plate of soup goes over. We turn our plates
at the proper angle, when the long roll begins, and
unconcernedly go on.
 “One day of waves mountain high, which sweep us on to
our desired haven. On the eighteenth day we see the shore of
beautiful America. How the heart beats! So soon to see father,
brothers, and sisters! Thank God. Aye, thank him too for the
manifold mercies of our journey.
“How strange and yet familiar are the sights and sounds of
San Francisco. The children’s eyes shine as they plan and
execute raids on a toy store.
“There is yet the land journey of thousands of miles. By
night and by day we speed on; across gorge, through tunnel
and snow-shed, over the alkali plains, over fertile fields to
Omaha.
“At last we arrive in Yankton, and a cheery voice makes
weary hearts glad. ‘I am Mr. Ward. Your brother Henry is here.’
Ah, is that Henry! How he has changed from boyhood to
manhood!
“‘Over the hills and far away.’ Here we are! How beautiful
the mission houses look! And the dear familiar faces! Rest and
home at last for a little while. ‘For here have we no continuing
city, but we seek one to come.’”

But journeying may be done much more quickly by thought, and

spirit may go as quick as thought. So here is the account of Horace
E. Warner’s thought journey to the family meeting:—

“If there has seemed to be any lack of interest on my part

in the family reunion, it is only in the seeming. For my decision
to stay at home was made with deep regret, and after the
slaying of much strong desire. But, aside from the gratification
which it would have given me to see you all, and which I hope it
would have given you to see me, I do not think the idea of the
meeting is impaired by my absence. Only this—I feel as though
I had, not wilfully nor willingly, but none the less certainly, cut
myself off from that sympathy—in the Greek sense—which I
stood in much need of, and can ill afford to miss.
 “I suppose you are now all together with one accord in one
place, so far as that is possible. To be all together would require
the union of two worlds. And this may be, too,—shall we not
say it is so? But if the dear ones from the unseen world are
present, though you can not hear their speech nor detect their
presence by any of the senses, can not you feel that I am really
with you in some sense too? Of course, the difference is great,
but so also the difference is great between the meeting of
friends in the natural body and the spiritual body. If the mind,
the soul, constitutes the man rather than the animal substances,
or the myriad cells which make up his physical organization,
why may not I leap over the insignificant barrier that divides us?
As I write, this feeling is very strong with me. It is vague and
indefinite, but yet it seems to me that I have been having some
kind of communication or communion with you. At all events,
my heart goes out strongly toward you all with fervent desire
that the meeting will be full of joy and comfort—of sweetest and
spiritual growth—the occasion of new inspiration, new courage,
new hopes. It is not likely that there can be any repetition of it
this side of the ‘city which hath foundations.’
“So the memories of this meeting should be the sweetest,
and should cluster thick around you in the years of separation.
This much I must perforce miss. For though I do truly rejoice in
your joys, and partake with you of the gladness of the meeting
after so long a time; yet it is only by imagination and sympathy
that I make myself one with you, and of this the future can
have no recollection.”

Now we will let others give their thoughts of the meeting, as it

seemed to them from outside. And, first, a few words from Rev.
John P. Williamson of Yankton Agency:—

“The first week in September, 1879, will long be

remembered by the Riggs family, and by one or two who were
not Riggses. From the east and the west, from the north and
the south, and from across the mighty Pacific, they gathered at
 the eldest brother’s house, at Santee Agency, Nebraska, for a
family reunion. It was forty-two years last February since
Stephen Return Riggs married Mary Ann Longley and came out
as a missionary to the Dakotas; and now in his sixty-eighth year,
his step still light, and his heart still young, he walks in to his
son’s house to find himself surrounded by nine children, three
sons-in-law, two daughters-in-law, and nineteen grandchildren;
with himself and wife making a company of thirty-five, and all
present except one son-in-law.
“This roll may never be as interesting to universal mankind
as that in the tenth chapter of Genesis, but it is almost
extended enough to evolve a few general truths. If we were to
pick these up, our first deduction would be that like begets like.
This man has certainly given more than his proportion of
missionaries. And why, except that like begets like? He was a
missionary, his children partook of his spirit, and became
missionaries. We heard some mathematical member of the
company computing the number of years of missionary service
the family had rendered. The amount has slipped our memory,
but we should say it was over one hundred and fifty.
“Our other deduction would be that the missionary
profession is a healthy one. Here is a family of no uncommon
physical vigor, and yet not a single death occurred among the
children, who are in goodly number. True, the mother of the
family has finished her work and crossed the river to wait with
her longing smile the coming children, but another ministers in
her room, who has added little Aunt Edna to the list, to stand
before her father when the rest are far away.”

Next, we have the observations of Rev. Joseph Ward of

Yankton:—

“Families have their characteristic points as well as

individuals. The family of Rev. S. R. Riggs, D.D., is no exception
to this. Their characteristics all point in one direction. It is
notably a missionary family. It began on missionary ground
Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.

More than just a book-buying platform, we strive to be a bridge

connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.

Join us on a journey of knowledge exploration, passion nurturing, and

personal growth every day!

ebookbell.com