OpenLDAP - Revision history

Saruman!: /* Post-install reconfiguration */

2016-02-21T21:44:27Z

Post-install reconfiguration

← Older revision		Revision as of 21:44, 21 February 2016
Line 96:		Line 96:
	* a single Organization (o="Saruman") with Distinguished Name dn="dc=saruman,dc=biz"		* 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"		* a single administrator with Common Name cn="admin", and dn="cn=admin,dc=saruman,dc=biz"
	Also note that the reconfiguration creates a backup of the "old" LDAP database in a directory with a name like ''/var/backups/unknown-2.4.23-7.ldapdb''; if you just reconfigured after installation, then you probably don't need this backup, so you can remove it.		Also note that the reconfiguration creates a backup of the "old" LDAP database in a directory with a name like ''/var/backups/unknown-2.4.40+dfsg-1+deb8u2.ldapdb''; if you just reconfigured after installation, then you probably don't need this backup, so you can remove it.

	The database that your OpenLDAP server uses is a standard Berkeley DB (BDB/HDB) 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. Now, for the database backend, we have the choice between ~~two almost identical~~ flavours:		The database that your OpenLDAP server uses is a standard Berkeley DB (BDB/HDB) database or something similar. 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 one of the specialized databases provided with Debian/OpenLDAP. Now, for the database backend, we have the choice between the following flavours:
	* the ''bdb'' backend used to be 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.		* the ''bdb'' backend used to be 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.
	* the ''hdb'' backend 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.		* the ''hdb'' backend 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.
	In Debian 6.0 "~~Squeeze~~" with OpenLDAP 2.4.23, ~~HDB~~ is the default backend.		* the ''mdb'' backend is a transactional backend built on OpenLDAP's [https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database Lightning Memory-Mapped Database] (LMDB).
			In Debian 8.0 "Jessie" with OpenLDAP 2.4.40, MDB is the default backend.

	==OpenLDAP server configuration==		==OpenLDAP server configuration==

Saruman!: /* Post-install reconfiguration */

2016-02-21T21:39:39Z

Post-install reconfiguration

← Older revision		Revision as of 21:39, 21 February 2016
Line 89:		Line 89:
	Organization name: Saruman		Organization name: Saruman
	Administrator passwd: wEt3udes		Administrator passwd: wEt3udes
	Database backend: ~~HDB~~		Database backend: MDB
	DB remove after purge: yes		DB remove after purge: yes
	Move old DB: yes		Move old DB: yes
Line 96:		Line 96:
	* a single Organization (o="Saruman") with Distinguished Name dn="dc=saruman,dc=biz"		* 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"		* a single administrator with Common Name cn="admin", and dn="cn=admin,dc=saruman,dc=biz"
	Also note that the reconfiguration creates a backup of the "old" LDAP database in a directory with a name like ''/var/~~backup~~/unknown-2.4.23-7.ldapdb''; if you just reconfigured after installation, then you probably don't need this backup, so you can remove it.		Also note that the reconfiguration creates a backup of the "old" LDAP database in a directory with a name like ''/var/backups/unknown-2.4.23-7.ldapdb''; if you just reconfigured after installation, then you probably don't need this backup, so you can remove it.

	The database that your OpenLDAP server uses is a standard Berkeley DB (BDB/HDB) 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. Now, for the database backend, we have the choice between two almost identical flavours:		The database that your OpenLDAP server uses is a standard Berkeley DB (BDB/HDB) 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. Now, for the database backend, we have the choice between two almost identical flavours:

Saruman!: /* Adding schemas */ path

2012-04-01T15:28:13Z

Adding schemas: path

