Professional Documents
Culture Documents
SERVER Configuration
Install Openldap Services :
The following table summarizes the OpenLDAP Software packages installed in the above step.
openldap Contains all configuration files, libraries, and documentation for OpenLDAP.
openldap-
Contains files needed to host an LDAP server ( slapd and slurpd).
servers
openldap-
Contains the client programs needed for accessing and modifying LDAP directories.
clients
Contains access client software for using LDAP as a method of user authentication for
nss_ldap
Linux.
After installing OpenLDAP Software, the next step is to modify the necessary configuration files to customize the
LDAP server. As with any new application, it is highly recommended to understand the purpose of each
configuration file and to create a backup of the original version of those configuration files before modifying
them.
The following table describes the client and server configuration files used to customize OpenLDAP Software.
Shell script used to start and stop the LDAP server (slapd and slurpd). Prior to
/etc/rc.d/init.d/ldap starting the LDAP server, the script performs a syntax check of
the slapd.confconfiguration file.
Directory that contains a set of default schema specifications which describe the
different object classes that are available by default with the OpenLDAP
Software. Each set is defined in a file (i.e. core.schema) suitable for inclusion
/etc/openldap/schema/* using the includedirective in the global definitions portion of
the slapd.conf(5) file. It is helpful to browse the contents of these files to
determine the required and available attributes for a particular object class.
/usr/bin/ldap* In OpenLDAP, any file that begins with "ldap" is a client utility. This
includesldapsearch for searching a directory, ldapadd for adding records from the
client,ldapmodify for modifying existing directory records, and ldapdelete for
removing records from the directory.
Backup the original version of any OpenLDAP Software configuration file before making modifications.
Using OpenLDAP Software with a BDB backend requires a DB_CONFIG database configuration file for optimum
performance. An example DB_CONFIG file exists at/etc/openldap/DB_CONFIG.example. To create an
LDAP database configuration file for BDB, simply copy the example configuration file to the LDAP directory
database location as follows:
The rootdn entry is the full Distinguished Name (DN) for the user who is unrestricted by access controls or
administrative limit parameters set for operations on the LDAP directory and The rootpw option is the password
for the rootdn that you specified
I have used clear text password since many of us are stuck in this. You can make use of encrypted password
with the following command.
The LDAP server is now ready to be started for the first time.
Create root record and its sub records , all in one file
where ,
Users created in the local machine (/etc/passwd) can be imported to LDAP with the help of PADL scripts
dn: uid=mano,ou=People,dc=padl,dc=com
uid: mano
cn: Manoharan
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}$1$i3SH2lp6$bqTLjklRUD98aiiyCPRiZ/
shadowLastChange: 15552
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 500
gidNumber: 500
homeDirectory: /home/mano
gecos: Manoharan
However , my root domain is domain.com & not padl.com and hence i need to change this default setting at
/usr/share/openldap/migration/migrate_common.ph
# Default base
$DEFAULT_BASE = "dc=domain,dc=com";
LDAP Search:
Where,
ldapsearch - is a command to search LDAP Objects / Entries
-b - base dn for search ( i.e –b "dc=domain,dc=com")
-x - Simple authentication
dn: uid=mano,ou=People,dc=domain,dc=com
uid: mano
cn: Manoharan
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword:: e2NyeXB0fSQxJGkzU0gybHA2JGJxVExqa2xSVUQ5OGFpaXlDUFJpWi8=
shadowLastChange: 15552
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 500
gidNumber: 500
where,
dn: uid=sachin,ou=People,dc=domain,dc=com
uid: sachin
cn: sachin
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword:: e2NyeXB0fSQxJE5LUlRScFQ5JFU5TG12dkxub0EucENtdHVTaTlNeS4=
shadowLastChange: 15623
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 501
gidNumber: 501
homeDirectory: /home/sachin
Note : All the above entries can also be put in an .ldif file and executed at one go .
LDAP Delete:
ldap_initialize( <DEFAULT> )
deleting entry "cn=salman,ou=People,dc=domain,dc=com"
where,
NFS:
-bash-3.2$ exit
logout
[sachin@CLIENT ~]$
Replication
By SLURPD Method
Slurpd style replication used a 'push' replication strategy and is obsoleted from version 2.4.
Documentation is maintained here for historical reasons and for anyone marooned on older
versions of OpenLDAP. It is configured and controlled as shown
2. The slave knows that writes can only come from its replication partner, and therefore it sends a referral back the
client, pointing it to the master server.
3. The client reissues the update request to the master.
4. The master performs the update and writes the change to the replication log
5. slurpd, also running on the master, notices the change in the replication log.
In this way, slaves can be kept up to date with the master with little lag. If any interruptions happen, or an error occurs on a
slave, slurpd always knows which slaves need which updates.
Create a replica account that slurpd will use to authenticate against the slave replica:
Slurpd is a straightforward solution to the replication problem, but it has several shortcomings. Shutting down your master
server so that you can synchronize a slave is inconvenient at best, and at worst it can affect service.
syncrepl is initiated from the slave, which is now given the name consumer. The master role is called provider. In syncrepl,
the consumer connects to the provider to get updates to the tree. In the most basic mode, called refreshOnly, the consumer
receives all the changed entries since its last refresh, requests a cookie that keeps track of the last synchronized change,
and then disconnects. On the next connection, the cookie is presented to the provider, which sends only the entries that
changed since the last synchronization.
Another syncrepl mode, called refreshAndPersist, starts off like the refreshOnly operation; but instead of disconnecting, the
consumer stays connected to receive any updates Any changes that happen after the initial refresh are immediately sent
over the connection to the consumer by the provider.
Delete all the DIT that were created out of SLURPD Testing :
Comment out the SLURPD – Slave Setting and add the following lines :\
The rid identifies this consumer to the master. The consumer must have a unique ID between 1 and 999.
The provider is an LDAP URI pointing back to the provider. type specifies that you only want periodic synchronization
through refreshOnly, and the interval is every hour. Theinterval is specified in DD:hh:mm:ss format.
Start the consumer with an empty database, and it will replicate its data from the provider and update every hour.
Making the transition to refreshAndPersist mode is simple. In the above snippet remove the interval, and change
the type to refreshAndPersist
Installation:
Install the Latest version of PHP
Go to phpldapadmin directory :
Copy the config.php.example file as config.php
http://192.168.17.53/phpldapadmin-1.2.3
For SADHIQ-LINUX-GROUP
Mano Nadar