1 / 12

LDAP Protocol Overview

LDAP Protocol Overview. Tony Fortunato The Technology Firm. info@thetechfirm.com. Specifics. RFCs 2252 & 2253 LDAPv2 – RFC 1777  March 1995 LDAPv3 – RFC 2251  December 1997 Uses TCP Port 389 for Client to Server Uses TCP port and 636 for LDAP over SSL.

bernad
Télécharger la présentation

LDAP Protocol Overview

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 Overview Tony Fortunato The Technology Firm info@thetechfirm.com

  2. Specifics • RFCs 2252 & 2253 • LDAPv2 – RFC 1777  March 1995 • LDAPv3 – RFC 2251  December 1997 • Uses TCP Port 389 for Client to Server • Uses TCP port and 636 for LDAP over SSL. • Can be configured to run over UDP as well. • all protocol operations are encapsulated in a common envelope, referred to as the LDAPMessage.

  3. Tool Notes And LDAP NAI Sniffer Pro v 4.50.04 • Expert Object database does not provide any additional information for LDAP. • The most detail you can get is at the TCP layer using the Expert. • You must add LDAP (TCP port 389) via the Protocol Options screen. • Does not decode the 1 Byte Message Length at offset 3C. Fluke Optiview Protocol Expert v 4.0.0.53 • Expert Object database does not provide any additional information for LDAP. • The most detail you can get is at the TCP layer using the Expert. • Fluke already had added LDAP to its various Detailed Reports. • Does not decode the 1 Byte Message Length at offset 3C. • Decodes the Response packets as Requests. • Decodes the Add Request/Response packets as ‘Continuation Data’/’Bind Request’. • Decodes the Unbind Request as a ‘Bind Request’ Ethereal v 0.8.20 • Does not have an Expert or reporting facility. • Ethereal does not decode Extended commands or responses.

  4. NAI LDAP Decode Note The packet with the frame too short, is not decoding past the Add command, even though the remaining data is there to be decoded. OK Packet Flagged as ‘Too Short’ Even though it’s 143 Bytes

  5. LAB Layout Incremental Replication Dc=3lg, dc=com MASTER Heckler 192.168.1.103 00505640005C SLAVE NT-vaio 192.168.1.102 005056405921 CLIENT Vaio 192.168.1.101 0010A4981A56 Ldap Servers Iplanet Directory server ver 5.1 Client Openldap version 2.0.11-8 (linux)

  6. TCP Three-way Handshake Initiating Application Port Number (Port 21) FTP Sequence Number + 1 Sequence Number + 1 • The delta value between frames 1 and 2 can be used as a TCP transport connect baseline value. • Other important information gathered from this handshake: • Window Size • SACK • Maximum Segment Size • Window Scale Option value Excerpt From IP Protocol Course

  7. TCP FIN The FIN (Finish) packet is initiated by the Client. ACK = Sequence Number + 1 ACK = Sequence Number + 1 The FIN (Finish) packet is then sent by the server. Excerpt From IP Protocol Course

  8. LDAP Message Format • LDAPMessage ::= SEQUENCE { messageID MessageID, protocolOp CHOICE { bindRequest BindRequest, bindResponse BindResponse, unbindRequest UnbindRequest, searchRequest SearchRequest, searchResponse SearchResponse, modifyRequest ModifyRequest, modifyResponse ModifyResponse, addRequest AddRequest, addResponse AddResponse, delRequest DelRequest, delResponse DelResponse, modifyRDNRequest ModifyRDNRequest, modifyRDNResponse ModifyRDNResponse, compareDNRequest CompareRequest, compareDNResponse CompareResponse, abandonRequest AbandonRequest } } MessageID ::= INTEGER (0 .. maxInt)

  9. Message ID The message ID value must be echoed in all LDAPMessage envelopes encapsulting responses corresponding to the request contained in the LDAPMessage in which the message ID value was originally used. NAI Ethereal Fluke

  10. Bind Request Command Format The Bind Operation must be the first operation request received by a server from a client in a protocol session. Bind Operation Function • initiates a protocol session between a client and a server • allows the authentication of the client to the server. • The Bind Request is defined as follows: BindRequest ::= [APPLICATION 0] SEQUENCE { version INTEGER (1 .. 127), name LDAPDN, authentication CHOICE { simple [0] OCTET STRING, krbv42LDAP [1] OCTET STRING, krbv42DSA [2] OCTET STRING } }

  11. Bind Request Parameters • version: A version number indicating the version of the protocol to be used in this protocol session. • Note that there is no version negotiation, and the client should just set this parameter to the version it desires. • name: The name of the Directory object that the client wishes to bind as. This field may take on a null value (a zero length string) for the purposes of anonymous binds. • authentication: information used to authenticate the name, if any, provided in the Bind Request. • The "simple" authentication option provides minimal authentication facilities, with the contents of the authentication field consisting only of a cleartext password. • This option should also be used when unauthenticated or anonymous binds are to be performed, with the field containing a zero length string in such cases. • The Bind Operation requires a response, the Bind Response, which is defined as: BindResponse ::= [APPLICATION 1] LDAPResult • A Bind Response consists simply of an indication from the server of the status of the client's request for the initiation of a protocol session. • Upon receipt of a Bind Request, a protocol server will authenticate the requesting client if necessary, and attempt to set up a protocol session with that client. The server will then return a Bind Response to the client indicating the status of the session setup request.

  12. Unbind Operation • The function of the Unbind Operation is to terminate a protocol session and defined as follows: UnbindRequest ::= [APPLICATION 2] NULL • The Unbind Operation has no response defined. Upon transmission of an UnbindRequest, a protocol client may assume that the protocol session is terminated. Upon receipt of an UnbindRequest, a protocol server may assume that the requesting client has terminated the session and that all outstanding requests may be discarded.

More Related