12.4. Creating a New Database on Fedora

Problem

Your Fedora OpenLDAP installation does not yet include an administrative user, nor any users at all. You need to create an admin user to manage your directory, and you also need to define your suffix.

Solution

There are three steps:

  1. Create an LDIF file with the new information.

  2. Use the ldapadd command to add the new entries to Berkeley DB.

  3. Configure read-write permissions in slapd.conf.

First, create the LDAP Data Interchange Format (LDIF) file, which in this example is named first.ldif. Substitute your own domain name, company name, description, and password. Trim all leading and trailing spaces. A blank line separates entries, comments must go on their own lines, and there must be one space after each colon:

	##first.ldif
	# root dn entry
	dn: dc=alrac,dc=net
	objectclass: dcObject
	objectclass: organization
	o: Alrac's Fine Cookies and Beer
	dc: alrac

	# directory administrator
	dn: cn=admin,dc=alrac,dc=net
	objectClass: simpleSecurityObject
	objectClass: organizationalRole
	cn: admin
	userPassword: bigsecretword
	description: LDAP administrator

Second, run this ldapadd command. You'll be asked for the rootpw password you entered in slapd.conf:

	# ldapadd -x -D "cn=admin,dc=alrac,dc=net" -W -f first.ldif
	Enter LDAP Password:
	adding new entry "dc=alrac,dc=net"
	adding new entry "cn=admin,dc=alrac,dc=net"

Let us admire the new entries:

	$ ldapsearch -x -b 'dc=alrac,dc=net'
	[...]
	# alrac.net
	dn: dc=alrac,dc=net
	objectClass: dcObject
	objectClass: organization
	o: Alrac's Fine Cookies and Beer
	dc: alrac

	# admin, alrac.net
	dn: cn=admin,dc=alrac,dc=net
	objectClass: simpleSecurityObject
	objectClass: organizationalRole
	cn: admin
	userPassword: fji8Hu11hs
	description: LDAP administrator
	[...]

Comment out the rootpw and rootdn entries in slapd.conf. Then, restart OpenLDAP, and view the directory entries again:

	# /etc/init.d/ldap restart
	$ ldapsearch -x -b 'dc=alrac,dc=net'

Now, the admin user has complete control of the database.

Discussion

Mind the whitespace in your LDIF files. A blank line delimits each entry. A single leading space on a line means it is a continuation of the previous line, commas delimit each name/value pair, and any literal commas must be escaped, like this example shows:

	dn: uid=twhale,ou=people,ou=factory,ou=bluecollars,
	 o=widgets\, inc.,c=au,dc=widgets,dc=com

The admin user can have any name, such as db-admin,or ldapgoddess, or whatever you like. You'll see the Manager user in a lot of LDAP documentation, which is the same as our admin user.

The first.ldif file contains two separate entries. The first one defines our suffix. That's the rootx of our directory tree. The second entry defines the admin user, who is given read/write access to the entire database in slapd.conf. All other users are given read access only. They can change their own passwords, and they cannot see anyone else's password.

Each entry requires its own unique DN. Remember, these are made by combining the Relative Distinguished Name (RDN) with all of its ancestors.(See this chapter's Introduction for more information.)

Your LDIF files don't have to use the .ldif file extension. It's probably less confusing to keep it, though.

Why replace the rootdn and rootpw in slapd.conf? The rootdn is the database superuser, just like our admin user, and rootpw is the rootdn's password. This is necessary for the initial creation of your directory, and you may prefer to configure your database superuser this way. Some admins don't want a rootdn in slapd.conf for security reasons. Some admins don't want the superuser in the directory, like our admin user, for security reasons. If you do keep it in slapd.conf, make triple-sure that file is protected—make it readable only by the owner and group owner, and turn on write access only when you need to make changes.

The admin ACLs we created in the previous recipe in slapd.conf are not necessary if you choose to keep rootdn in slapd.conf. rootdn does not need explicit access rules.

Fire up a graphical LDAP browser like gq to see the available attributes for each objectClass. This is an easy way to see what your choices are. You may also look in the schema files in /etc/ldap/schema/ (/etc/openldap on Fedora). inetOrgPerson is one you'll use a lot. /etc/ldap/schema/inetorgperson.schema defines what attributes are required, and which ones are optional:

	# inetOrgPerson
	# The inetOrgPerson represents people who are associated with an
	# organization in some way. It is a structural class and is derived
	# from the organizationalPerson which is defined in X.521 [X521].
	objectclass ( 2.16.840.1.113730.3.2.2
	    NAME 'inetOrgPerson'
	    DESC 'RFC2798: Internet Organizational Person'
	    SUP organizationalPerson
	    STRUCTURAL
	    MAY (

	         audio $ businessCategory $ carLicense $ departmentNumber $ 
	         displayName $ employeeNumber $ employeeType $ givenName $ 
	         homePhone $ homePostalAddress $ initials $ jpegPhoto $ 
	         labeledURI $ mail $ manager $ mobile $ o $ pager $ 
	         photo $ roomNumber $ secretary $ uid $ userCertificate $ 
	         x500uniqueIdentifier $ preferredLanguage $ 
	         userSMIMECertificate $ userPKCS12 )
		)

As this shows, all of them are optional. The simpleSecurityObject is less complex; it has only a single required attribute:

	objectclass ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject'
	    DESC 'RFC1274: simple security object'
	    SUP top AUXILIARY
	    MUST userPassword )

See Also