You are on page 1of 8

Advanced Operating Systems

Assignment No.1

By

Imran Nayyer

Roll # 1433

Ms (CS) 1st

Topic: LDAP
Question No.1: What does LDAP stands for?

Answer: LDAP stands for Lightweight Directory Access Protocol.

Question No.2: What is LDAP?

Answer: The Lightweight Directory Access Protocol (LDAP) is an


application protocol for querying and modifying data of directory services
implemented in Internet Protocol (IP) networks.
It runs directly over TCP, and makes several simplifications to full X.500
DAP, leaving out many of the lesser-used features. LDAP uses primitive
string encodings for most data elements, making it more efficient and
easier to implement than DAP.

Question No.3: Describe at least six differences between


directories and databases.

Answer:

LDAP was designed and optimized to handle simple data, which once
written, will seldom be modified. Traditional databases have been
designed and optimized for both query and update operations on data and
are designed to handle highly complex data, as opposed to LDAP, which is
essentially a text-based directory storage system.
Further, traditional databases have been built for transaction integrity and
consistency. This is not really a priority for LDAP where the data is most
often read than written. Thus the lightweightness of LDAP comes from it
being a simple protocol handling simple data.

The way a directory organizes data is considerably different from how a


traditional database organizes it. This difference is explicit on the
following counts:
1: Databases usually have only fields with unique names within a record;
for example, an employee record has one field with the name telephone
number. This is not the case with an LDAP directory. For example, an
employee record in a database may have a field named telephone
number, and there is one and only one field with this name as far as the
record is concerned. So what if an employee has two telephone numbers,
say one work number and a second cell phone number?
2: In a traditional database, this is solved by representing the numbers as
a separate telephone number table with the employee ids used to relate
them to a particular employee. However, in an LDAP directory there can
be one attribute with the name telephone number but with multiple
values; there could be two fields with the same name telephone number,
one representing the work number and the other representing the mobile
number. In such a situation, the directory is most likely to perform better
than the database in terms of processing a query for the telephone
numbers of an employee. Such a fluid scheme is one of the reasons that
queries are processed very fast in a LDAP directory.

3: LDAP is characterized as a 'write-once-read-many-times' service. That


