Notes

Outline

LDAP Overview Bruce Greenblatt, Ph. D Directory Tools and Application Services, Inc.

Agenda LDAP History Structure of LDAP Data Standard LDAP Protocol LDAP Protocol Extensions LDAP Programming (in Java)

What’s a Directory? A directory is a service the primary goal of which is to provide a property based information retrieval system It can do other things as well Examples: DNS, NIS, Whois, LDAP, X.500, NDS, Finger, ...

What’s in a Directory Some directories store information about specific types of objects DNS stores information about Internet Hosts Finger stores textual information about Internet users Other directories are generic: LDAP & X.500 allows storage of virtually anything

Technology Timeline

Distribution Timeline

Device Timeline

Mainstream Implementations Netscape Directory Server 4.0 Novell Directory Services: in NetWare 5.0 NDS on NT (a.k.a. eDIrectory) Microsoft Active Directory in Windows 2000

Product Features Replication Synchronization Strong Authentication Access Control Extensible Schema Reliability Scalability Compatibility/Interoperability Repository Versatility and Flexibility Integrated Administration Location Independence

NDS (Novell) ± Integrated and included with NetWare Networks NT version No large objects (> 64k) from LDAP Distribution/Synchronization time tested Proprietary GQ authentication Now fully LDAP compliant (NetWare 4.11) NetWare 5 claims LDAPv3

Netscape DS ± No network integration NT and many Unix implementations No size restrictions Distribution/Synchronization via LDAP TLS support for strong authentication Fully LDAP v2/v3compliant LDAP inventors

Active Directory (Microsoft) ± Integrated and included with Windows NT/2000 Networks Not cross platform Kerberos authentication Claims LDAPv3 compliant Uses “dc” naming

What’s in a Name Each entry in a directory has a unique name Directory entries are typically organized hierarchically Entries have parents, children and peers The collection of all the names in the directory is the “namespace”

DNS Namespace

LDAP Namespace

LDAP Namespace (cont.) Portions of the LDAP Namespace are contained on each LDAP Server Some servers cooperate to provide the same portion These portions of the namespace are sometimes called partitions.

LDAP Namespace (cont.) Each entry on an LDAP server is uniquely identified server by its distinguished name (DN) Example DNs: ou=sales, o=acme, c=us o = ibm, c = us cn = bruce, o = dtas, o = internet o = sales, dc = microsoft, dc = com

LDAP Namespace (cont.) In X.500, the theory is that each DN is globally unique All X.500 servers cooperate to find the appropriate server that holds the name in question In LDAP, the theory is that the combination of the LDAP host plus the DN are globally unique

LDAP Replication

LDAP Replication No Internet Standard for Directory replication Can use LDAP itself to copy data from server to server Proprietary Mechanisms NDS and Microsoft Domains/Sites X.500 DISP IETF CIP

LDAP URL Provide a way to specify the combination of a host name and a DN ldap://ldap.canon.com/o=canon,c=us ldap:///o=University%20of%20Michigan,c=US

LDAP Protocol (cont.) LDAP operates between a client and a server LDAP client makes request LDAP server implements them are returns results

LDAP Protocol (cont.)

LDAP Protocol (cont.) Operations use LDAPMessage construct. Its fields are: Operation Id (as ASN.1 Application Tag) Operation dependent Data Control Extension

LDAP Protocol (cont.) Operation results use the LDAPResult construct Its fields are result code matched DN error message referral (as LDAP URL)

ASN.1 All LDAPMessages and LDAPResults are encoded using ASN.1 ASN.1 is the ITU’s mechanism of defining the language that its peer entities use to communicate across a data communications network.  ASN.1 defines not only the type of data that is used in communications, but also the mapping of the data layouts into the binary network order. E.g., the integer 100 is encoded in ASN.1 as the hex value: 02 0001 64 Each ASN.1 encoded object consists of a type, a length and a value

ASN.1 (Cont.) LDAP DNs are encoded as strings.  E.g. 04 14 “OU=Sales, O=Acme, C=US” X.500 DNs aren’t.  E.g.

LDAP Connection Operations Bind allows the User (I.e. LDAP Client) to identify itself to the LDAP Server Unbind ends the authentication session between the client and the server

LDAP Lookup Operation All reading of information from the LDAP is done using the Search operation Three types of search scope Single object search Container level search Subtree search

Changing the Directory Information Information in the directory is changed using: Add Delete Modify ModifyDN

Other LDAP Operations Abandon cancels a previously issued operation Compare compare a presented attribute and value to something in LDAP ExtendedReq allows new operations to be defined

LDAP History Simplified version of X.500 DAP First version of X.500 completed in 1988 massive revision completed in 1993 Virtually no commercial implementation DOD funded study of ways to simplify X.500

LDAP History (cont.) RFC 1487 defines LDAP v1 (July 1993) RFC 1777 defines LDAP v2 (March 1995) RFC 2251 defines LDAP v3 (December 1997)

LDAP vs X.500 DAP LDAP Protocol maps directly to TCP (or TLS) LDAP Attribute Types are strings, where DAP uses binary OIDs Most protocol elements are strings as well LDAP uses SASL (RFC 2222) for its authentication LDAP uses more lightweight ASN.1 encoding

LDAP vs. DAP (cont.) LDAP Internationalization of Strings done through UTF-8 LDAP relies on the referral model, while DAP relies on the chaining model LDAP servers tend to operate independently, while DAP servers cooperate to present a single, global view of the directory information

LDAP Objects Every entry in LDAP is a member of a certain structural object class An object class gives the list of mandatory and optional attributes for each object of that class LDAP Object Classes are either; Structural, Abstract or Auxiliary

Object Class Examples ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass ) ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn )     MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) ) ( 2.5.6.15 NAME 'strongAuthenticationUser' SUP top AUXILIARY     MUST userCertificate )

LDAP Attributes Mandatory attributes are present in every entry Optional attributes are often missing in some entries Most attributes can be present more than once in an entry e.g. telephoneNumber

Attribute Examples ( 2.5.4.0 NAME 'objectClass' EQUALITY objectIdentifierMatch      SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) ( 2.5.4.41 NAME 'name' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) ( 2.5.4.3 NAME 'cn' SUP name ) ( 2.5.4.6 NAME 'c' SUP name SINGLE-VALUE )

LDAP Authentication LDAP Bind supports several authentication mechanisms Anonymous Simple Protected (simple over SSL) Strong (via SASL)

LDAP Bind

Bind Result

Encoding the Bind Request An anonymous bind might be encoded as:

Encoding the Bind Request (cont.) Here’s a simple bind

Encoding the Bind Response A successful Bind would yield this response from the server

Encoding the Bind Response (cont.) If the server rejects the bind, it responds with

Strong Authentication with SASL SASL option in Bind Requst allows for strong authentication techniques (Choice is “3”) ServerSaslCreds in Bind Response allows for back and forth exchange of Bind information saslBindInProgress result code allows for multiple exchanges

Challenge Response Authentication The client contacts the server in order to authenticate The server responds with some string of bytes, possibly including a randomly generated byte sequence.  This string of bytes is known as the “challenge”. The client combines its password with the server’s challenge in a special way that is defined by the Challenge response mechanism, and sends this combination back to the server.  This combination is known as the response. The server examines the response to determine if it confirms that the responding client has knowledge of the password of the user that is attempting the authentication.

CRAM-MD5 Challenge Response SASL Mechanism Defined in RFC 2195 for IMAP authentication Can be used for LDAP Authentication as well Simple to implement on small footprint devices

CRAM-MD5 The data encoded in the server’s challenge contains a presumptively arbitrary string of random digits, a timestamp, and the fully-qualified primary host name of the server. The client makes note of the data and then responds with a string consisting of the user name, a space, and a 'digest’, computed using a variant of MD5.

