Filling an OpenLDAP database: Difference between revisions
m (→Creating your first Organizational Units: ldif file layout corrected) |
m (→Creating your first Organizational Units: added slapadd) |
||
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...