Now that you've added the data to the directory, you can actually determine whether it works with the command
ldapsearch -L -b "dc=azlan, dc=com" -W "(objectclass=*)"
You should get all data in the directory returned as a result (see Figure 1).
Now that you've come this far, you can do a lot of things with your directory. You could, for example, simply take your browser and look for data in your LDAP directory. That isn't the most interesting part though. As an alternative, you can configure your Linux client so that authentication is no longer done on your local password and shadow files, but on the LDAP server, giving you one central point from which to administer all user data instead of hundreds of computers with all their individual password files. To make it all happen, do the following.
Before you can configure your client to authenticate on an LDAP server, you should make sure all necessary software is installed. If you are using RPMs, the packages openldap, auth_ldap and nss_ldap should be present. You can verify that with rpm -q packagename. If they are not present, you can find them at rpmfind.com.
Often, two files are named ldif.conf on systems. One is in /etc and is used by nss_ldap and pam_ldap to determine where they can find required information. The other is in /etc/openldap and is used by utilities such as ldapadd and ldapsearch to determine in which container they should work. As stated before, delete one of them and make a link to the other to make things easy. Once that's done, you can put the necessary data in it. For a simple configuration you only need two lines:
BASE dc=azlan, dc=com HOST laetitia.azlan.com
The first line specifies the default container where the client should look for data, and the second line gives the name of your LDAP server. Of course, your system must be able to resolve this name by means of DNS or something similar, otherwise you could use an IP address.
Next, you have to tell the nameservice switch where it should look for data. Do this by editing the file /etc/nsswitch.conf; it should contain the following lines:
passwd: files ldap shadow: files ldap group: files ldap
With these lines, your system first tries to authenticate users on your local password files, and if that doesn't work, it tries to authenticate on the LDAP database. So if a user exists in /etc/passwd, and he or she gives the password that is in /etc/shadow, LDAP will not be used.
Next, you should take a look at PAM. This is the mechanism used on most modern Linux distributions by the different programs that have anything to do with user authentication. It can, for example, be used by login, but also by FTP, su, ssh, passwd, etc. In recent versions of PAM, each of these programs has a configuration file, normally in /etc/pam.d. In this configuration file you can specify the PAM modules that should be used by the module.
If you want the login process to do authentication on LDAP, the corresponding configuration file could look like Listing 3.
Let's give a brief explanation. There are four processes in which user and password information is used. First there is authentication, represented in the PAM file by “auth”. This process lets you into the system, and one of its responsibilities is to check your password. Then there is “account”, which verifies whether the user has any account restrictions that could prevent him or her from logging in to the system. After that there is “password”, which is used if you want to change your password. Lastly, “session” specifies the tasks to be done if you want to use other resources on the system on which you are already authenticated.
Each of these modules has specific tasks. These tasks are specified in the PAM modules, and one of the most important is pam_unix.so. This module takes care of the normal passwd/shadow authentication and is normally required if you want access to the system. But if you are using LDAP, it is also good if LDAP is able to let you in. So before the line where pam_unix is called, there is a line where pam_ldap is called. It is not required (you still want to be able to use your system if the LDAP server is down) but it is sufficient. That is, if you can be authenticated by pam_ldap, you don't have to go to pam_unix afterward. Besides these two major modules, there are some minor modules that are not discussed here.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- July 2016 Issue of Linux Journal
- Tibbo Technology's Tibbo Project System
- Client-Side Performance
- Sony Settles in Linux Battle
- Peppermint 7 Released
- Libarchive Security Flaw Discovered
- Profiles and RC Files
- The Giant Zero, Part 0.x
- Snappy Moves to New Platforms
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide