Professional Documents
Culture Documents
Assignment No.1
By
Imran Nayyer
Roll # 1433
Ms (CS) 1st
Topic: LDAP
Question No.1: What does LDAP stands for?
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.
1: scope of information
2: location of clients
3: distribution of servers
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.
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.
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:
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