CRAM MD5 (cont.) The original IMAP version S: * OK IMAP4 Server C: A0001 AUTHENTICATE CRAM-MD5 S:+PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+ C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw S: A0001 OK CRAM authentication successful In LDAP: A Bind choice 3 is used, with a DN, but empty parameters Server responds with SaslBindInProgress result code, and challenge Client does another bind, with the same choice, the same DN, and the appropriate response to the challenge Server responds with success or failure

LDAP Unbind Always encoded the same way No response

LDAP Search Most used LDAP operation

Search Parameters Base Object where to start the search Scope how much of the LDAP tree to search Filter which LDAP entries to return Attributes which pieces of the entry to return

Aliases An alias is a directory entry that “points” to another directory entry

Dereferencing Aliases The derefAlias field tells how the LDAP server should treat aliases that it encounters in the search If a server dereferences an alias object then this means that when an alias is encountered in a search result then the object or objects named by the alias’s aliasedObjectName attribute are substituted in the search result in place of the alias object.

LDAP Filters

LDAP Filters Allow for arbitrarily complicated matching rules Allow for new types of matching to be defined Only match against “whole” attributes If any value in a multi-valued attribute matches the filter, then the entry is returned in the search result

Encoding the Search

Matching Rules In the previous search, the filter was “objectClass = person” All entries in LDAP have more than one object class Any entry that matches this filter will have at least two object classes: top person

