Lightweight Directory Access Protocol and is a standard industrial protocol and global directory services that are based on the models of client-server and executes a layer over the TCP/IP stack. These lightweight directory access protocol gives an opportunity for interfacing with access, modify and seek the web index. These lightweight server consists of data that are sorted out as an index tree. If suppose the user request the server for additional data for performing an desire and confidential information. The server will provide the response to the user by providing the desire data if it contain in the database, or it it attribute the user to a different server for the activity on required data. The user obtains the specified data from a different server. All the participating servers will maintain the same tree structure in the directory across the network and these features play a key part in the directory service of Lightweight directory access protocol. Irrespective for which the server is reversed by the user, the user dependably gather the required data in a precise format without any errors and can utilize these LDAP to verify the DB2 as a substitution of working framework confirmation. Light Directory Access Protocol can be classified into the following types,such as:

IBM contributes a complimentary package with plug-in LDAP modules for DB2. The package contain in the DB2 will incorporates three plug-in securities in the DB2 for each of the specified: Contingent on the specified necessities, it can be utilize in any of the three plug-in's. All these plug-in don't bolster the situations where a few clients are characterized in LDAP and others in the System operations and after deciding to utilize the LDAP plug-ins, and at the same time the user need to characterize all clients that are connected with the database in the LDAP server. The similar guidelines can be applied to the plug-in groups. The user have to decide which plug-ins are compulsory for the system. The user confirmation plug-ins are utilized as a part of situations where the client ID and the password validation that are outfitted on a CONNECT or ATTACH statement explanations that occurred in the client system. The authentication of user is hard to secure and is not actually suggested. The plug-in the server is normally prescribed, since it execute the validations in the server side of client IDs and passwords, suppose it execute a CONNECT or ATTACH proclamation and this is secure way. The plug-in server also gives an approach to outline the LDAP client IDs DB2 approval IDs.

For performing the configurations with the LDAP transparent, first the user have to configure with the server of LDAP.

For configurating the SLAPD.conf file, that consists of each and every information regarding the objects in the LDAP and after installing the LDAP server, by default LDAP directory tree has to be installed in the server machine. The tables can be installed and modified inside the server database.

By viewing the below example, the concept of LDAP configurations with the server can be easily understands. [c] # base dn: example.com dn: dc=example,dc=com dc: example o: example objectClass: organization objectClass: dcObject # pc box db dn: dc=db697,dc=example,dc=com dc: db697 o: db697 objectClass: organization objectClass: dcObject # # Group: dbadm # dn: cn=dbmy1adm,dc=db697,dc=example,dc=com cn: dbmy1adm objectClass: top objectClass: posixGroup gidNumber: 400 objectClass: groupOfNames member: uid=db2my1,cn=dbmy1adm,dc=db697,dc=example,dc=com memberUid: db2my1 # # User: db2 # dn: uid=db2my1,cn=dbmy1adm,dc=db697,dc=example,dc=com cn: db2my1 sn: db2my1 uid: db2my1 objectClass: top objectClass: inetOrgPerson objectClass: posixAccount uidNumber: 400 gidNumber: 400 loginShell: /bin/csh homeDirectory: /db2/db2my1 # # Group: dbctl # dn: cn=dbmy1ctl,dc=db697,dc=example,dc=com cn: dbmy1ctl objectClass: top objectClass: posixGroup gidNumber: 404 objectClass: groupOfNames member: uid=my1adm,cn=dbmy1adm,dc=db697,dc=example,dc=com memberUid: my1adm # # User: adm # dn: uid=my1adm,cn=dbmy1ctl,dc=db697,dc=example,dc=com cn: my1adm sn: my1adm uid: my1adm objectClass: top objectClass: inetOrgPerson objectClass: posixAccount uidNumber: 404 gidNumber: 404 loginShell: /bin/csh homeDirectory: /home/my1adm ldapadd r- -D ‘cn=Manager,dc=example,dc=com” –W –f /var/lib/slapd.conf[/c] After performing the above LPAD server with the name ‘/var/lib/slapd.conf’, then it execute the file by performing all the command to add these values into LDAP Server.

For performing the configurations of client LDAP is spared in the record 'ldap.conf'. And these LDAP consists of two documents that are accessible for the parameters that are configured and ought to locate the first at '/and so forth/ldap.conf' and the last is situated at '/and so on/openldap/ldap.conf'.

By viewing the below example, the concept of LDAP configurations with the client can be easily understands. [c] # File: /etc/ldap.conf # The file contains lots of more entries and many of them # are comments. You show only the interesting values for now host localhost base dc=example,dc=com ldap_version 3 pam_password crypt pam_filter objectclass=posixAccount nss_map_attribute uniqueMember member nss_base_passwd dc=example,dc=com nss_base_shadow dc=example,dc=com nss_base_group dc=example,dc=com [/c]

• DB2 LDA Protocol - Is a part of global directory services based on client server stacks.
• Plug-in - Is a complimentary package with LDAPB modules.
• Transparent - Is a configurtion with the LDAP server.