Filling an OpenLDAP database: Difference between revisions

From SaruWiki
Jump to navigation Jump to search
m (→‎Creating your first Organizational Units: ldif file layout corrected)
Line 32: Line 32:
This effectively stops the server, writes the information directly into the database, and then starts the server again.
This effectively stops the server, writes the information directly into the database, and then starts the server again.


Another way to do the ''same'' thing, would be to add the information with the ''ldapadd'' command:
Another way to do (almost) the ''same'' thing, would be to add the information with the ''ldapadd'' command:
  ldapadd -c -x -D cn=admin,dc=saruman,dc=biz -W -f orgunits.ldif
  ldapadd -c -x -D cn=admin,dc=saruman,dc=biz -W -f orgunits.ldif
This binds to the OpenLDAP server (which must be running) using the admin account. This causes the command to request the admin password, and then feed the contents from the ''orgunits.ldif'' file into the database.
This binds to the OpenLDAP server (which must be running) using the admin account. This in turn causes the command to request the admin password, and then feed the contents from the ''orgunits.ldif'' file into the database. However, adding data to a live database precludes you from adding system controlled attributes, as structuralObjectClass is. So for live addition, remove those four particular lines from the ''orgunits.ldif'' file.
 
Explanation of this difference: ''slapadd'' is meant as a restore tool, so it must (and can) create system controlled attributes. ''ldapadd'' is a modification tool, so it shouldn't need to (and can't) create these attributes.


==Migrating User, Password and Group entries to an LDAP server==
==Migrating User, Password and Group entries to an LDAP server==

Revision as of 18:08, 25 September 2008

Creating your first Organizational Units

On the offchance that you haven't installed LAM, and thus haven't created the organizational units people, groups, hosts and domains, here's how to create them manually. Create a file containing the following information:

dn: ou=people,dc=saruman,dc=biz
ou: people
objectClass: top
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit

dn: ou=groups,dc=saruman,dc=biz
ou: groups
objectClass: top
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit

dn: ou=hosts,dc=saruman,dc=biz
ou: hosts
objectClass: top
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit

dn: ou=domains,dc=saruman,dc=biz
ou: domains
objectClass: top
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit

Let's suppose this file is named orgunits.ldif. Now from the directory that contains this file, feed the information into your OpenLDAP using the following commands:

sudo invoke-rc.d slapd stop
sudo slapadd -c -v -l orgunits.ldif
sudo invoke-rc.d slapd start

This effectively stops the server, writes the information directly into the database, and then starts the server again.

Another way to do (almost) the same thing, would be to add the information with the ldapadd command:

ldapadd -c -x -D cn=admin,dc=saruman,dc=biz -W -f orgunits.ldif

This binds to the OpenLDAP server (which must be running) using the admin account. This in turn causes the command to request the admin password, and then feed the contents from the orgunits.ldif file into the database. However, adding data to a live database precludes you from adding system controlled attributes, as structuralObjectClass is. So for live addition, remove those four particular lines from the orgunits.ldif file.

Explanation of this difference: slapadd is meant as a restore tool, so it must (and can) create system controlled attributes. ldapadd is a modification tool, so it shouldn't need to (and can't) create these attributes.

Migrating User, Password and Group entries to an LDAP server

It's nice to have an LDAP, but it's much nicer if it is filled with information. We'll try to enter all existing users and groups from the host server into LDAP, using the available migration tools.

Creating new users

If we need new users (e.g. when the server you're setting up is spankin' new) then we can create them in several ways. Let's discuss two of them:

Adding a user with an LDIF file

To add a user with the LDAP command line utilities, we first need to create an LDIF file. This file is a simple text file, that could look something like this:

# Create the user group
dn: cn=networkusers,ou=groups,dc=saruman,dc=biz
objectClass: posixGroup
description: Internal network users
gidNumber: 10001
cn: TestGroup

# Create a new user:
dn: uid=sixpacjo,ou=people,dc=saruman,dc=biz
objectclass: top
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: shadowAccount
cn: Joe Sixpack
description: Your Average Network User
givenName: Joe
sn: Sixpack
mail: joe.sixpack@saruman.biz
# The Unix login-name for the user:
uid: sixpacjo
# The group and user IDs:
gidNumber: 10001
uidNumber: 10001
# The Unix account data:
homeDirectory: /home/sixpacjo
loginShell: /bin/bash
# The encrypted password for the user:
userPassword: {crypt}$1$qs70ynbk$UBuewN7ZdIvqavIxkxdmX0

For a line-by-line explanation of this LDIF file, go here.

AHA! you'll say. But how do I get to this encrypted password? It's simple. Try this:

openssl passwd -crypt "secret"

The argument -crypt makes openssl generate a password using the standard Unix password algorithm; this is also the default setting. An alternative would be to use -1 instead of -crypt, which'll give you an MD5 encrypted password. Ofcourse, using an MD5 encrypted password means you have to change the last line of the LDIF file to

userPassword: {MD5}$1$yCuyTf63$NoAjuX/dYBmE29hXrsDb41

Note that prefixing the used encryption method is totally fine with OpenLDAP, but it actually is not according to the LDAP standard; this LDIF file can be understood by OpenLDAP, but not by every other piece of LDAP software out there...

Adding a user with LAM