What is LDAP?
LDAP stands for Lightweight Directory Access Protocol. As the name suggests, it is a lightweight protocol for accessing directory services, specifically X.500-based directory services. LDAP runs over TCP/IP or other connection oriented transfer services.
What is a directory service?
A directory is a specialized database optimized for reading, browsing and searching. Directories tend to contain descriptive, attribute-based information and support sophisticated filtering capabilities.
How does LDAP work?
LDAP directory service is based on a client-server model. One or more LDAP servers contain the data making up the directory information tree (DIT). The client connects to servers and asks it a question. The server responds with an answer and/or with a pointer to where the client can get additional information (typically, another LDAP server). No matter which LDAP server a client connects to, it sees the same view of the directory; a name presented to one LDAP server references the same entry it would at another LDAP server. This is an important feature of a global directory service, like LDAP.
slapd is an LDAP directory server that runs on many different platforms. You can use it to provide a directory service of your very own.
What is slurpd and what can it do?
slurpdis a daemon that, with slapd help, provides replicated service. It is responsible for distributing changes made to the master slapd database out to the various slapd replicas. It frees slapd from having to worry that some replicas might be down or unreachable when a change comes through; slurpd handles retrying failed requests automatically. slapd and slurpd communicate through a simple text file that is used to log changes.
The topic of LDAP seems to be little bit complicated at the beginning, so we will start with a simple example to for demonstration purposes.
We will use two machines in this example: a client and a server, both running Red Hat Enterprise Linux 5.4. We will use the OpenLDAP rpm package that’s available with Red Hat. The setup is:
We will break out configuration into a very simple steps. We will start with the server “station1.example.com”:
1. Create test users:
4. The next step is to migrate the local files (/etc/passwd, /etc/shadow, and /etc/group) contents to an LDIF file. This is done using scripts that are ready with the packages we installed at the beginning
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" is the distinguished name of the entry; it's neither an attribute nor a part of the entry. "cn=John Doe" is the entry's RDN (Relative Distinguished Name), and "dc=example,dc=com" is the DN of the parent entry, where "dc" denotes 'Domain Component'. The other lines show the attributes in the entry. Attribute names are typically mnemonic strings, like "cn" for common name, "dc" for domain component, "mail" for e-mail address and "sn" for surname.
5. Since the LDIF file is ready, we can now build the LDAP database:
First check the existing LDAP database (it should be empty):
7. Change permissions of the LDAP database files. Since they will be accessed by the LDAP daemon, then they shouldn’t have “root” as owner and group.
Execute this command to lunch the GUI tool:
Enter the settings as follows then click “OK” :
Now that the system “station2.example.com” should be configured as an LDAP client, we can test our configuration with LDAP Search commands:
1. To use LDAP commands, we should have this pacakge installed in the clients:
LDAP stands for Lightweight Directory Access Protocol. As the name suggests, it is a lightweight protocol for accessing directory services, specifically X.500-based directory services. LDAP runs over TCP/IP or other connection oriented transfer services.
What is a directory service?
A directory is a specialized database optimized for reading, browsing and searching. Directories tend to contain descriptive, attribute-based information and support sophisticated filtering capabilities.
How does LDAP work?
LDAP directory service is based on a client-server model. One or more LDAP servers contain the data making up the directory information tree (DIT). The client connects to servers and asks it a question. The server responds with an answer and/or with a pointer to where the client can get additional information (typically, another LDAP server). No matter which LDAP server a client connects to, it sees the same view of the directory; a name presented to one LDAP server references the same entry it would at another LDAP server. This is an important feature of a global directory service, like LDAP.
What is the difference between LDAPv2 and LDAPv3?
LDAPv3 was developed in the late 1990's to replace LDAPv2. LDAPv3 adds the following features to LDAP:
- Strong authentication and data security services via SASL
- Certificate authentication and data security services via TLS (SSL)
- Internationalization through the use of Unicode
- Referrals and Continuations
- Schema Discovery
- Extensibility (controls, extended operations, and more)
slapd is an LDAP directory server that runs on many different platforms. You can use it to provide a directory service of your very own.
What is slurpd and what can it do?
slurpdis a daemon that, with slapd help, provides replicated service. It is responsible for distributing changes made to the master slapd database out to the various slapd replicas. It frees slapd from having to worry that some replicas might be down or unreachable when a change comes through; slurpd handles retrying failed requests automatically. slapd and slurpd communicate through a simple text file that is used to log changes.
The topic of LDAP seems to be little bit complicated at the beginning, so we will start with a simple example to for demonstration purposes.
We will use two machines in this example: a client and a server, both running Red Hat Enterprise Linux 5.4. We will use the OpenLDAP rpm package that’s available with Red Hat. The setup is:
Server: station1.example.com 192.168.0.1 Client: station2.example.com 192.168.0.2To demonstrate some of the functionality of an LDAP server, we will add local users to “station1.example.com” (our Server) BEFORE we configure it as an LDAP server. Then, we will configure it as an LDAP Server so that all the users (i.e. /etc/passwd and /etc/shadow and /etc/group contents) will be imported to the LDAP database, and finally after configuring “station2.example.com” as an LDAP client, we will verify our configuration by listing the users that the system can see which should include the users that we created on “station1.example.com”.
We will break out configuration into a very simple steps. We will start with the server “station1.example.com”:
1. Create test users:
[root@station1 ~]# useradd user1 [root@station1 ~]# useradd user2 [root@station1 ~]# useradd user32. Install the following packages (rpms):
[root@station1 ~]# yum install openldap-servers-2.3.43-3.el5 [root@station1 ~]# yum install openldap-2.3.43-3.el5 [root@station1 ~]# yum install openldap-clients-2.3.43-3.el53. Edit the LDAP config file to add the name of our suffix (in this case, it’s dc=example,dc=com). Edit only three lines:
[root@station1 ~]# vi /etc/openldap/slapd.conf suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" ... rootpw 123 [root@station1 ~]#In the above file, we only edited three lines to make “dc=example,dc=com” because that’s our suffix in this demo. We also made the root password (rootpw) = 123, that’s the root admin for LDAP. Password is store in text format here for simplicity.
4. The next step is to migrate the local files (/etc/passwd, /etc/shadow, and /etc/group) contents to an LDIF file. This is done using scripts that are ready with the packages we installed at the beginning
[root@station1 migration]# cd /usr/share/openldap/migration/ [root@station1 migration]# ./migrate_base.pl > a.ldif [root@station1 migration]# ./migrate_passwd.pl /etc/passwd >> a.ldif [root@station1 migration]# ./migrate_group.pl /etc/group >> a.ldifThe resulting file “a.ldif” is a text file, you can read the file to verify that the contents were migrated properly.
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" is the distinguished name of the entry; it's neither an attribute nor a part of the entry. "cn=John Doe" is the entry's RDN (Relative Distinguished Name), and "dc=example,dc=com" is the DN of the parent entry, where "dc" denotes 'Domain Component'. The other lines show the attributes in the entry. Attribute names are typically mnemonic strings, like "cn" for common name, "dc" for domain component, "mail" for e-mail address and "sn" for surname.
5. Since the LDIF file is ready, we can now build the LDAP database:
First check the existing LDAP database (it should be empty):
[root@station1 ~]# ls /var/lib/ldap/ openldap-severs-update.log [root@station1 ~]#There’s only one empty log file, that’s fine. Now we can build the database:
[root@station1 ~]#ldapadd -x -D "cn=Manager,dc=<example>,dc=<COM>" -W -l /usr/share/openldap/migration/a.ldif Where -v enable verbose mode -x Use simple authentication instead of SASL. -D binddn Use the Distinguished Name binddn to bind to the LDAP directory. For SASL binds, the server is expected to ignore this value. -W Prompt for simple authentication. This is used instead of specifying the password on the command line. -l ldif-file Read LDIF from the specified file instead of standard input.6. Verify that the database has been successfully created:
[root@station1 ~]# ls -l /var/lib/ldap total 1880 -rw-r--r-- 1 root root 2048 Oct 21 12:28 alock -rw------- 1 root root 36864 Oct 21 12:25 cn.bdb -rw------- 1 root root 24576 Oct 21 12:25 __db.001 -rw------- 1 root root 278528 Oct 21 12:25 __db.002 -rw------- 1 root root 270336 Oct 21 12:25 __db.003 -rw------- 1 root root 98304 Oct 21 12:25 __db.004 -rw------- 1 root root 352256 Oct 21 12:25 __db.005 -rw------- 1 root root 24576 Oct 21 12:25 __db.006 -rw------- 1 root root 36864 Oct 21 12:25 dn2id.bdb -rw------- 1 root root 8192 Oct 21 12:25 gidNumber.bdb -rw------- 1 root root 114688 Oct 21 12:25 id2entry.bdb -rw------- 1 root root 10485760 Oct 21 12:25 log.0000000001 -rw------- 1 root root 8192 Oct 21 12:25 loginShell.bdb -rw------- 1 root root 8192 Oct 21 12:25 memberUid.bdb -rw------- 1 root root 8192 Oct 21 12:25 nisMapName.bdb -rw------- 1 root root 20480 Oct 21 12:25 objectClass.bdb -rw-r--r-- 1 root root 37 Oct 21 11:54 openldap-severs-update.log -rw------- 1 root root 8192 Oct 21 12:25 ou.bdb -rw------- 1 root root 20480 Oct 21 12:25 uid.bdb -rw------- 1 root root 8192 Oct 21 12:25 uidNumber.bdb [root@station1 ~]#As we can see, the database files have been created. We can check that the database is actually true to the LDIF we created by executing this command:
[root@station1 ~]# slapcatThe output should match the contents of the LDIF file generated earlier.
7. Change permissions of the LDAP database files. Since they will be accessed by the LDAP daemon, then they shouldn’t have “root” as owner and group.
[root@station1 ~]# chown ldap.ldap * /var/lib/ldap [root@station1 ~]# ls -l /var/lib/ldap total 1880 -rw-r--r-- 1 ldap ldap 2048 Oct 21 12:28 alock -rw------- 1 ldap ldap 36864 Oct 21 12:25 cn.bdb -rw------- 1 ldap ldap 24576 Oct 21 12:25 __db.001 -rw------- 1 ldap ldap 278528 Oct 21 12:25 __db.002 -rw------- 1 ldap ldap 270336 Oct 21 12:25 __db.003 -rw------- 1 ldap ldap 98304 Oct 21 12:25 __db.004 -rw------- 1 ldap ldap 352256 Oct 21 12:25 __db.005 -rw------- 1 ldap ldap 24576 Oct 21 12:25 __db.006 -rw------- 1 ldap ldap 36864 Oct 21 12:25 dn2id.bdb -rw------- 1 ldap ldap 8192 Oct 21 12:25 gidNumber.bdb -rw------- 1 ldap ldap 114688 Oct 21 12:25 id2entry.bdb -rw------- 1 ldap ldap 10485760 Oct 21 12:25 log.0000000001 -rw------- 1 ldap ldap 8192 Oct 21 12:25 loginShell.bdb -rw------- 1 ldap ldap 8192 Oct 21 12:25 memberUid.bdb -rw------- 1 ldap ldap 8192 Oct 21 12:25 nisMapName.bdb -rw------- 1 ldap ldap 20480 Oct 21 12:25 objectClass.bdb -rw-r--r-- 1 ldap ldap 37 Oct 21 11:54 openldap-severs-update.log -rw------- 1 ldap ldap 8192 Oct 21 12:25 ou.bdb -rw------- 1 ldap ldap 20480 Oct 21 12:25 uid.bdb -rw------- 1 ldap ldap 8192 Oct 21 12:25 uidNumber.bdb [root@station1 ~]#8. Now the LDAP server is ready! Start the service:
[root@station1 ~]# service ldap start
Checking configuration files for slapd: bdb_db_open: Warning - No DB_CONFIG file found in directory /var/lib/ldap: (2)
Expect poor performance for suffix dc=example,dc=com.
config file testing succeeded
[ OK ]
[root@station1 ~]#
Next, we will configure “station2.example.com” as an LDAP client. It’s very simple, we will use the GUI for simplicity:Execute this command to lunch the GUI tool:
[root@station2 ~]# system-config-authenticationChoose “Enable LDAP Support”, then click “configure LDAP”:
Enter the settings as follows then click “OK” :
Now that the system “station2.example.com” should be configured as an LDAP client, we can test our configuration with LDAP Search commands:
1. To use LDAP commands, we should have this pacakge installed in the clients:
[root@station2 ~]# rpm -qa|grep ldap-clients openldap-clients-2.3.43-3.el5 [root@station2 ~]2. Execute ldapsearch commands to retrieve information about the users we configured on the LDAP server:
[root@station2 ~]# ldapsearch -x uid=user1 Enter LDAP Password: # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: uid=user1 # requesting: ALL # # user1, People, example.com dn: uid=user1,ou=People,dc=example,dc=com uid: user1 cn: user1 objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount userPassword:: e2NyeXB0fSQxJHlIUGxDcWk2JGJnbHFKSVpaUlFIbGFrSzFwNzlvby8= shadowLastChange: 15268 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 500 gidNumber: 500 homeDirectory: /home/user1 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root@station2 ~]#This means that both the client and server are working fine.
Note that this document comes without warranty of any kind. But every effort
has been made to provide the information as accurate as possible. I welcome
emails from any readers with comments, suggestions, and corrections at
webmaster_at admin@linuxhowto.in
Copyright © 2012 LINUXHOWTO.IN
Copyright © 2012 LINUXHOWTO.IN
No comments:
Post a Comment