LDAP - Internet Engineering - Lecture Slides, Slides of Internet and Information Access

Download LDAP - Internet Engineering - Lecture Slides and more Slides Internet and Information Access in PDF only on Docsity!

LDAP

Contents

• Introduction
• Protocol
• Architecture
• Operations
• Schemas

Directories

• A directory is a listing of information about objects arranged in some order that gives details about each object.
• Common examples are a city telephone directory and a library card catalog.
• In computer terms, a directory is a specialized database, also called a data repository, that stores typed and ordered information about objects.
• A particular directory might list information about printers (the objects) consisting of typed information such as location (a formatted character string), speed in pages per minute (numeric), print streams supported (for example PostScript or ASCII), and so on.

Directory vs Database

• A directory is often described as a database
• But it has special characteristics different from general databases: - They are accessed much more than they are updated. Hence they are optimized for read access - They are not suited for information that changes rapidly (e.g. number of jobs in a printer queue) - Many directory services don’t support transactions - Directories normally limits the type of information that can be stored - Databases use powerful query languages like SQL but Directories normally use very simple access methods - Hence directories can be optimized to economically provide more applications with rapid access

Strengths/Limitations

• LDAP is well suited for

• Information that is referenced by many entities and applications
• Information that needs to be accessed from more than one location - Roaming, e.g. by “Road Warriors” - Preference information for web “portals”
• Information that is read more often than it is written

• LDAP is not well suited for

• Information that changes often (it is not a relational database)
• Information that is unstructured (it is not a file system)

LDAP protocol

• A message protocol used by directory clients and servers.
• It defines several messages like bindRequest and searchRequest
• There is LDAP API to be used by C and Java programs
• With Microsoft it can by accessed via ADSI
• All modern LDAP servers are based on LDAP version 3.
• Clients and servers may or may not be on the same machine

Directories advantages

Directory structure

Distinguished Names

• Each object in the LDAP directory has a DN
  • uid=jheiss,ou=people,dc=example,dc=com
  • cn=users,ou=group,dc=example,dc=com
• Notice that the DNS name is example.com (specified by DC=Domain Component entries) for the domain
• OU is organizational unit
• Each domain subdomain could create a tree structure in LDAP (engr.example.com, sales.example.com, pre.engr.example.com, support.engr.example.com, etc)

Sample New York Directory Information Tree

ou=DOH

cn=OFT Administrators cn=Ethics App Users cn=Ethics App Administrators

ou=Groups uid=bdigman uid=jnortrup uid=dstrazzeri

ou=People cn=1B Floor Postscript Printer cn=Conference Room 1B-A

ou=Resources cn=OFT Portal cn=Ethics Application

ou=Applications

ou=OFT ou=TAX

o=NY,c=US

• Branched by agency
• Agencies in this example have branches containing:
  • Groups which contain people
  • People in the organization
  • Resources such as printers and conference rooms
  • Applications (where application specific info. could be maintained)

Sample DIT

ObjectClass

• A commonly used attribute is "objectClass".
• Each record represents an object, and the attributes associated with that object are defined according to it's objectClass - The value of the objectClass attribute.

Object Type examples

• Examples of objectClass:
  • organization (needs a name and address)
  • person (needs name, email, phone & address)
  • course (needs a CRN, instructor, mascot)
  • cookie (needs name, cost & taste index)

Multiple Values

• Each attribute can have multiple values, for example we could have the following record:

DN: cn=Dave Hollinger, O=RPI, C=US CN: Dave Hollinger CN: David Hollinger Email: [email protected] Email: [email protected] Email: [email protected]

Directory Information Flows

o=NY,c=US ou=TAXl=New York City ou=NYSOFT ou=DCJSou=DOH

o=NY,c=US OU=TAX

NYT Master Supplier

Master Supplier^ Tax & Finance Replication Master

Replication from Tax& Finance Server toNYT Master DOH Legacy Sytem DOH Information inProprietary Format

placed in NYT Master Supplier^ CDIF converted to LDAP and Common Directory^ DOH Informationsent to OFT in Interchange Format(CDIF)

Full tree replicated fromMaster Supplier toReplication Master

o=NY,c=US Tax & Finance Consumer o=NY,c=US ou=TAXl=New York City ou=NYSOFT ou=DCJSou=DOH

ou=TAXl=New York City ou=NYSOFT ou=DCJSou=DOH

NYT Replication Consumer o=NY,c=US ou=TAXl=New York City ou=NYSOFT ou=DCJSou=DOH

Full tree replicatedfrom ReplicationMaster to User throughout NYTDirectories

Full tree replicatedMaster to Agencyfrom Replication User Directory