With LDAP installed, configured, and running, you can now fill the directory with people. This involves yet more LDAP acronyms and is by no means an easy task, so do not worry if you have to reread this several times before it sinks in.
First, create the file base.ldif. You will use this to define the base components of your system: the domain and the address book. LDIF is an acronym standing for LDAP Data Interchange Format, and it is the standard way of recording user data for insertion into an LDAP directory. Here are the contents we used for our example:
dn: dc=hudzilla,dc=org objectClass: top objectClass: dcObject objectClass: organization dc: hudzilla o: Hudzilla Dot Org dn: ou=People,dc=hudzilla,dc=org ou: People objectClass: top objectClass: organizationalUnit
This file contains two individual entities, separated by an empty line. The first is our organization, hudzilla.org. The dn lines you know already, as they define each object uniquely in the scope of the directory. The objectClass directive specifies which attributes should be allowed for this entity and which attributes should be required. In this case, we use it to set the DC to hudzilla and to set o (the name of the organization) to Hudzilla Dot Org.
The next entity defines the address book, People, in which all our people will be stored. It is defined as an organizational unit, which is what the ou stands for. An organizational unit really is just an arbitrary partition of your company. You might have OUs for marketing, accounting, and management, for example.
You need to customize the file to your own requirements. Specifically, change the DCs to those you specified in your slapd.conf.
Next, create and edit a new file called people.ldif. This is where you will define entries for your address book, also using LDIF. Here are the people we used in our example:
dn: cn=Paul Hudson,ou=People,dc=hudzilla,dc=org objectClass: inetOrgPerson cn: Paul Hudson cn: Hudzilla mail: [email protected]
sn: Hudson dn: cn=Nick Veitch,ou=People,dc=hudzilla,dc=org objectClass: inetOrgPerson cn: Nick Veitch cn: CrackAttackKing mail: [email protected]
There are three entries there, again separated by empty lines. Each person has a DN that is made up of his common name (CN), organizational unit (OU), and domain components (DCs). He also has an objectClass definition, inetOrgPerson, which gives him standard attributes such as an email address, a photograph, and a telephone number. Entities of type inetOrgPerson must have a CN and an SN (surname) so you will see them in this code.
Note also that each person has two common names: his actual name and a nickname. Not all LDAP clients support more than one CN, but there is no harm in having several as long as the main one comes first and is listed in the DN.
Having multiple key/value pairs, like multiple CNs, is one of the defining features of LDAP. In today's interconnected world, few people can be defined using a single set of attributes, because people now have home phone numbers, work phone numbers, cell phone numbers, pager numbers, plus several email addresses, and potentially even a selection of offices where they hot desk. Using multiple CNs and other attributes allows you to properly record these complex scenarios.
The jpegPhoto attribute for the first entity has very particular syntax. Immediately after the colon, you use an opening angle bracket (<) followed by a space and then the location of the person's picture. Because the picture is local, it is prefixed with file://. It is in /home/paul/paulhudson.jpg, so the whole URL is file:///home/paul/paulhudson.jpg.
After you have edited the file to include the people in your organization, save it and close the editor. As root, issue these two commands:
ldapadd x W D "cn=root,dc=hudzilla,dc=org" f base.ldif ldapadd x W D "cn=root,dc=hudzilla,dc=org" f people.ldif
The ldapadd command is used to convert LDIF into live directory content and, most important, can be executed while your LDAP server is running. The -x parameter means to use only basic authentication, which means you need to supply the root username and password. -W means to prompt you for the password. -d lets you specify a DN for your username; and immediately after the
-d, we specify the root DN as set earlier in siapd.conf. Finally, -f means to use the LDIF from the following file.
When you run them, you are prompted for the root password you set earlier. Upon entering it, you should see confirmation messages as your entries are added, like this:
adding new entry "cn=Paui Hudson,ou=Peopie,dc=hudziiia,dc=org"
If you see an error such as idap_bind: Can't contact ldap server (-1), you need to start the LDAP server by typing /etc/init.d/siapd start. The most likely sources of other errors are typing errors. LDIF is a precise format, even down to its use of whitespace.
To test that the directory has been populated and that your configuration settings are correct, run this command:
idapsearch x 'objectciass=*'
The idapsearch command does what you might expect: It queries the LDAP directory from the command line. Again, -x means to use simple authentication, although in this situation you do not need to provide any credentials because you are only reading from the directory. The objectciass=* search specifies to return any entry of any objectciass, so the search will return all the entries in your directory.
You can amend the search to be more specific. For example:
idapsearch x 'cn=Ni*'
This command returns all people with a common name that begins with Ni. If you get results for your searches, you are ready to configure your clients.
OpenLDAP needs specific permissions for its files. The /var/lib/idap directory should be owned by user ldap and group ldap, with permissions 600. If you experience problems, try running chmod 600 /var/lib/ldap.
Was this article helpful?