Directories and LDAP
What is a Directory?
- Yellow pages
- Personal phone/address book
- Mail order catalogs
- Library catalog cards
- TV Guides
- Your organization’s mailing list
- Netscape’s HTML directory
What is NOT a Directory?
- Database: more costly, heavy-duty transaction support, frequent writes
- File system: allows partial retrieval, random access of data
- Web servers: delivers big image files, provides web application development
platform
- FTP servers: can’t do search, not attribute-based information model
- DNS servers: not extensible, no updates
Types
Types of (Network) Directories
- NOS-based: MS Active Directory (with LDAP core), Novell NDS
- Application-specific: Lotus Notes Address Book, MS Exchange Directory
- Purpose-specific: DNS
- General-purpose, standards-based: LDAP, X.500 directories
Characteristics of Directories
Characteristics of Directories
- Good at storing pointers to large data, not the large data
- Attribute-based information model
- High read-to-write ratio, unlike databases, file systems, or web browsers
- High search capability
- Standards-based access (for some)
Evolution of Directories
FIGURE
Directory Services and Organizations
The Nerve Center of an Organization’s Infrastructure?
- Naming: who/what are there?
- Location: where are they?
- Security: protect against unauthorized access and tempering
- Management: personnel, decision- making
- Resource: monitor load and usage
- Extensibility: grow with the organization
So what is LDAP, exactly?
- LDAP: Lightweight Directory Access Protocol
- Preceded by the two X.500-related protocols: DAS, DIXIE (front ends)
- “Lightweight”: simplified encoding methods, runs directly on commonly
available TCP/IP
- “Heavyweight”:X.500DAPuses complex encoding methods, runs on rare OSI
network protocol stack
- Simplified implementation of clients and servers by eliminating infrequent
and redundant DAP features/operations
- Data elements represented as simple text strings, while messages wrapped in
binary encoding for efficiency
- Uses a subset of the X.500 encoding rules to further simplify implementation
- Simplified transport: no need for OSI, runs directly over TCP.
- Supports both IPv4 and IPv6.
Early LDAP Implementations
FIGURE
SLAPD: Stand-alone LDAP Daemon
- Multi-platform LDAP directory server
- Flexible customization
- Support for both LDAPv2 and LDAPv3
- Support for both IPv4 and IPv6
- Simple Authentication and Security Layer
- Transport Layer Security through SSL
- Generic modules API: covers development for front-end communication with
LDAP client, and back-end database operations with Perl, Shell, SQL, TCL,
and Python
SLAPD: Continued
- Access control based on LDAP authorization information, IP address, domain
name, etc.
- Support for Unicode and language tags
- Choice of various backend databases
- A multi-threaded slapd process can handle all incoming requests => reduced
system overhead => higher performance
- Replication of data using single-master multiple-slave scheme for
high-volume environments
- Highly configurable via a single configuration file that “does it all”
LDAP Client-Server Exchange Protocol
FIGURE
Example LDAP Usage
- A directory service that enables a user to locate remote resources ANYWHERE
on a distributed network.
- A dynamic system that provides/fetches resources based on individual user’s
queries.
- A model that would utilize and manage the existing system in a more
organized way.
- Examples:”OmniPrint” service from anywhere on the network, location and
availability of a coffeemaker!
- A robust and extensible client-server model
- Application needs: data elements, service performance (latency, throughput,
e.g., 480K searches per hour)
- User needs: accuracy, privacy, up-to-date, completeness, security, balance
for all users
- Extensibility: Must be able to extend to distributed and replicated models
- Platforms supported: Should accommodate heterogeneous platforms
Schemas
- Similar to databases, needed for integrity and quality
- A set of rules that determines what can be stored in a directory service
- A set of rules that defines how directory servers and clients should treat
information during a directory operation
- Each entity (called “attribute”) has its own object identifier (called an
oid)
- Reduce unnecessary data duplication resulted from some directory-enabled
applications
attributes and objectclasses
The following shows how to create your own schema in LDAP (for our example
fictitious domain):
description ATTRIBUTE ::= {
WITH SYNTAX DirectoryString {1024}
EQUALITY MATCHING RULE caseIgnoreMatch
SUBSTRINGS MATCHING RULE caseIgnoreSubstringsMatch ID 2.5.4.13
}
objectclass printer
requires cn
allows description, pagesPerMinute, languages
objectclass networkDevice
requires ipaddress
allows cn, connectionSpeed
Note: the term objectclass is not the same terminology from object-oriented
programming. In LDAP, an objectclass defines a schema-aware data object but
does not define methods (functions) as in OOP.
Namespaces
- Means by which information in the directory will be named and referenced,
similar to a pointer or label (or index).
- Namespace can be of any topology, e.g. tree, star, triangular, or linear.
LDAP supports trees innately.
- Concept of DN and its components: CN, C, ST, L, O, OU, STREET, DC, UID
- Naming scheme could be internet-based or traditional, based on
organizational needs
Here’s an example of a DN:
ou=cpdc,ou=ece,ou=northwestern,ou=edu, c=evanston,st=illinois,c=us
Traditional (Internet-style) naming:
CPDC.ECE.McCormick.Northwestern.Evanston.IL.US
Which is better?
LDAP Tree Topology
FIGURE to show the distinguished name concept.
Network Architecture
FIGURE
Distributed LDAP Server Model
FIGURE
LDIF Example
dn: uid=lt412-p3,ou=People,dc=cs,dc=luc,dc=edu
uid: lt412-p3
cn: LT 412 P3 Lab
givenName: LT 412 P3
sn: Lab
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}$1$/I5v6ig6$aDHu3Idj8i98kb9XVHlvq0
shadowLastChange: 12695
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 1012
gidNumber: 250
homeDirectory: /homes/users/lt412-p3
gecos: LT 412 P3 Lab
Acknowledgements
The notes in this lecture are based on a presentation co-authored with
Dr. Thiruvathukal’s former students in Distributed Systems (at Northwestern
University), Steve Chiu and
Jay Pisharath.
References
- http://openldap.org
- T. Howes et. al., Understanding and Deploying LDAP Directory Services,
MacMillan Technical Publishing, 1999
- LDAP bindings are provided in many languages, such as Python and Java.
OpenLDAP provides C bindings.