← Older revision		Revision as of 15:28, 1 April 2012
Line 304:		Line 304:
	To add a schema, you need a schema in LDIF format, which you can then add to the LDAP database using the ''ldapadd'' command.		To add a schema, you need a schema in LDIF format, which you can then add to the LDAP database using the ''ldapadd'' command.
	Suppose you have a schema file ''samba.schema'' which you've copied to the ''/etc/ldap/schema'' directory. You'd first have to convert this to a suitable LDIF file. This can be done using ''slaptest'', however ''slaptest'' requires access to the other schemas that your new schema is building on. So we now do this:		Suppose you have a schema file ''samba.schema'' which you've copied to the ''/etc/ldap/schema'' directory. You'd first have to convert this to a suitable LDIF file. This can be done using ''slaptest'', however ''slaptest'' requires access to the other schemas that your new schema is building on. So we now do this:
	* ~~under ''/tmp'' we~~ create a file ''schema_convert.conf'' with the ~~following~~ content (Note that we're including the schema files of all the schemas that are already in our LDAP server):		* We create a file ''schema_convert.conf'' with the content shown below. Note that we're including the schema files of all the schemas that are already in our LDAP server. Furthermore, because we may need it again with the next schema addition, it makes sense to save this file under ''/etc/ldap/schema'':
	include /etc/ldap/schema/core.schema		include /etc/ldap/schema/core.schema
	include /etc/ldap/schema/cosine.schema		include /etc/ldap/schema/cosine.schema
Line 312:		Line 312:
	* now we create a working directory where ''slaptest'' can put our new LDIF file, and have ''slaptest'' create the configuration:		* now we create a working directory where ''slaptest'' can put our new LDIF file, and have ''slaptest'' create the configuration:
	root@easton2:/tmp# '''mkdir /tmp/ldif_output'''		root@easton2:/tmp# '''mkdir /tmp/ldif_output'''
	root@easton2:/tmp# '''slaptest -f /~~tmp~~/schema_convert.conf -F /tmp/ldif_output'''		root@easton2:/tmp# '''slaptest -f /etc/ldap/schema/schema_convert.conf -F /tmp/ldif_output'''
	config file testing succeeded		config file testing succeeded
	root@easton2:/tmp# '''_'''		root@easton2:/tmp# '''_'''

Saruman!: /* Adding schemas */ more

2012-04-01T15:25:39Z

Adding schemas: more

@@ Line 280: / Line 280: @@
 ==Adding schemas==
-A major task in LDAP maintenance is the addition of LDAP schemas. By default, only 4 schemas will be present in your LDAP server: ''core'', ''cosine'', ''nis'' and ''inetorgperson''. Any other schema, -- say, for Samba -- would need to be added. However, let's first check which schemas are already installed. Let's try two different methods, and see what they'll show out of the box:
+A major task in LDAP maintenance is the addition of LDAP schemas. By default, only 4 schemas will be present in your LDAP server: ''core'', ''cosine'', ''nis'' and ''inetorgperson''. Any other schema, -- say, for Samba -- would need to be added.
   root@easton2:/tmp# '''ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=schema,cn=config "(objectClass=olcSchemaConfig)" dn'''
   dn: cn=schema,cn=config
@@ Line 299: / Line 301: @@
   -rw------- 1 openldap openldap  2802 Jun 13 17:39 cn={3}inetorgperson.ldif
   root@easton2:/tmp# '''_'''
+===Creating a suitable LDIF file for the schema===
 To add a schema, you need a schema in LDIF format, which you can then add to the LDAP database using the ''ldapadd'' command.
 Suppose you have a schema file ''samba.schema'' which you've copied to the ''/etc/ldap/schema'' directory. You'd first have to convert this to a suitable LDIF file. This can be done using ''slaptest'', however ''slaptest'' requires access to the other schemas that your new schema is building on. So we now do this:
-* under ''/tmp'' we create a file ''schema_convert.conf'' with the following content:<pre>include /etc/ldap/schema/core.schema<br>include /etc/ldap/schema/cosine.schema<br>include /etc/ldap/schema/nis.schema<br>include /etc/ldap/schema/inetorgperson.schema<br>include /etc/ldap/schema/samba.schema</pre>Note that we're including the schema files of all the schemas that are already in our LDAP server,
+* under ''/tmp'' we create a file ''schema_convert.conf'' with the following content (Note that we're including the schema files of all the schemas that are already in our LDAP server):
-* now we create a working directory where ''slaptest'' can put our new LDIF file:<pre>mkdir /tmp/ldif_output</pre>
+ include /etc/ldap/schema/core.schema
-* h
+ include /etc/ldap/schema/cosine.schema

Saruman!: /* Adding schemas */ layout

2012-04-01T14:59:45Z

Adding schemas: layout

← Older revision		Revision as of 14:59, 1 April 2012
Line 302:		Line 302:
	To add a schema, you need a schema in LDIF format, which you can then add to the LDAP database using the ''ldapadd'' command.		To add a schema, you need a schema in LDIF format, which you can then add to the LDAP database using the ''ldapadd'' command.
	Suppose you have a schema file ''samba.schema'' which you've copied to the ''/etc/ldap/schema'' directory. You'd first have to convert this to a suitable LDIF file. This can be done using ''slaptest'', however ''slaptest'' requires access to the other schemas that your new schema is building on. So we now do this:		Suppose you have a schema file ''samba.schema'' which you've copied to the ''/etc/ldap/schema'' directory. You'd first have to convert this to a suitable LDIF file. This can be done using ''slaptest'', however ''slaptest'' requires access to the other schemas that your new schema is building on. So we now do this:
	* under ''/tmp'' we create a file ''schema_convert.conf'' with the following content:~~<br>~~<pre>include /etc/ldap/schema/core.schema<br>include /etc/ldap/schema/cosine.schema<br>include /etc/ldap/schema/nis.schema<br>include /etc/ldap/schema/inetorgperson.schema<br>include /etc/ldap/schema/samba.schema</pre~~><br~~>Note that we're including the schema files of all the schemas that are already in our LDAP server,		* under ''/tmp'' we create a file ''schema_convert.conf'' with the following content:<pre>include /etc/ldap/schema/core.schema<br>include /etc/ldap/schema/cosine.schema<br>include /etc/ldap/schema/nis.schema<br>include /etc/ldap/schema/inetorgperson.schema<br>include /etc/ldap/schema/samba.schema</pre>Note that we're including the schema files of all the schemas that are already in our LDAP server,
	* now we create a working directory where ''slaptest'' can put our new LDIF file:~~<br>~~<pre>mkdir /tmp/ldif_output</pre>		* now we create a working directory where ''slaptest'' can put our new LDIF file:<pre>mkdir /tmp/ldif_output</pre>
			* h

Saruman!: /* Adding schemas */ new

2012-04-01T14:58:54Z

Adding schemas: new

← Older revision		Revision as of 14:58, 1 April 2012
Line 301:		Line 301:

	To add a schema, you need a schema in LDIF format, which you can then add to the LDAP database using the ''ldapadd'' command.		To add a schema, you need a schema in LDIF format, which you can then add to the LDAP database using the ''ldapadd'' command.
	Suppose you have a schema file ''samba.schema'' which you've copied to the ''/etc/ldap/schema'' directory. You'd first convert this to an LDIF file using		Suppose you have a schema file ''samba.schema'' which you've copied to the ''/etc/ldap/schema'' directory. You'd first have to convert this to a suitable LDIF file. This can be done using ''slaptest'', however ''slaptest'' requires access to the other schemas that your new schema is building on. So we now do this:
	~~root@easton2~~:/etc/ldap/schema~~# '''slaptest -f samba~~.schema -F /etc/ldap/schema ~~-s "cn=~~schema~~,cn=config"'''~~		* under ''/tmp'' we create a file ''schema_convert.conf'' with the following content:<br><pre>include /etc/ldap/schema/core.schema<br>include /etc/ldap/schema/cosine.schema<br>include /etc/ldap/schema/nis.schema<br>include /etc/ldap/schema/inetorgperson.schema<br>include /etc/ldap/schema/samba.schema</pre><br>Note that we're including the schema files of all the schemas that are already in our LDAP server,
			* now we create a working directory where ''slaptest'' can put our new LDIF file:<br><pre>mkdir /tmp/ldif_output</pre>
	~~ldapadd -x -H~~ ldap://<~~LDAP SERVER~~>/ ~~-D "cn=config" -W -f~~ <~~SCHEMA~~>.~~ldif~~
	~~Enter~~ LDAP ~~Password:~~
	~~adding~~ new ~~entry "cn=~~<~~SCHEMA~~>~~,cn=schema,cn=config"~~

Saruman!: /* Method 1: interactive CLI tool */ emphasis

2011-06-19T17:43:34Z

Method 1: interactive CLI tool: emphasis

← Older revision		Revision as of 17:43, 19 June 2011
Line 218:		Line 218:
	olcDbIndex: objectClass eq		olcDbIndex: objectClass eq

	root@easton2:/tmp# ldapmodify -Y EXTERNAL -H ldapi:///		root@easton2:/tmp# '''ldapmodify -Y EXTERNAL -H ldapi:///'''
	SASL/EXTERNAL authentication started		SASL/EXTERNAL authentication started
	SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth		SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
	SASL SSF: 0		SASL SSF: 0
	dn: olcDatabase={1}hdb,cn=config		'''dn: olcDatabase={1}hdb,cn=config'''
	add: olcDbIndex		'''add: olcDbIndex'''
	olcDbIndex: cn eq		'''olcDbIndex: cn eq'''
	olcDbIndex: uid eq		'''olcDbIndex: uid eq'''

	modifying entry "olcDatabase={1}hdb,cn=config"		modifying entry "olcDatabase={1}hdb,cn=config"

Saruman!: /* Adding or modifying (configuration) information */ finished edits

2011-06-19T13:07:22Z

Adding or modifying (configuration) information: finished edits

@@ Line 229: / Line 229: @@
   modifying entry "olcDatabase={1}hdb,cn=config"
-  root@easton2:/tmp# ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config olcDatabase={1}hdb olcDbIndex
+  root@easton2:/tmp# '''ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config olcDatabase={1}hdb olcDbIndex'''
   dn: olcDatabase={1}hdb,cn=config
   olcDbIndex: objectClass eq
@@ Line 236: / Line 236: @@
   root@easton2:/tmp# '''_'''
 Modifying works almost the same; we only need keyword ''replace'' instead of ''add'':
+Deleting information from an LDAP tree rarely ever happens, because once an attribute is used for anything, you aren't allowed to delete it, only modify it. However, if you want to delete anything, you can use the changetype "modify" with action "delete":
 ===Method 2: use an ldif file===

Saruman!: /* Adding or modifying (configuration) information */ addition

2011-06-19T11:21:30Z

Adding or modifying (configuration) information: addition

@@ Line 213: / Line 213: @@
 The simple way of changing anything in the database goes like this:
 ===Method 1: interactive CLI tool===
 ===Method 2: use an ldif file===
 ===Method 3: use an LDAP browser===

Saruman!: restructure

2011-06-19T08:24:07Z

restructure

← Older revision		Revision as of 08:24, 19 June 2011
Line 103:		Line 103:
	In Debian 6.0 "Squeeze" with OpenLDAP 2.4.23, HDB is the default backend.		In Debian 6.0 "Squeeze" with OpenLDAP 2.4.23, HDB is the default backend.

	==OpenLDAP configuration==		==OpenLDAP server configuration==
	<small>(text from http://www.rjsystems.nl/en/2100-d6-openldap-provider.php)</small> As of OpenLDAP 2.4.23-3, the ''slapd'' runtime configuration is fully LDAP-enabled. The default is to manage it using the standard LDAP operations with data in LDIF. The old ''slapd.conf'' format is still supported, but since that file must now be converted to the new ''slapd-config'' format to allow runtime changes to be saved, it seems likely that the developers will eventually phase it out. Therefore, we'll focus only on the new configuration method, the main advantage of which is that any changes made are immediately active, so it is no longer necessary to restart ''slapd'' after making configuration changes.		<small>(text from http://www.rjsystems.nl/en/2100-d6-openldap-provider.php)</small> As of OpenLDAP 2.4.23-3, the ''slapd'' runtime configuration is fully LDAP-enabled. The default is to manage it using the standard LDAP operations with data in LDIF. The old ''slapd.conf'' format is still supported, but since that file must now be converted to the new ''slapd-config'' format to allow runtime changes to be saved, it seems likely that the developers will eventually phase it out. Therefore, we'll focus only on the new configuration method, the main advantage of which is that any changes made are immediately active, so it is no longer necessary to restart ''slapd'' after making configuration changes.

Line 210:		Line 210:
	root@easton2:/tmp# '''_'''		root@easton2:/tmp# '''_'''

	===Adding or modifying configuration information===		==Adding or modifying (configuration) information==
	The simple way of changing anything in the database goes like this:		The simple way of changing anything in the database goes like this:
			===Method 1: interactive CLI tool===
			===Method 2: use an ldif file===
			===Method 3: use an LDAP browser===
			With this method, you just use your LDAP browser for the addition or modification, according to its specific usage instructions. In the back, the tool will communicate with the LDAP server as you would in the previous methods. Note however, that this method relies on a bind account in the configuration database, which is a serious security risk.

	===Adding schemas===		==Adding schemas==
	A major task in LDAP maintenance is the addition of LDAP schemas. By default, only 4 schemas will be present in your LDAP server: ''core'', ''cosine'', ''nis'' and ''inetorgperson''. Any other schema, -- say, for Samba -- would need to be added. However, let's first check which schemas are already installed. Let's try two different methods, and see what they'll show out of the box:		A major task in LDAP maintenance is the addition of LDAP schemas. By default, only 4 schemas will be present in your LDAP server: ''core'', ''cosine'', ''nis'' and ''inetorgperson''. Any other schema, -- say, for Samba -- would need to be added. However, let's first check which schemas are already installed. Let's try two different methods, and see what they'll show out of the box:
	root@easton2:/tmp# '''ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=schema,cn=config "(objectClass=olcSchemaConfig)" dn'''		root@easton2:/tmp# '''ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=schema,cn=config "(objectClass=olcSchemaConfig)" dn'''
Line 241:		Line 245:
	Enter LDAP Password:		Enter LDAP Password:
	adding new entry "cn=<SCHEMA>,cn=schema,cn=config"		adding new entry "cn=<SCHEMA>,cn=schema,cn=config"

	~~==OpenLDAP finetuning==~~
	To finetune the OpenLDAP configuration, we make some changes to the main configuration file for the OpenLDAP server, ''/etc/ldap/slapd.conf''. Note: make SURE that the permissions on this file are rw-r----- (640) and the owner is ''root:openldap'', so that OpenLDAP can read the configuration, but only you can change it.

	When changing the configuration of your LDAP server, keep in mind that everything ''above'' the first ''backend hdb'' (or ''backend <something>'') should contain only global directives, and everything under it only backend directives that will apply to all databases that you're going to run under that backend type. In our examples, we're only going to run a single database of a single backend type, so all backend directives will apply to our single database. Nevertheless, you should put your global directives above the backend declaration, and the rest below.