1 / 25

LDAP- Protocol and Applications

LDAP- Protocol and Applications. Role of LDAP. Allow clients to access a directory service Directories hold hierarchical structured information Clients may be directly controlled by individuals, embedded in applications, or “agents”

amandla
Download Presentation

LDAP- Protocol and Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. LDAP- Protocol and Applications

  2. Role of LDAP • Allow clients to access a directory service • Directories hold hierarchical structured information • Clients may be directly controlled by individuals, embedded in applications, or “agents” • LDAP can be used when integrating multiple directory services

  3. Advantages of LDAP • Global naming model ensures unique entries • Allows for multiple independent directories • Extensible to meet future / local requirements • Runs directly over TCP / IP and SSL • Has broad industry support • Based on existing deployed technologies

  4. Overview • Client-server architecture • Global tree of entries, each server holds a portion of the tree • Entry: set of attributes with distinguished name • Name: “cn=Mark Wahl,dc=critical-angle,dc=com” • Attributes: description, email address, photograph, etc • Operations • Bind: identify the client and optionally authenticate • Search: find entries in a portion of the tree matching a filter • Add, delete, modify, modify DN: modifies the tree • Extended operations: for application-specific functionality

  5. HTTP Client HTTP Client LDAP Client WWW-LDAP Gateway LDAP-X.500 Gateway LDAP Server X.500 Server X.500 Server Components

  6. Evolution • 1988: X.500 • 1992: Univ. Michigan starts developing LDAP • 1993: LDAP first published as RFC • 1995: Work begins on LDAPv3 specification • 1996: Final call on LDAPv3 drafts • 1997: LDAPv3 published as RFCs

  7. New in LDAPv3 • Referrals • Character sets • Schema definitions • Schema publication • Security features • Extended operation framework • Dynamic and paged search extensions

  8. LDAPv3: Referrals • LDAPv2 • Every server required to process any query • Based on initial use of LDAP as lightweight access to X.500 • LDAPv3 • Server may process query itself, or return a referral • Referral: set of URLs of other servers to contact • Multiple URLs can be included, in case servers are inaccessible • Servers can also rewrite queries for clients • Referral processing is done inside client library and can be transparent to applications

  9. LDAPv3: Character Sets • LDAPv2 only allowed for ASCII and T.61 • Based on legacy of X.500 environment • T.61 can represent only some Western European characters • LDAPv3: UTF-8 entry names and attribute values • UTF-8 is a variable-length encoding of ISO 10646 • ASCII characters are identical in UTF-8 • Unicode is a subset of ISO 10646

  10. LDAPv3: Schema Definitions • Schema • Aspects of a real-world object to be represented in entry • No schema defined for LDAPv2, but X.500 implied • LDAPv3 suggests: • X.500(1993): people and organizations • RFC 1274 updated: Internet-specific attributes • Vendor-defined schema • Netscape, Microsoft, Novell and others • Application and administrator-defined schema • For local requirements

  11. LDAPv3: Schema Publication • Schema is extensible attribute type names are not globally unique • Clients can check their semantic associations to an attribute type name match those of server • Clients also need way to discover new schema • LDAPv3 adds subschema subentries to the treewhich contain description and unique identifiers • Automatically maintained by servers themselves

  12. LDAPv3: Security • LDAPv3 can be carried over SSL • Provides connection authentication and confidentiality • SASL Bind • Allows negotiation of services (e.g. Kerberos or GSS-API) • Password encrypted with one-way hash • All servers must have a copy of client’s password • Suitable for environments with a single service • Strong authentication with digital signature • Servers need only have client’s public key (via certificate) • Suitable for environments with multiple services

  13. LDAPv3: Extension Framework • Extension • Supports adding new features to LDAP without disruption • Unique identifier, criticality, value • Server may ignore unrecognized non-critical extensions • Server rejects operation with unrecognized critical extensions • Client can check server’s supported extensions • Published in the directory tree in a special entry

  14. LDAPv3: Paged Search Results • Optional server feature • Server sorts result and caches it • Clients can request arbitrary pages (subsets) of a recently gathered result • Designed for UI clients: to support a user moving scrollbar around a long list of entries

  15. LDAPv3: Dynamic Refresh • Optional server feature • Client adds information to the directory, and requests that the server time it out • Server replies with time-to-live, based on its load • Client sends UDP / IP refresh operation to server • If client shuts down, server will delete information • Designed for mobile and dial-up clients

  16. Some Applications of LDAP • Internet applications • Centralized or distributed white pages • ISP on-line subscriber directory • Intranet applications • Internal white pages • Certificate and CRL distribution • System/network management database

  17. Applications: White Pages • For use by people through WWW gateways/clients • Telephone number, email address lookup • Can also return photos, spoken names, URLs • Naming and distribution model allows the directory to contain information from multiple organizations • PARADISE: over 1,000,000 entries maintained by Universities and research organizations • BigFoot, Four11, others provide LDAP access

  18. Applications: White Pages • Same data can be used by programs • Sendmail extension checks LDAP for addressing • Netscape, other WWW servers validate user • Directory synchronization: combining address databases from multiple mail systems

  19. Applications: Users Directory • Dynamic directory extension can be used where information is frequently changing • Microsoft NetMeeting and other clients will register user in directories of everyone on-line • Other people can search for that user, based on their name or other attributes • Terminal capabilities can be determined from directory before communication starts

  20. Applications: Certificates • Certificates and Revocation Lists are exchanged between components of Public Key Infrastructure • Users and Certification Authorities (CAs) identified by Distinguished Names, as used in LDAP • Programs can automatically retrieve this information from LDAP-capable directories • LDAPv2 could not handle certificates correctly; fixed in LDAPv3

  21. Application: System Database • LDAP can be used to access directories of network components (servers, printers, etc) • Novell has a gateway from LDAP to NDS • Directories can also be built with other general-purpose servers

  22. Implementations • Few LDAPv3 implementations available • Critical Angle, Zoomit; and others • LDAPv2 implementations: • Servers • Clients • Client libraries • Gateways to LDAP • From HTTP, Ph / CCSO, whois++, X.500 • Gateways from LDAP • To X.500, NDS • Firewalls

  23. Some Implementations • Clients • Univ. Michigan, Microsoft, Netscape Communicator • Client libraries • C (RFC 1823), Java, Perl, Visual Basic, Tcl • General-purpose servers • Most X.500 servers support LDAP • Netscape: LDAP-only Directory Server • Univ. Michigan, Critical Angle: free SLAPD • Single-purpose servers • Provide LDAP view onto existing data structure • Often not able to handle modifications or extensions

  24. Future Directions • Replication and Indexing • Currently replication between servers not standardized • Replication will be defined using existing LDAP operations • Centroids: make wide-area searches more effective • Standard Access Control • Unless two vendor’s servers implement access control in the same way, cannot replicate sensitive information • Currently only X.500 servers have a common model • Additional Schemas • Applications will take advantage of directory infrastructure

  25. Conclusions • LDAP is key to the directory infrastructure • LDAP will be used by many services, just like TCP and DNS are today • LDAPv3 implementations are coming • Be sure directory servers are suited for the service being deployed

More Related