Matching Rules (cont.) Find all people with email addresses (&(“objectClass = person”) (“mail” present)) Find all people with email addresses in either sales or marketing: (&(“objectClass = organizationalPerson”) (“mail” present) (|(“ou = sales”) (“ou = marketing”)) an and filter with three filter elements, one of which is a nested or filter

Search Results In LDAP v3, the successful results of a search are returned in: SearchResultEntry SearchResultReference SearchResultDone Each matching entry is returned in a separate SearchResultEntry

Referrals In LDAP, if the LDAP server has reason to believe that another server can better handle the Search, it can refer the client to another server The server returns the referral (10) result code, and fills in an LDAP URL in the optional referral field alternatively, it can return a searchResultReference as a member of the search result list

Referrals (cont.)

Common Search Errors timeLimitExceeded (3) – The amount of time specified in the Search request has passed without the LDAP server being able to complete the search.  The client should resubmit the search with a larger timeLimit, or with a more refined filter sizeLimitExceeded (4) – The number of entries that the server found that match the specified server filter was more than the number of entries specified in the sizeLimit field of the Search request.  The number of entries returned is equal to the value specified in the sizeLimit field noSuchAttribute (16) – This is an indication that one of the attributes requested in the Search Request is not available for this object (or object class) noSuchObject (32) – This is normally an indication that the specified search base is unknown to this LDAP server

Creating Entries The LDAP Add operation is used to create new entries in the directory

Changing Entries One entry at a time can be changed with the Modify operation

LDAP Modify Replace suboperation works even if the entry does not yet have values for the indicated attribute this is good for template updates also for “last access time” updates safer than add suboperation Delete suboperation with no values removes all attribute values Mandatory attributes can’t be removed

Out with the Old Entries are removed from LDAP via the Delete operation It works on one entry at a time! To delete a subtree, first do a subtree search, and delete each entry found in the subtree.

Results The result of the Add, Modify and Delete operations are just LDAPResults

Common Errors InsufficientAccessRights (50) - This error is returned if the identity specified in the Bind does not have the necessary privileges to perform the specified change to the DIT. ObjectClassViolation (65) – This error is returned when a change to an entry has been attempted that would result in missing mandatory attributes.  It may also be returned when an attribute is specified for addition to an entry that is not available for that object class. EntryAlreadyExists (68) – This error is returned when an Add operation specifies an entry’s DN that already is present in the DIT. NoSuchObject (32) – This error is returned when a Modify or Delete operation specifies an entry’s DN that can’t be found in the DIT.

Matched DN The Matched DN field in the LDAPResult is included in the Add result In the event of an unsuccessful Add, the matchedDN field indicates the lowest point in the tree that the server could find For example, if the client attempted to add   "CN=JS,O=Foo,C=US", the "O=Foo,C=US" entry did not exist, and the   "C=US" entry did exist, then the server would return the error   noSuchObject with the matchedDN field containing "C=US".

Less Used Operations ModifyDN move an entry from one place in the tree to another Compare compare a supplied attribute and value to that of an entry in the directory Abandon cancel an outstanding operation

LDAP Extensibility Controls allow virtually any parameter to be added to an existing operation Extended operations allow new operations and results to be defined Server supported extensions can be looked up in RootDSE object

Controls Supplied in the control parameter of the LDAPMessage construct Examples: Sort Control Paged Results Signed operations

LDAP Operation Format The format of an LDAP Operation is: LDAPMessage ::= SEQUENCE { messageID       MessageID, protocolOp      CHOICE { bindRequest     BindRequest, bindResponse    BindResponse, … } controls       [0] Controls OPTIONAL } Controls ::= SEQUENCE OF Control Control ::= SEQUENCE { controlType             LDAPOID, criticality             BOOLEAN DEFAULT FALSE, controlValue            OCTET STRING OPTIONAL }

Sort Control Allows results of the search to be returned in a client specified order Currently in last stages of draft

Signed Operations Control Allows LDAP client to digitally sign operations that change the DIT Integrity of the connection is normally provided by TLS Main goal is to allow for the provision of an audit trail for each directory entry Defined in RFC 2649

S/MIME Internet Standard for Secure Exchange of Electronic Mail actually the secure exchange of MIME objects Based on the PKCS #7 Standard and the MIME Recommendation Current revision is S/MIME v2 (S/MIME v3 is still in draft status)

MIME MIME defines the format of messages to allow for: textual message bodies in character sets other than US-ASCII an extensible set of different formats for non-textual message bodies multi-part message bodies textual header information in character sets other than US-ASCII

PKCS #7 RSA Standard for the format of Cryptographic Objects signed information encrypted information PKCS #7 envelopes: the signed or encrypted data bag of  certificates to aid in decrypting or verifying the data

Signed MIME Objects S/MIME allows two formats for signed messages: multipart/signed application/pkcs-7 Only multipart/signed is used in Signing Directory Operations Signing Directory operations doesn’t encrypt

Multipart/Signed

LDAP Information as MIME Objects LDAP Defines a MIME format for directory objects in RFC 2425 Defines text/directory MIME type Useful as an interchange format for directory information outside of the LDAP protocol (I.e. email).

Text/Directory example

LDAP Object Life Cycle At some point in time, an LDAP object is created. An LDAP Add operation is executed Over time, the object’s attributes change LDAP Modify (or ModifyRDN) operations are executed Eventually, the object is removed from the directory An LDAP Delete operation is executed

Signing LDAP Operations Each LDAP operation that modifies a directory entry can be signed The signature is attached to the Add, Modify, modifyRDN or Delete operation in a control. The signature is in S/MIME format

Signing Procedures Normally the LDAP client signs the LDAP operation as follows: Build LDAPMessage without the SignedOperation control Compute signature on the above LDAPMessage Create new LDAPMessage that includes the old MessageID, protocolOp and any control fields from the previous LDAPMessage, plus the computed signature formatted as an S/MIME message.

More Details The OID for the control is 1.2.840.113549.6.0.0 This is defined under the RSA OID arc

Control Format The format of the Signed Directory Operation Control is:

LDAP Server Processing Upon receipt of a signed LDAP operation, an LDAP Server does the following: Optionally verifies the signature Copies the data in the control into an “audit trail” attribute attached to the LDAP object being modified If the operation is an Add, the create the “zero” entry in the audit trail conforming to the MIME format for Directory Information.

LDAP Audit Trail The Audit Trail has this object class definition in LDAP: (1.2.840.113549.6.1.0 NAME 'signedAuditTrail’ SUP top AUXILIARY MUST ( Changes ) )

LDAP Audit Trail (continued) The Changes attribute has this attribute definition: ( 1.2.840.113549.6.2.0 NAME 'Changes’ DESC 'a set of changes applied to an entry’ SYNTAX 'Binary' ) Changes ::= SEQUENCE { sequenceNumber [0] INTEGER (0 .. maxInt), signedOperation [1] OCTET STRING }

LDAP Audit Trail (continued) The LDAP server has copied the operations and signatures (potentially verified) in to the Audit Trail. Audit Trails become attached to each object in the directory The sequence number in each changes attribute gives the order in which the changes occurred, and are assigned by the server The Audit Trails are retrieved by normal LDAP Search operations.

Signed LDAP Results A control to allow for the client to request that the server sign its results is also defined: The OID is: 1.2.840.113549.6.0.1 The format of the control is just a boolean This allows servers to be configured to always sign their results. For these servers, LDAP clients are allowed to turn off the signing

Handling the Delete operation If the LDAP object is deleted, then the audit trail would be lost. In order to keep the audit trail around, a zombieObject is defined ( 1.2.840.113549.6.1.2 NAME 'zombieObject’ SUP top STRUCTURAL MUST ( Cn $ Changes $ OriginalObject  )  )

Attributes of the zombieObject The Cn is server assigned so as to contrive a new name for the deleted object. Perhaps there will be a common place to put these deleted object in the Directory Information Tree (a graveyard perhaps). The changes attributes are copied over from the deleted object. The originalObject attribute is just the LDAP URL of the object that was deleted. The signature of the Delete operation is also included in the changes attribute.

Signing by the Server The LDAP Client can request that the Server sign the LDAP operation, and include that in the object’s changes attribute. In this case the server uses its own private key to sign the operation.

Signed Operation Conclusions By making use of public key technology, and creating digitally signed transactions that are created by the LDAP v3 client as entries are created and modified, a complete journal of the history of the entry is available. Since each entry in the journal has been digitally signed with the private key of the creator, or modifier of the entry, the source and integrity of the directory entry can be validated by verifying the signature of each entry in the journal. Note that not all of the journal entries will have been signed by the same user.

Current Status Signed Directory Operations Using S/MIME is an experimental track RFC 2649.

Extended Operations Allows new operations to be added to the standard Extended operations have been defined to allow TLS to be started and stopped at the application level

Extension Format

TLS Extended Operations Pretend that these OIDs are used 3.0.0 ® start using TLS request 3.0.1 ® start using TLS response 3.0.2 ® stop using TLS request 3.0.3 ® stop using TLS response Theoretically, at a minimum, all we really need to do is tell the LDAP server that we’re about to start TLS

Encoding the Start TLS

TLS Extension Status The real Using TLS draft is significantly more complex than this presentation It is currently out for last call, and will be a proposed standard shortly Allows for TLS and standard TCP LDAP to work over the same socket

LDAP and PKI LDAP can be used to support a public key infrastructure (PKI) Typical use of PKI is in secure document distribution signing and verification encrypting and decrypting authenticating origin

LDAP and PKI (cont.) Each user has a key pair a public key that everyone knows a private key that only the user knows The public key is made available via LDAP in the form of a certificate X.509 format PGP format

Important Certificate Fields DN of key holder (subject name) DN of certificate issuer Validity period of certificate Alternative names of key holder Public key

Certificates in LDAP

Signing Sign Compute secure hash of document being signed, e.g. using MD5 Encrypt the hash with private key creating the digital signature Distribute document, signature and certificate

Verifying Verify Compute secure hash of document being signed, e.g. using MD5 Decrypt the digital signature with public key found in the certificate Compare decrypted signature and computed hash

Finding the Certificate Note that the DN in the certificate is not necessarily the DN to use in LDAP The user’s directory entry has been renamed since the certificate was issued The DN in the certificate is in the DIT of the CA (e.g. VeriSign), and not in the DIT of the certificate owner (e.g. DTAS). The user doesn’t have a directory entry

Finding the Certificate (cont.) I want to send an encrypted message to bob@someplace.com Use DNS to retrieve the SRV records for ldap.someplace.com.  Assume that the LDAP server that is found is ldap.someplace.com Submit an LDAP search with the filter of (“mail = bob@someplace.com) Extract Certificate from SearchResult (if there)

Finding the Certificate (cont.) If a referral was received, submit a new search request to the indicated LDAP server Extract the issuer’s DN from Bob’s certificate. If this is a new CA, submit a new LDAP search to get the CA information in order to validate Bob’s certificate Get CRLs and ARLs for CA chain from LDAP

LDAP Access Control No Standard!!! LDAP Extensions WG project Excellent Requirements Draft is available Original Michigan implementation had a simple Access Filtering mechanism carried over to Netscape DS

LDAP Access Control (cont.) Allows the administrator to decide which attributes are visible e.g. only allow anonymous users to see name fields and email addresses Rules can be set up by LDAP DNs, IP address or host name of originator

groupOfName Objects Groups are especially useful for controlling access to objects Access is granted to groups, and the membership of the group can change over time, but the access control information remains constant

LDAP Programming Standard APIs are available for C and Java RFC 1843 contains a C API for LDAP v2 LDAP v3 API is still a draft Javasoft published the Java Naming and Directory Interface (JNDI) as part of the Standard JDK 1.2 interface set Netscape has published an LDAP only Java API

LDAP Programming in Java JNDI Unified interface for different types of directories, e.g. DNS, LDAP, X.500, NIS http://www.javasoft.com/products/jndi/index.html Netscape Java API LDAP only API To be published as an Informational RFC (Currently draft) http://developer.netscape.com/docs/manuals/dirsdk/jsdk30/index.htm

JNDI

JNDI Service Providers LDAP v2 and v3 from Sun NIS from Sun CORBA Naming from Sun File system access from Sun RMI Registry from Sun SLP from Sun NDS and Bindery from Novell

Netscape Java LDAP SDK

Netscape Java LDAP SDK Core Class is LDAPConnection All LDAP operations go through objects of this class Adds “connect” method in addition to LDAP operations Also supports SASL Authentication com.netscape.sasl does not include any mechanisms, you have to define your own!

LDAP in Applets Applets don’t normally have arbitrary network access Java 1.2 proposes security model whereby “access policies” can be set up Simpler model is used in Netscape Capabilities classes Signed applets request priveleges Browser displays request with applets certificate to user LDAP applets want “UniversalConnect” privelege http://developer.netscape.com/docs/manuals/signedobj/capabilities/index.html

LDAP Java Browser Browser is a set of applets Use a class to share global data

Data Collection Applet Need variables to hold bind data

Data Collection Applet (cont).

Data Collection Applet (cont.)

Data Collection Applet (cont.)

Data Collection Applet (cont.)

DIT Navigation Applet The DIT navigation applet has four components: A list control to hold the LDAP entries in the container at the current level of the DIT A text field to show which LDAP entry is currently selected A larger text area to show the attributes and values of the selected LDAP entry A button that can be pressed to move up one level in the DIT hierarchy

DIT Navigation Applet (cont.) Need variables to hold context data

DIT Navigation Applet (cont.)

DIT Navigation Applet Need to request permission to make a connection from an applet.

DIT Navigation Applet (cont.)

DIT Navigation Applet (cont.)

DIT Navigation Applet (cont.)

DIT Navigation Applet (cont.)

DIT Navigation Applet (cont.)

DIT Navigation Applet (cont.)

DIT Navigation Applet (cont.)

HTML for Browser

DIT Navigation Applet (cont.)

Java LDAP Browser Source and Binary freely available http://www.directory-applications.com/browser.html

Java Search (Cont.)

Java Search (Cont.)

LDAP Technology Inhibitors Lack of Uniform Support for Extensions Lack of Server Side Support for Capturing extensions Lack of strong authentication support without TLS Lack of complete LDAP v3 support