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, 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

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

Evolution 1988: X : 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 –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 tree which 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, 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