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.