I wanted to do it on

libre office..but my
college still hasn’t
kept up with
FOSS…SO A 2-
MINUTE NIROBOTA
FOR THAT….
LIGHT WEIGHT DIRECTORY ACCESS PROTOCOL
LDAP…

NOW ..has this guy gone mad??

Protocols…that also
LIGHTWEIGHT??...CAN NEVER BE…
THIS IS INSANE…

?????
Well..lets see…ummm..lets find out about
protocols…
 PROTOCOLS…DIRECTORIES..
LIGHTWEIGHT..
Protocol means a set of rules about how things are to be
done, but in this case between devices or processes in
computing and communications…
Good..at least something to do with computers..
Ok..so in a line it is..
A directory in this The most common application is when talking about
sense is an organized networks. It can mean the way two different system connect
set of records: for (via a common protocol) or the way two similar devices
example, a telephone connect (but over an intermediate system or connection.
directory is an SOME GYAN…
alphabetical list of (Protocols are usually published as an open standard so
persons and
everyone can design their equipment or systems for
organizations with an
address and phone compatibility.)
e et c us to m needs.
number in each
r e re a dil y a d apted to m as m o re easily
d m o s s … w
"record". .. sig n ifi ca n tly simpler an c e s s ar y fo r Internet acce
im p ler than
e ight as in h ich is n e h u s ag e .S
Light w s up p o rts TCP/IP, w m o d e st bandwidt
L DA P ti ve ly
Unlike X.500, in te r ne t d ue to its rela
over the
implemented
 Lets do something serious…
LDAP ..A ONE LINER..application protocol for reading and editing
directories over an IP network.

HOW DID IT COME INTO BEING??

Telecommunication companies' understanding of directory requirements was well developed
after some 70 years of producing and managing telephone directories. These companies
introduced the concept of directory services to information technology and computer
networking, their input culminating in the comprehensive X.500 specification,a suite of
protocols produced by the International Telecommunication Union (ITU) in the 1980s.

A BIT ON X 500..

X.500 is a series of computer networking standards covering electronic directory services.

The X.500 series was developed by ITU-T, formerly known as CCITT, and first approved in
1988. The directory services were developed in order to support the requirements
of X.400 electronic mail exchange and name lookup. ISO was a partner in developing the
standards, incorporating them into the Open Systems Interconnection suite of
protocols. ISO/IEC 9594 is the corresponding ISO identification..
 He is killing me with
t
theory…!!
he X
.
Proto 500 Dire
col ( ctory
X.500 directory services.. th e Op D A P), w Access
Inter e n Sys hich
. . c te requ
USE stack on n ectio m s ired
n (O
SI) p
roto
col
LDAP was originally intended to be a
lightweight alternative protocol
Used the simp
ler n widespre
ad TCP/IP pro
tocol stack…
ne e d to d ep loy an OSI
LDAP removed a n y BING
O!!!
network JACKP
OT…

Point to Perhaps the biggest plus for LDAP is that your company can access
the LDAP directory from almost any computing platform, from any
one of the increasing number of readily available, LDAP-aware

be applications. It's also easy to customize your company's internal

applications to add LDAP support.
 1
Inventors…Versions.. 9
 originally created by Tim Howes of the University of Michigan
& 9
Steve Kille of Isode Limited
&
 Wengyik Yeong of Performance 3
Systems International

Mark Wahl..of Critical Angle Inc..along with Steve n Tim formed the Ldap
v3 under IETF.. > PUBLISHED in 1997..had support for extensibilty..and
included support for Simple Authentication and Security Layer
Further develo
pment of the
extensions ad LDAPv3 specifi
ding features cations them
to LDAPv3 ha selves and of
s come throu numerous
gh the IETF.

IL L G OI N O N… ! !
N ITS ST
 A bit on how it really works..
Step 1
Por
A client starts an LDAP session by connecting to an
LDAP server, called a Directory System Agent (DSA)

Step 2 389 t
..
The client then sends an operation request to the server,
and the server sends responses in return..

LIST OF OPS..CAN BE INITIATED BY THE CLIENT…

•Start TLS — use the LDAPv3 Transport Layer Security (TLS) extension for a secure
Connection..
•Bind — authenticate and specify LDAP protocol version.
•Search — search for and/or retrieve directory entries.
•Compare — test if a named entry contains a given attribute value.
•Add a new entry.
•Delete an entry.
•Modify an entry.
•Modify Distinguished Name (DN) — move or rename an entry.
•Abandon — abort a previous request.
•Extended Operation — generic operation used to define other operations.
•Unbind — close the connection (not the inverse of Bind).
 GYAN ABT THE DIRECTORY
STRUCTURE..
follows the 1993 edition of the X.500 model..
A directory is a tree of directory entries.
An entry consists of a set of attributes.
An attribute has a name (an attribute type or attribute description) and one or more values.
The attributes are defined in a schema 
Each entry has a unique identifier: its Distinguished Name (DN). This consists of its Relative
Distinguished Name (RDN), constructed from some attribute(s) in the entry, followed by the
parent entry's DN. Think of the DN as the full file path and the RDN as its relative filename in
its parent folder (e.g. if C:\foo\bar\myfile.txt were the DN, then myfile.txt would be the RDN).
a DN may change over the lifetime of the entry, for
instance, when entries are moved within a tree..so a
UUID may be assigned in the set of entry’s op
attributes..

Know about LDIF..thats..ldap data interchange format…

 Lets get a tad technical…
An entry can look like this when represented in LDAP Data Interchange Format
(LDIF) (LDAP itself is a binary protocol):
dn: cn=John Doe,dc= example, dc=com cn: John Doe givenName: John
sn: Doe telephoneNumber: +1 888 555 6789 telephoneNumber: +1 888
555 1232 mail: john@example.com manager: cn=Barbara Doe,dc=
example, dc=com objectClass: inetOrgPerson objectClass:
organizationalPerson objectClass: person objectClass: top

Dn= distinguished name..not part of the entry or attribute..

Cn=relative dn..dc=example,dc=com..is the parent’s dn..dc-domain component..
Mail=email ..sn=surname..

A server holds a subtree starting from a specific entry, e.g. "dc= example, dc=com"
and its children. Servers may also hold references to other servers, so an attempt to
access “ ou= department , dc= example , dc=com" could return
a referral or continuation reference to a server which holds that part of the directory
tree. The client can then contact the other server. Some servers also
support chaining, which means the server contacts the other server and returns the
results to the client.
This might help in getti ng a grasp
 Its going to be deadly geeky..so hang on..or doze off..

A BIT ON THE OPS..EACH OF THEM!!

StartTLS
The StartTLS operation establishes Transport Layer Security (the descendant of SSL) on the
connection. It can provide data confidentiality (to protect data from being observed by
third parties) and/or data integrity protection (which protects the data from tampering).
During TLS negotiation the server sends its X.509 certificate to prove its identity. The client
may also send a certificate to prove its identity. After doing so, the client may then
use SASL/EXTERNAL. By using the SASL/EXTERNAL, the client requests the server derive its
identity from credentials provided at a lower level (such as TLS). Though technically the
server may use any identity information established at any lower level, typically the server
will use the identity information established by TLS.
Bind (authenticate)
The Bind operation authenticates the client to the server. Simple Bind can send the user's
DN and password in plaintext, so the connection should be protected using Transport
Layer Security (TLS). The server typically checks the password against the user Password
attribute in the named entry. Anonymous Bind (with empty DN and password) resets the
connection to anonymous state. SASL (Simple Authentication and Security Layer) Bind
provides authentication services through a wide range of mechanisms, e.g. Kerberos or
the client certificate sent with TLS..
 CONTD…
Bind also sets the LDAP protocol version. Normally clients should use LDAPv3, which is the
default in the protocol but not always in LDAP libraries.
Bind had to be the first operation in a session in LDAPv2, but is not required in LDAPv3 (the
Search and Compare
current
The SearchLDAP version).
operation is used to both search for and read entries. Its parameters are:
baseObject 
The DN (Distinguished Name) of the entry at which to start the search,
scope 
What elements below the baseObject to search. This can be BaseObject (search just the named entry, typically used to read
one entry), single Level (entries immediately below the base DN), or whole Subtree  (the entire subtree starting at
the base DN).
filter 
Criteria to use in selecting elements within scope. For example, the filter (&(objectClass=person)(|(givenName=John)
(mail=john*))) will select "persons" (elements of objectClass person) who either have the given name "John" or an e-
mail address that begins with the string "john".
derefAliases 
Whether and how to follow alias entries (entries which refer to other entries),
attributes 
Which attributes to return in result entries.
sizeLimit, timeLimit 
Maximum number of entries to return, and maximum time to allow search to run.
typesOnly 
Return attribute types only, not attribute values.The server returns the matching entries and
potentially continuation references. These may be returned in any order. The final result will
include the result code.
The Compare operation takes a DN, an attribute name and an attribute value, and checks if the
named entry contains that attribute with that value.
 ITS STILL TECHNICAL..
Update Data
Add, Delete, and Modify DN - all require the DN of the entry that is to be changed.
Modify takes a list of attributes to modify and the modifications to each: Delete the
attribute or some values, add new values, or replace the current values with the new
ones.
Add operations also can have additional attributes and values for those attributes.
Modify DN (move/rename entry) takes the new RDN (Relative Distinguished Name),
optionally the new parent's DN, and a flag which says whether to delete the value(s) in
the entry which match the old RDN. The server may support renaming of entire
directory subtrees.
An update operation is atomic: Other operations will see either the new entry or the old
one. On the other hand, LDAP does not define transactions of multiple operations: If
you read an entry and then modify it, another client may have updated the entry in the
mean time. Servers may implement extensions  which support this, though.
Extended operations
The Extended Operation is a generic LDAP operation which can be used to define new
operations. Examples include the Cancel and Password Modify.
 THIS IS THE LAST OF THE TECHNICAL TORTURE..
Abandon
The Abandon operation requests that the server abort an operation named by a message ID.
The server need not honor the request. Unfortunately, neither Abandon nor a successfully
abandoned operation send a response. A similar Cancel extended operation has therefore
been defined which does send responses, but not all implementations support this.
Unbind
The Unbind operation abandons any outstanding operations and closes the connection. It
has no response. The name is of historical origin, and is not the opposite of the Bind
operation.
Clients can abort a session by simply closing the connection, but they should use
Unbind.Unbind allows the server to gracefully close the connection and free resources that
it would otherwise keep for some time until discovering the client had abandoned the
connection. It also instructs the server to cancel operations that can be canceled, and to not
send responses for operations that cannot be canceled.

A NOTE ON LDAP url ..

An LDAP URL format exists which clients support in varying degree, and which servers return
in referrals and continuation references (see RFC 4516)
ldap://host:port/DN?attributes?scope?filter?extensions
 A discussion on URLs..
Uniform resource locators…
Most of the components, which are described below, are optional.
•host is the FQDN or IP address of the LDAP server to search.
•port is the network port of the LDAP server.
•DN is the distinguished name to use as the search base.
•attributes is a comma-separated list of attributes to retrieve.
•scope specifies the search scope and can be "base" (the default), "one" or
"sub".
•filter is a search filter. For example (objectClass=*) as defined in RFC
4515.
•extensions are extensions to the LDAP URL format.
For example, "ldap://ldap.example.com/cn=John
%20Doe,dc=example,dc=com" refers to all user attributes in John Doe's
entry inldap.example.com, while "ldap:///dc=example,dc=com??sub?
(givenName=John)" searches for the entry in the default server (note the
triple slash, omitting the host, and the double question mark, omitting the
attributes). As in other URLs, special characters must be percent-encoded.
There is a similar non-standard ldaps: URL scheme for LDAP over SSL. This
should not be confused with LDAP with TLS, which is achieved using the
 FAQ s..
1)Is an LDAP information directory a database? 
Just as a Database Management System (DBMS) from Sybase, Oracle, Informix, or
Microsoft is used to process queries and updates to a relational database, an LDAP server
is used to process queries and updates to an LDAP information directory. In other words,
an LDAP information directory is a type of database, but it's not a relational database.
And unlike databases that are designed for processing hundreds or thousands of changes
per minute - such as the Online Transaction Processing (OLTP) systems often used in e-
commerce - LDAP directories are heavily optimized for read performance.
2)The advantages of LDAP directories ??
The biggest plus for LDAP is that your company can access the LDAP directory from almost
any computing platform, from any one of the increasing number of readily available,
LDAP-aware applications. It's also easy to customize your company's internal applications
to add LDAP support.
The LDAP protocol is both cross-platform and standards-based, so applications needn't worry
about the type of server hosting the directory. In fact, LDAP is finding much wider industry
acceptance because of its status as an Internet standard. Vendors are more willing to write LDAP
integration into their products because they don't have to worry about what's at the other end.
Your LDAP server could be any one of a number of open-source or commercial LDAP directory
servers (or perhaps even a DBMS server with an LDAP interface), since interacting with any true
LDAP server involves the same protocol, client connection package, and query commands. By
contrast, vendors looking to integrate directly with a DBMS usually must tailor their product to
work with each database server vendor individually.
LDAP allows you to securely delegate read and modification authority based on your specific
needs using ACIs (collectively, an ACL, or Access Control List). For example, your facilities
group might be given access to change an employee's location, cube, or office number, but
not be allowed to modify entries for any other fields. ACIs can control access depending on
who is asking for the data, what data is being asked for, where the data is stored, and other
aspects of the record being modified. This is all done through the LDAP directory directly, so
you needn't worry about making security checks at the user application level.
LDAP is particularly useful for storing information that you wish to read from many locations,
but update infrequently. For example, your company could store all of the following very
efficiently in an LDAP directory:
The company employee phone book and organizational chart
External customer contact information
Infrastructure services information, including NIS maps, email aliases, and so on
Configuration information for distributed software packages
Public certificates and security keys

Advantages galore!!
When should you use LDAP to store your data?
Most LDAP servers are heavily optimized for read-intensive operations. Because of this, one
can typically see an order of magnitude difference when reading data from an LDAP directory
versus obtaining the same data from a relational database server optimized for OLTP.
Because of this optimization, however, most LDAP directories are not well suited for storing
data where changes are frequent. For instance, an LDAP directory server is great for storing
your company's internal telephone directory, but don't even think of using it as a database
back end for your high-volume e-commerce site.
If the answer to each of the following questions is Yes, then storing your data in LDAP is a
good idea.
Would you like your data to be available cross-platform?
Do you need to access this data from a number of computers or applications?
Do the individual records you're storing change a few times a day or less, on average?
Does it make sense to store this type of data in a flat database instead of a relational
database? That is, could you effectively store all the data for a given item in a single record?
This final question often gives people pause, because it's very common to access a flat record
to obtain data that's relational in nature. For example, a record for a company employee
might include the login name of that employee's manager. It's fine to use LDAP to store this
kind of information. Rule of thumb: If you can imagine storing your data in a large electronic
Rolodex, you can store it easily in an LDAP directory.

Torture khatam…
 U have questions after this…

I’m sorry..nothing will be

answered..
Mujhe jhelne k liye ..
Thanks…