LDAP Notes

 

Overview

* LDAP defines a protocol for
accessing directory data
representing data in directory service
imp/exp data in directory service (ldif format)
* LDAP does not define
– how data is stored
– how data is manipulated

Four Models (FINS)

* Functional model: how to access LDAP
* Information Model: how to represent information aka data (not how to store data)
* Naming model: for example, dc=example,dc=com
* Security model:

LDAP Advantages

* Write-once-read-many-times
* Standardized method for local as well as remote ldap access
– Data can be delegated to multiple locations
* Can be configured to replicate data (like DNS)

LDAP Disadvantages

* Updates are expensive (due to indexing)
* Not for transaction activities (may contain data inconsistencies)

Object or Data Model

Data Information Tree (DIT)

* LDAP represents data as a hierarchy of objects, like a tree:
– has a root
– has branches (entries)
– has leaves (objectClasses)
– each leave (i.e. objectClass) has cells (attributes)
– cell (i.e. attribute) is where data is stored

Schema

* Convenient packaging unit for a group of objectClasses and attributes
* Think of it as different type of trees such as oak tree, willow tree, fir tree, etc.

Entries

* Must contain one, and only one, STRUCTURAL objectClass
* May contain one ABSTRACT objectClass
* May contain any number of AUXILIARY objectClasses
* May have parent, and/or child, and/or sibling entries

ObjectClass

* Used as a container for attributes
* Has a OID
* Has a name
* Is searchable
* Defines if an attribute is optional or mandatory
* Can be part of hierarchy:
– the whole hierarchy must be of the same type, i.e. STRUCTURAL or AUXILIARY
– inherits all characteristics of its parent ObjectClasses

ObjectClassDescription = "(" whsp
  numericoid whsp      ; ObjectClass identifier
  [ "NAME" qdescrs ]
  [ "DESC" qdstring ]
  [ "OBSOLETE" whsp ]
  [ "SUP" oids ]       ; Superior ObjectClasses
  [ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]
					   ; default structural
  [ "MUST" oids ]      ; AttributeTypes
  [ "MAY" oids ]       ; AttributeTypes
whsp ")"

Attribute

* Has a OID
* Has a name
* Is searchable
* May be part of hierarchy
– inherits all properties of its parents
* Can have aliases or abbreviations, e.g. cn for commomName
* Usually contains data
– has a data type
– defaults to allow multiple values
* Always associated with one or more ObjectClasses
* Can be either optional or mandatory for associated ObjectClass
* No primary key, one or more attributes are used to identity a unique entry. Like database combination keys and are called naming attributes or relative distinguished name (RDN) in LDAP.

AttributeTypeDescription = "(" whsp
    numericoid whsp              ; AttributeType identifier
  [ "NAME" qdescrs ]             ; name used in AttributeType
  [ "DESC" qdstring ]            ; description
  [ "OBSOLETE" whsp ]
  [ "SUP" woid ]                 ; derived from this other
				 ; AttributeType
  [ "EQUALITY" woid              ; Matching Rule name
  [ "ORDERING" woid              ; Matching Rule name
  [ "SUBSTR" woid ]              ; Matching Rule name
  [ "SYNTAX" whsp noidlen whsp ] ; see section 4.3
  [ "SINGLE-VALUE" whsp ]        ; default multi-valued
  [ "COLLECTIVE" whsp ]          ; default not collective
  [ "NO-USER-MODIFICATION" whsp ]; default user modifiable
  [ "USAGE" whsp AttributeUsage ]; default userApplications
  whsp ")"

LDAP Referrals

* Similar to DNS referrals in concept
* No server auto referrals defined in standards
– Some vendors, e.g. OpenLDAP, use chaining for auto referrals
* Referrals are returned to client instead

LDAP Replication

* Built in replication to allow one or more copies of DIT (not whole LDAP) to be slaved from a single master
* Takes time to replicate (potential data inconsistencies)
* Master-Slave replication:
– slaves are read only copies of the master
– master server is single point of failure
* Multi-Master replication:
– Data contentions: value contention and delete convention
* Example replication configurations:

Matching Rules

* Part of LDAP operational
* Typicall built-in to the LDAP server and defined in subschema
* A matching rule is defined for each attribute using
– EQUALITY
– SUBST
– ORDERING

Operational Attributes and Objects

* Build in attributes and objectClasses
* Governs how LDAP server functions
* Live under rootDSE
* Not visible during normal operations

* From ldapsearch:

# note the + returns operational attributes
ldapsearch -h localhost -p 1389 -x -s base -b "" +

References

* LDAP for Rocket Scientists
* OpenLDAP Glossary
* RFC 2252: Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions

This entry was posted in ldap and tagged . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *


*

This site uses Akismet to reduce spam. Learn how your comment data is processed.