Change the suffix line to match your domain components, separated by commas. For example:
suffix "dc=hudzilla,dc=org"
The next line defines the root DN, which is another LDAP acronym meaning distinguished name. A DN is a complete descriptor of a person in your directory: her name and the domain in which she resides. For example:
rootdn "cn=root,dc=hudzilla,dc=org"
CN is yet another LDAP acronym, this time meaning common name. A common name is just that — the name a person is usually called. Some people have several common names. Andrew Hudson is a common name, but that same user might also have the common name Andy Hudson. In our rootdn line, we define a complete user: common name root at domain hudzilla.org. These lines are essentially read backward. LDAP goes to org first, searches org for hudzilla, and then searches hudzilla for root.
The rootdn is important because it is more than just another person in your directory. The root LDAP user is like the root user in Linux. It is the person who has complete control over the system and can make whatever changes he wants to.
Now comes a slightly more complex part: The LDAP root user needs to be given a pass word. The easiest way to do this is to open a new terminal window alongside your existing one. Switch to root in the new terminal also, and type slappasswd. This tool generates password hashes for OpenLDAP, using the SHA1 hash algorithm. Enter a password when it prompts you. When you have entered and confirmed your password, you should see output like this:
{SSHA}qMVxFT2K1UUmrA89Gd7z6EK3gRLDIo2W
That is the password hash generated from your password. Yours will be different from the one shown here, but what is important is that it has {SSHA} at the beginning to denote it uses SHA1. You now need to switch back to the other terminal (the one editing slapd.conf) and add this line below the rootdn line:
rootpw <your password hash>
You should replace <your password hash> with the full output from slappasswd, like this:
rootpw {SSHA}qMVxFT2K1UUmrA89Gd7z6EK3gRLDIo2W
That sets the LDAP root password to the one you just generated with slappasswd. That is the last change you need to make in the slapd.conf file, so save your changes and close your editor.
Back in the terminal, run the slaptest command. This checks your slapd.conf file for errors and ensures you edited it correctly. Presuming there are no errors, run these two commands:
chkconfig ldap on
service ldap start
These tell Fedora to start OpenLDAP each time you boot up, and to start it right now.
The final configuration step is to tell Fedora which DN it should use if none is specified. You do so by going to System Settings and selecting Authentication. In the dialog box that appears, check Enable LDAP Support in both the User Information tab and Authentication tab. Next, click the Configure LDAP button, enter your DCs (for example, dc=hudzilla,dc=org) for the LDAP Search Base DN, and enter 127.0.0.1 for the LDAP Server. Click OK and then click OK again.
Checking Enable LDAP Support does not actually change the way in which your users log in. Behind the scenes, this forces Fedora to set up the ldap.conf file in /etc/openldap so that LDAP searches that do not specify a base search start point are directed to your DC.
Populating Your Directory
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 use this file 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 the organization, hudzilla.org. The dn lines you know already; 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
maiclass="underline" paul@hudzilla.org
jpegPhoto:< file:///home/paul/paulhudson.jpg
sn: Hudson
dn: cn=Andrew Hudson,ou=People,dc=hudzilla,dc=org
objectClass: inetOrgPerson
cn: Andrew Hudson
cn: IzAndy
maiclass="underline" andrew@hudzilla.org
sn: Hudson
dn: cn=Nick Veitch,ou=People,dc=hudzilla,dc=org
objectClass: inetOrgPerson
cn: Nick Veitch
cn: CrackAttackKing
maiclass="underline" nick@hudzilla.org
sn: Veitch
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.