is to say, the type of data that would normally be stored in an LDAP
service would not be expected to change on every access. To illustrate:
LDAP would NOT be suitable for maintaining banking transaction records
since, by their nature, they change on every access (transaction). LDAP
would, however, be eminently suitable for maintaining details of the bank
branches, hours of opening, employees etc...
4: Visibility of Data Organization
5: Data Synchronization
6: So what are LDAP (Directory) advantages and why would any sane
human being use a directory?
Before attempting to answer the question let's dismiss the tactical
issue of performance. In general RDBMS systems are still significantly
faster than LDAP implementations. This is changing with the development
of second generation Directory Servers and while it is likely that RDBMS
will always remain faster than LDAP the gap is reducing significantly to
the point where, assuming you compare like with like, (a measured
network initiated transaction) the differences will become increasingly
non-existent - unless you update a highly indexed attribute on every
operation - in which case you deserve everything you (don't) get.
So why use LDAP? Here is our list of key characteristics which make
the (currently) high level of pain worthwhile.
LDAP provides a remote and local data access method that is
standardized. It is thus possible to replace the LDAP implementation
completely without affecting the external interface to the data. RDBMS
systems provide local access standards such as SQL but remote interfaces
tend to be proprietary.
Because LDAP uses standardized data access methods Clients and
Servers may be sourced (or developed) independently.
LDAP provides a method whereby data may be moved (delegated)
to multiple locations without affecting any external access to that data. By
using referral methods LDAP data can be moved to alternate LDAP servers
by changing operation parameters only.
LDAP systems can be operationally configured to replicate data to one or
more application without adding either code or changing the external
access to that data.
The above definition focuses exclusively on the standard nature of
LDAP data access and does not consider the ratio of reads to writes
which, as noted above, will depend on the number of operational indices
maintained. It does implicitly ignore the use of Directories for transaction
processing - though even here there are signs that LDAP implementations
are looking at such capabilities.
Question No.4: What are three dimensions of a directory
and how they are different from each other?

Answer: The three dimensions of a directory are

1: scope of information
2: location of clients
3: distribution of servers

All are independent of each other. For example, clients scattered


across the globe can access a directory containing only information about
a single department, and that directory can be replicated at many
directory servers. Or, clients in a single location can access a directory
containing information about everybody in the world that is stored by a
single directory server.
The scope of information to be stored in a directory is often given as
an application requirement. The distribution of directory servers and the
way in which data is partitioned or replicated can often be controlled to
affect the performance and availability of the directory. For example, a
distributed and replicated directory might perform better because a read
request can be serviced by a nearby server. A centralized directory may
be less available because it is a single point of failure. However, a
distributed directory might be more difficult to maintain because multiple
sites, possibly under the control of multiple administrators, must be kept
up-to-date and in running order.
The generic example of a directory would be a telephone directory
or an address book. We use white pages directories when we need to find
something specific about a person or a business about which we know
something distinguishing such as the name of the person or the name of
the business. When we need to find more general information about a
group, say we need to find the list of all local merchants who specialize in
selling reusable widgets, we refer to a yellow pages directory.
We use directories when we use e-mail or a web browser. The e-
mail client sends a mail message to a mail server. The mail server looks
up an internal table to locate the host machine on which the recipient of
the message has an account. Similarly, when the name of a website is
typed into a browser, the browser contacts a Domain Name System
(DNS) server. The DNS server looks up an internal table that maintains a
mapping between a DNS name and the IP address of the machine that
hosts the web site. The server returns the mapping to the browser that
now talks directly to the web server using its IP address. Ideally, such
information can reside in a directory and can be accessed by any client
that can speak the protocol of the directory. In fact, there are now quite a
few installations where DNS lookup is directory enabled using DNS-to-
LDAP gateways.
Question No.5: What is DAP? How is LDAP different from
DAP?

Answer: LDAP has four key advantages over DAP.

First, it runs directly over TCP (or other reliable transport, in


theory), eliminating much of the connection set-up and packet-handling
overhead of the OSI session and presentation layers required by DAP. In
addition, the near universal availability of TCP/IP implementations means
that LDAP can run on most systems “out of the box.”

Second, LDAP simplifies the X.500 functional model in two ways. It


leaves out the read and list operations, emulating them via the search
operation. It also leaves out some of the more esoteric and less-often-
used service controls and security features of full X.500 (e.g., the ability
to sign operations). This simplifies LDAP implementations.

Third, though X.500 and LDAP both describe and encode protocol
elements using ASN.1 and BER [12], LDAP uses string encodings for
distinguished names and data elements. X.500 uses a complex and
highly-structured encoding even for simple data elements; LDAP data
elements are string types. This encoding is a big win for distinguished
names, which have considerable structure leading to encoding/ decoding
complexity and size. LDAP relegates the knowledge of a value’s syntax to
the application program rather than lower level protocol routines.

Fourth, LDAP frees clients from the burden of chasing referrals. The
LDAP server is responsible for chasing down any referrals returned by
X.500, returning either results or errors to the client. Clients assume a
single connection model in which X.500 appears as a single logical
directory.

Question No.6: Was LDAP version 2 an internet standard


in 1998? Is it now?

Answer: Yes LDAP version 2 was an Internet standard in 1998 and it is


still an internet standard.

Question No.7: What is stand alone LDAP server?

Answer: LDAP server is the server that LDAP clients interact with to
obtain directory information. The actual data is stored in a datastore
(usually a database). The datastore is hidden from the clients since the
server knows how to retrieve information from the datastore and present
it to the clients in a common format.
Question No.8: Describe six types of operations that
LDAP defines on directory entries.

Answer:

The following are the LDAP operations that can be performed using
the projected user profiles.

1: Bind
An LDAP client can bind (authenticate) to the LDAP server using a
projected user profile. This is accomplished by specifying the projected
user profile distinguished name (DN) for the bind DN and the correct
i5/OS™ user profile password for authentication.

2: Search
The system projected backend supports some basic search filters.
You can specify the object class, os400-profile, and os400-gid attributes
in search filters. The os400-profile attribute supports wildcards. The
os400-gid attribute is limited to specifying (os400-gid=0), which is an
individual user profile, or! (Os400-gid=0), which is a group profile. You
can retrieve all attributes of a user profile except the password and
similar attributes.
For certain filters, only the DN object class and os400-profile values
are returned. However, subsequent searches can be conducted to return
more detailed information.

3: Compare
The LDAP compare operation can be used to compare an attribute
value of a projected user profile. The os400-aut and os400-docpwd
attributes cannot be compared.

4: Add and modify


You can create user profiles using the LDAP add operation and you
can also modify user profiles using the LDAP modify operation.

5: Delete
User profiles can be deleted using the LDAP delete operation. To
specify the behavior of the DLTUSRPRF OWNOBJOPT and PGPOPT
parameters, two LDAP server controls are now provided. These controls
can be specified on the LDAP delete operation. Refer to the Delete User
Profile (DLTUSRPRF) command for more information about the behavior
of these parameters.

6: ModRDN
You cannot rename projected user profiles because this is not
supported by the operating system.
Question No.9: Name and briefly summarize the four
models on which LDAP is based.

Answer:
1: Information Model
We tend to use the term Data Model, in our view a more intuitive
and understandable term. The Data (or Informational) Model defines how
the information or data is represented in an LDAP enabled system - this
may, or may NOT, be the way the data is actually stored as explained
above.
2: Naming Model
This defines all that 'dc=example, dc=com' stuff that you stumble
across in LDAP systems. We stick pretty much to the specifications here
because the terms are so widely used.
3: Functional Model
When you read, search, write or modify the LDAP you are using the
Functional Model - wow.
4: Security Model
You can control, in a very fine-grained manner, which can do what
to what data. This is complex but powerful stuff. We progressively
introduce the concepts and have dedicated a specific chapter to it. To
begin with - forget security. You can always go back and retro-fit security
in LDAP. Where you cannot retro-fit, we reference security implications in
the text.
Note:

The information provided in this assignment is 100% my own


search from the following links below. No material has been copied from
any other student.

References:

http://www.wdvl.com/Authoring/Languages/PHP/Pro/prophp1_2.html

http://www.wdvl.com/Authoring/Languages/PHP/Pro/prophp1_4.html

http://www.zytrax.com/books/ldap/ch2/

http://en.wikipedia.org/wiki/LDAP

You might also like