250 likes | 288 Views
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”
E N D
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
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
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
HTTP Client HTTP Client LDAP Client WWW-LDAP Gateway LDAP-X.500 Gateway LDAP Server X.500 Server X.500 Server Components
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
New in LDAPv3 • Referrals • Character sets • Schema definitions • Schema publication • Security features • Extended operation framework • Dynamic and paged search extensions
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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