Authenticate users on your Linux system by the numbers with the versatile LDAP.
5. Create the Users with All the Needed Attributes

After you have done the four preceding steps, your computer is ready to authenticate on the LDAP directory. But is your directory also ready? To prepare your directory for authentication, you need to put all relevant user attributes in it, all the information normally in /etc/passwd and /etc/shadow. Otherwise, how could you use your precious resources without a proper user ID and all the other nice things from these files? To get the information, you can use some Perl scripts specially created to get information out of the files on your computer and into the LDAP database, or you can make your own LDIF file to import the users you want.

If you want to do it all automatically, many Perl scripts are available at There are scripts to import almost all settings that can also be in an NIS database—your password files, your host file, your network file, etc. Before you can use them, however, you have to edit the general configuration file, In this file you have to change some parameters that specify the location where the data has to be created. Especially important are DEFAULT_MAIL_DOMAIN and DEFAULT_BASE; they specify the DNS domain in which users have their e-mail accounts and the LDAP container in which users must be created, respectively. Once that's done, you can start the import. For each different kind of information, there's a separate script; probably the most interesting of them are, which imports all network information, and, which imports the users on your system.

The other way to get things done is by means of an LDIF file, the contents of which must be added to the database using ldapadd. The most important thing for this file is that all the right properties are specified. Listing 4 shows an example of how to ensure this.

Listing 4. Sample Property Specification for an LDIF File

There are only two disadvantages to this method. First, the home directory isn't automatically created when you create the user in the LDIF database, but there's a PAM module named that can take care of it for you. The other problem is user passwords; there's no nice method to get them in encrypted form in the database. A less elegant way to accomplish this is to create the user once in /etc/passwd and /etc/shadow, give him or her a password and copy the encrypted string out of /etc/shadow and into your LDIF file.

Once this is done, you can try the whole thing out. Delete the user from your local files, open a login prompt and try to log in; it should work just fine.

Sander van Vugt ( lives in the Netherlands. He works for Azlan Training as a Linux, Novell and Nortel technical trainer and has written several books and articles about Linux.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: indepth and pam_mkhomedir

Anonymous's picture

There is better alternative to using pam_mkhomedir which suffers following limitations. Check this at

1) There are some applications which never need to authenticate users
But they need home dirs. -- for example smtp servers which deliver mail to home.

2) Some do use other ways to authenticate, bypassing pam all together.

3) Servers must be root so that pam can creates home dirs. Otherwise
make /home silimiar in permissions to /tmp -- famous sshd problem

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState