LDAP Protocol and Applications Role of LDAP Allow

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” • 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 DN: modifies the tree Extended operations: for application-specific functionality

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

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

New in LDAPv 3 • • Referrals Character sets Schema definitions Schema publication Security features Extended operation framework Dynamic and paged search extensions

LDAPv 3: Referrals • LDAPv 2 – Every server required to process any query – Based on initial use of LDAP as lightweight access to X. 500 • LDAPv 3 – 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

LDAPv 3: Character Sets • LDAPv 2 only allowed for ASCII and T. 61 – Based on legacy of X. 500 environment – T. 61 can represent only some Western European characters • LDAPv 3: 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

LDAPv 3: Schema Definitions • Schema – Aspects of a real-world object to be represented in entry – No schema defined for LDAPv 2, but X. 500 implied • LDAPv 3 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

LDAPv 3: 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 • LDAPv 3 adds subschema subentries to the tree which contain description and unique identifiers • Automatically maintained by servers themselves

LDAPv 3: Security • LDAPv 3 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

LDAPv 3: 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

LDAPv 3: 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

LDAPv 3: 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 entries maintained by Universities and research organizations • Big. Foot, Four 11, 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 Net. Meeting 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 • LDAPv 2 could not handle certificates correctly; fixed in LDAPv 3

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 generalpurpose servers

Implementations • Few LDAPv 3 implementations available – Critical Angle, Zoomit; and others • LDAPv 2 implementations: – – Servers 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 • LDAPv 3 implementations are coming • Be sure directory servers are suited for the service being deployed