OpenLDAP 2.4.11: Difference between revisions

From SaruWiki
Jump to navigation Jump to search
m (added BDB backends)
(ldap info getting usable...)
Line 1: Line 1:
== OpenLDAP installation==
== OpenLDAP installation and configuration==


Note: we're going to install OpenLDAP on our server as [http://www.openldap.org/doc/admin24/config.html#Local%20Directory%20Service the local directory service], without replication, referrals or other advanced features.
Note: we're going to install OpenLDAP on our server as [http://www.openldap.org/doc/admin24/config.html#Local%20Directory%20Service the local directory service], without replication, referrals or other advanced features.
Line 5: Line 5:
Installing OpenLDAP on your Debian server is ridiculously simple. Just make sure your server is up-to-date (''sudo apt-get update'' followed by ''sudo apt-get upgrade''), and then install the two main components for your OpenLDAP server:
Installing OpenLDAP on your Debian server is ridiculously simple. Just make sure your server is up-to-date (''sudo apt-get update'' followed by ''sudo apt-get upgrade''), and then install the two main components for your OpenLDAP server:
  sudo apt-get install slapd ldap-utils
  sudo apt-get install slapd ldap-utils
The Debian configuration script will ask you for only one single thing: an administrator password. As always: generate a strong password! When you've provided the password, the LDAP database is created with the administrator name "admin" and as a base directory path, something based on your DNS name. Suppose your internal domain is "amber.lan", then the script will generate ''suffix "dc=amber,dc=lan,dc="''. Since this might not always be the most convenient configuration, we recommend that you run the configuration again using ''dpkg-reconfigure slapd''. Interestingly enough, this reconfiguration asks you many ''more'' questions. The answers could look like this:
The Debian configuration script will ask you for only one single thing: an administrator password. As always: generate a strong password! When you've provided the password, the LDAP database is created with the administrator name "admin" and as a base directory path, something based on your DNS name. Suppose your internal domain is "amber.lan.", then the script will generate ''suffix "dc=amber,dc=lan,dc="''. The last, empty, domain component (''dc'') is caused by the trailing dot in your DNS name: the DNS root.
 
Since this might not always be the most convenient configuration, we recommend that you run the configuration again using ''dpkg-reconfigure slapd''. Interestingly enough, this reconfiguration asks you many ''more'' questions. The answers could look like this:
  omit OpenLDAP config:  no
  omit OpenLDAP config:  no
  DNS domain name:      saruman.biz
  DNS domain name:      saruman.biz
  Organization name:    Saruman Ltd.
  Organization name:    Saruman
  Administrator passwd:  wEt3udes
  Administrator passwd:  wEt3udes
  Database backend:      HDB
  Database backend:      HDB
Line 14: Line 16:
  Move old DB:          yes
  Move old DB:          yes
  Allow LDAPv2:          no
  Allow LDAPv2:          no
As you can see, the reconfiguration yields much more configuration options than plain installation - although really you'll probably answer most questions with their default values anyway, with the exception of the database backend, which by default is BDB.
As you can see, the reconfiguration yields much more configuration options than plain installation - although really you'll probably answer most questions with their default values anyway, with the exception of the database backend, which by default is BDB.<br>
Anyway, the above method of configuring yields you an LDAP database with only two objects in it:
* a single Organization (o="Saruman") with Distinguished Name dn="dc=saruman,dc=biz"
* a single administrator with Common Name cn="admin", and dn="cn=admin,dc=saruman,dc=biz"


The database that your OpenLDAP server uses is a standard Berkeley DB (BDB) database. Now we most likely will require some other databases as well in our server setup, something modern like PostgreSQL or MySQL - so why don't we configure our OpenLDAP to use this same database as well? For the answer, see [http://www.openldap.org/doc/admin24/intro.html#LDAP%20vs%20RDBMS here] - in short, the LDAP tree structure does not lend itself very well to inclusion in a modern relational database. Thus, we advise to stick with the Berkeley database provided with OpenLDAP.<br>
The database that your OpenLDAP server uses is a standard Berkeley DB (BDB) database. Now we most likely will require some other databases as well in our server setup, something modern like PostgreSQL or MySQL - so why don't we configure our OpenLDAP to use this same database as well? For the answer, see [http://www.openldap.org/doc/admin24/intro.html#LDAP%20vs%20RDBMS here] - in short, the LDAP tree structure does not lend itself very well to inclusion in a modern relational database. Thus, we advise to stick with the Berkeley database provided with OpenLDAP.<br>
Thus, for the database backend, we have the choice between two almost identical flavours: the ''bdb'' backend is the recommended primary backend for a normal slapd database. It uses the Oracle Berkeley DB package, referred to as ''BDB'', to store data. It makes extensive use of indexing and caching to speed data access. ''hdb'' is a variant of the ''bdb'' backend that uses a hierarchical database layout which supports subtree renames. It is otherwise identical to the ''bdb'' behavior, and all the same configuration options apply
Now, for the database backend, we have the choice between two almost identical flavours: the ''bdb'' backend is the recommended primary backend for a normal slapd database. It uses the Oracle Berkeley DB package, referred to as ''BDB'', to store data. It makes extensive use of indexing and caching to speed data access. ''hdb'' is a variant of the ''bdb'' backend that uses a hierarchical database layout which supports subtree renames. It is otherwise identical to the ''bdb'' behavior, and all the same configuration options apply.
 
==Installing and configuring an LDAP Account Manager==
It's perfectly normal to manipulate your LDAP from the command line using LDAP utilities like ''ldapsearch'', ''ldapadd'', ''ldapdelete'' and ''ldapmodify'', as well as ''slapcat'', ''slappasswd'' etcetera. However, many people find a GUI for LDAP indispensible. If you are amongst those, then for you, my friend, the question becomes: which graphic tool do you want to use? Many people speak highly of ''[http://gq-project.org/ gq]'', ''[http://luma.sourceforge.net/about.html luma]'' and ''[http://phpldapadmin.sourceforge.net/ phpldapadmin]''. We go for ''lam'' ([http://lam.sourceforge.net/index.htm LDAP acount Manager]).

Revision as of 23:12, 6 September 2008

OpenLDAP installation and configuration

Note: we're going to install OpenLDAP on our server as the local directory service, without replication, referrals or other advanced features.

Installing OpenLDAP on your Debian server is ridiculously simple. Just make sure your server is up-to-date (sudo apt-get update followed by sudo apt-get upgrade), and then install the two main components for your OpenLDAP server:

sudo apt-get install slapd ldap-utils

The Debian configuration script will ask you for only one single thing: an administrator password. As always: generate a strong password! When you've provided the password, the LDAP database is created with the administrator name "admin" and as a base directory path, something based on your DNS name. Suppose your internal domain is "amber.lan.", then the script will generate suffix "dc=amber,dc=lan,dc=". The last, empty, domain component (dc) is caused by the trailing dot in your DNS name: the DNS root.

Since this might not always be the most convenient configuration, we recommend that you run the configuration again using dpkg-reconfigure slapd. Interestingly enough, this reconfiguration asks you many more questions. The answers could look like this:

omit OpenLDAP config:  no
DNS domain name:       saruman.biz
Organization name:     Saruman
Administrator passwd:  wEt3udes
Database backend:      HDB
DB remove after purge: no
Move old DB:           yes
Allow LDAPv2:          no

As you can see, the reconfiguration yields much more configuration options than plain installation - although really you'll probably answer most questions with their default values anyway, with the exception of the database backend, which by default is BDB.
Anyway, the above method of configuring yields you an LDAP database with only two objects in it:

  • a single Organization (o="Saruman") with Distinguished Name dn="dc=saruman,dc=biz"
  • a single administrator with Common Name cn="admin", and dn="cn=admin,dc=saruman,dc=biz"

The database that your OpenLDAP server uses is a standard Berkeley DB (BDB) database. Now we most likely will require some other databases as well in our server setup, something modern like PostgreSQL or MySQL - so why don't we configure our OpenLDAP to use this same database as well? For the answer, see here - in short, the LDAP tree structure does not lend itself very well to inclusion in a modern relational database. Thus, we advise to stick with the Berkeley database provided with OpenLDAP.
Now, for the database backend, we have the choice between two almost identical flavours: the bdb backend is the recommended primary backend for a normal slapd database. It uses the Oracle Berkeley DB package, referred to as BDB, to store data. It makes extensive use of indexing and caching to speed data access. hdb is a variant of the bdb backend that uses a hierarchical database layout which supports subtree renames. It is otherwise identical to the bdb behavior, and all the same configuration options apply.

Installing and configuring an LDAP Account Manager

It's perfectly normal to manipulate your LDAP from the command line using LDAP utilities like ldapsearch, ldapadd, ldapdelete and ldapmodify, as well as slapcat, slappasswd etcetera. However, many people find a GUI for LDAP indispensible. If you are amongst those, then for you, my friend, the question becomes: which graphic tool do you want to use? Many people speak highly of gq, luma and phpldapadmin. We go for lam (LDAP acount Manager).