Page MenuHomeFreeBSD

D10600.id44148.diff
No OneTemporary

D10600.id44148.diff

Index: chapter.xml
===================================================================
--- chapter.xml
+++ chapter.xml
@@ -2245,10 +2245,20 @@
<authorgroup>
<author>
<personname>
+ <firstname>Rocky</firstname>
+ <surname>Hotas</surname>
+ </personname>
+ <contrib>Draft by </contrib>
+ </author>
+ </authorgroup>
+
+ <authorgroup>
+ <author>
+ <personname>
<firstname>Tom</firstname>
<surname>Rhodes</surname>
</personname>
- <contrib>Written by </contrib>
+ <contrib>Originally contributed by </contrib>
</author>
</authorgroup>
</info>
@@ -2340,31 +2350,36 @@
<indexterm><primary>LDAP Server</primary></indexterm>
<para>&os; does not provide a built-in <acronym>LDAP</acronym>
- server. Begin the configuration by installing the <package
- role="port">net/openldap24-server</package> package or port.
- Since the port has many configurable options, it is
- recommended that the default options are reviewed to see if
- the package is sufficient, and to instead compile the port if
- any options should be changed. In most cases, the defaults
- are fine. However, if SQL support is needed, this option must
- be enabled and the port compiled using the instructions in
- <xref linkend="ports-using"/>.</para>
-
- <para>Next, create the directories to hold the data and to store
- the certificates:</para>
-
- <screen>&prompt.root; <userinput>mkdir /var/db/openldap-data</userinput>
-&prompt.root; <userinput>mkdir /usr/local/etc/openldap/private</userinput></screen>
+ server. Begin the configuration by installing <package
+ role="port">net/openldap-server</package> package or
+ port:
+
+ <screen>&prompt.root; <userinput>pkg install openldap-server</userinput></screen>
+
+ There is a large set of default options enabled in
+ the <link
+ xlink:href="&url.articles.linux-users;/software.html">
+ package</link>. To review them:
+ <command>pkg info openldap-server</command>. If they are not
+ sufficient (for example if SQL support is needed), please
+ consider recompiling the port using the appropriate <link
+ xlink:href="&url.books.handbook;/ports-using.html">
+ framework</link>.</para>
+
+ <para>The installation creates the directory
+ <filename>/var/db/openldap-data</filename> to hold the data.
+ The directory to store the certificates must be
+ created:</para>
- <para>Copy over the database configuration file:</para>
-
- <screen>&prompt.root; <userinput>cp /usr/local/etc/openldap/DB_CONFIG.example /var/db/openldap-data/DB_CONFIG</userinput></screen>
+ <screen>&prompt.root; <userinput>mkdir /usr/local/etc/openldap/private</userinput></screen>
<para>The next phase is to configure the certificate authority.
The following commands must be executed from
<filename>/usr/local/etc/openldap/private</filename>. This is
important as the file permissions need to be restrictive and
- users should not have access to these files. To create the
+ users should not have access to these files. More detailed
+ information about certificates and their parameters can be
+ found in <xref linkend="openssl"/>. To create the
certificate authority, start with this command and follow the
prompts:</para>
@@ -2385,7 +2400,9 @@
<para>During the certificate generation process, be sure to
correctly set the <literal>Common Name</literal> attribute.
- Once complete, sign the key:</para>
+ The Certificate Signing Request must be signed with the
+ Certificate Authority in order to be used as a valid
+ certificate:</para>
<screen>&prompt.root; <userinput>openssl x509 -req -days <replaceable>365</replaceable> -in server.csr -out ../server.crt -CA ../ca.crt -CAkey ca.key -CAcreateserial</userinput></screen>
@@ -2398,172 +2415,417 @@
<para>Remember to use the same <literal>Common Name</literal>
attribute when prompted. When finished, ensure that a total
of eight (8) new files have been generated through the
- proceeding commands. If so, the next step is to edit
- <filename>/usr/local/etc/openldap/slapd.conf</filename> and
- add the following options:</para>
-
- <programlisting>TLSCipherSuite HIGH:MEDIUM:+SSLv3
-TLSCertificateFile /usr/local/etc/openldap/server.crt
-TLSCertificateKeyFile /usr/local/etc/openldap/private/server.key
-TLSCACertificateFile /usr/local/etc/openldap/ca.crt</programlisting>
-
- <para>Then, edit
- <filename>/usr/local/etc/openldap/ldap.conf</filename> and add
- the following lines:</para>
-
- <programlisting>TLS_CACERT /usr/local/etc/openldap/ca.crt
-TLS_CIPHER_SUITE HIGH:MEDIUM:+SSLv3</programlisting>
-
- <para>While editing this file, uncomment the following entries
- and set them to the desired values: <option>BASE</option>,
- <option>URI</option>, <option>SIZELIMIT</option> and
- <option>TIMELIMIT</option>. Set the <option>URI</option> to
- contain <option>ldap://</option> and
- <option>ldaps://</option>. Then, add two entries pointing to
- the certificate authority. When finished, the entries should
- look similar to the following:</para>
-
- <programlisting>BASE dc=example,dc=com
-URI ldap:// ldaps://
-
-SIZELIMIT 12
-TIMELIMIT 15
-
-TLS_CACERT /usr/local/etc/openldap/ca.crt
-TLS_CIPHER_SUITE HIGH:MEDIUM:+SSLv3</programlisting>
-
- <para>The default password for the server should then be
- changed:</para>
-
- <screen>&prompt.root; <userinput>slappasswd -h "{SHA}" &gt;&gt; /usr/local/etc/openldap/slapd.conf</userinput></screen>
-
- <para>This command will prompt for the password and, if the
- process does not fail, a password hash will be added to the
- end of <filename>slapd.conf</filename>. Several hashing
- formats are supported. Refer to the manual page for
- <command>slappasswd</command> for more information.</para>
-
- <para>Next, edit
- <filename>/usr/local/etc/openldap/slapd.conf</filename> and
- add the following lines:</para>
-
- <programlisting>password-hash {sha}
-allow bind_v2</programlisting>
-
- <para>The <option>suffix</option> in this file must be updated
- to match the <option>BASE</option> used in
- <filename>/usr/local/etc/openldap/ldap.conf</filename> and
- <option>rootdn</option> should also be set. A recommended
- value for <option>rootdn</option> is something like
- <option>cn=Manager</option>. Before saving this file, place
- the <option>rootpw</option> in front of the password output
- from <command>slappasswd</command> and delete the old
- <option>rootpw</option>. The end result should
- look similar to this:</para>
-
- <programlisting>TLSCipherSuite HIGH:MEDIUM:+SSLv3
-TLSCertificateFile /usr/local/etc/openldap/server.crt
-TLSCertificateKeyFile /usr/local/etc/openldap/private/server.key
-TLSCACertificateFile /usr/local/etc/openldap/ca.crt
-rootpw {SHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g=</programlisting>
-
- <para>Finally, enable the <application>OpenLDAP</application>
- service in <filename>/etc/rc.conf</filename> and set the
- <acronym>URI</acronym>:</para>
-
- <programlisting>slapd_enable="YES"
-slapd_flags="-4 -h ldaps:///"</programlisting>
-
- <para>At this point the server can be started and tested:</para>
-
- <screen>&prompt.root; <userinput>service slapd start</userinput></screen>
-
- <para>If everything is configured correctly, a search of the
- directory should show a successful connection with a single
- response as in this example:</para>
+ proceeding commands.</para>
- <screen>&prompt.root; <userinput>ldapsearch -Z</userinput>
-# extended LDIF
+ <para>The daemon running the OpenLDAP server is
+ <filename>slapd</filename>. Its configuration can be
+ performed through a <filename>slapd.conf</filename>
+ configuration file, or through a database file
+ <filename>slapd.ldif</filename>.
+ The former way is deprecated by OpenLDAP:</para>
+
+ <tip>
+ <para>The use of <filename>slapd.ldif</filename> is
+ strongly recommended.</para>
+ </tip>
+
+ <para>Configuration examples for
+ <filename>slapd.ldif</filename> can be found <link xlink:href=
+ "http://www.openldap.org/doc/admin24/slapdconf2.html">here</link>
+ and in
+ <filename>/usr/local/etc/openldap/slapd.ldif.sample</filename>.
+ Each part of this file is uniquely identified through a
+ <literal>dn:</literal> (Distinguished Name), beginning with
+ the <emphasis>global configuration</emphasis> entry. Be sure
+ that no blank lines are between the <literal>dn:</literal>
+ statement and the desired end of the section. Options are
+ documented in <link
+ xlink:href="https://www.freebsd.org/cgi/man.cgi?query=slapd-config&amp;manpath=FreeBSD+11.0-RELEASE+and+Ports">slapd-config(5)</link>.
+ In the following example, TLS will be used to implement a
+ secure channel.</para>
+
+ <programlisting>#
+# See slapd-config(5) for details on configuration options.
+# This file should NOT be world readable.
#
-# LDAPv3
-# base &lt;dc=example,dc=com&gt; (default) with scope subtree
-# filter: (objectclass=*)
-# requesting: ALL
+dn: cn=config
+objectClass: olcGlobal
+cn: config
#
+#
+# Define global ACLs to disable default read access.
+#
+olcArgsFile: /var/run/openldap/slapd.args
+olcPidFile: /var/run/openldap/slapd.pid
+olcTLSCertificateFile: /usr/local/etc/openldap/server.crt
+olcTLSCertificateKeyFile: /usr/local/etc/openldap/private/server.key
+olcTLSCACertificateFile: /usr/local/etc/openldap/ca.crt
+#olcTLSCipherSuite: HIGH
+olcTLSProtocolMin: 3.1
+olcTLSVerifyClient: never</programlisting>
+
+ <para>The Certificate Authority, server certificate and server
+ private key files must be specified here. It is recommended
+ to let the clients choose the security cipher and omit option
+ <literal>olcTLSCipherSuite</literal> (incompatible with TLS
+ clients other than <filename>openssl</filename>). Option
+ <literal>olcTLSProtocolMin</literal> lets the server require a
+ minimum security level: it is recommended. While
+ verification is mandatory for the server, it is not for the
+ client: <literal>olcTLSVerifyClient: never</literal>.</para>
-# search result
-search: 3
-result: 32 No such object
-
-# numResponses: 1</screen>
+ <para>The second part is about the backend modules and can be
+ configured as follows:</para>
- <note>
- <para>If the command fails and the configuration looks
- correct, stop the <command>slapd</command> service and
- restart it with debugging options:</para>
-
- <screen>&prompt.root; <userinput>service slapd stop</userinput>
-&prompt.root; <userinput>/usr/local/libexec/slapd -d -1</userinput></screen>
- </note>
+ <programlisting>#
+# Load dynamic backend modules:
+#
+dn: cn=module,cn=config
+objectClass: olcModuleList
+cn: module
+olcModulepath: /usr/local/libexec/openldap
+olcModuleload: back_mdb.la
+#olcModuleload: back_bdb.la
+#olcModuleload: back_hdb.la
+#olcModuleload: back_ldap.la
+#olcModuleload: back_passwd.la
+#olcModuleload: back_shell.la</programlisting>
+
+ <para>The third part is devoted to load the needed <literal>
+ ldif</literal> schemas to be used by the databases: they
+ are essential.</para>
+
+ <programlisting>dn: cn=schema,cn=config
+objectClass: olcSchemaConfig
+cn: schema
+
+include: file:///usr/local/etc/openldap/schema/core.ldif
+include: file:///usr/local/etc/openldap/schema/cosine.ldif
+include: file:///usr/local/etc/openldap/schema/inetorgperson.ldif
+include: file:///usr/local/etc/openldap/schema/nis.ldif</programlisting>
- <para>Once the service is responding, the directory can be
- populated using <command>ldapadd</command>. In this example,
- a file containing this list of users is first created. Each
- user should use the following format:</para>
-
- <programlisting>dn: dc=<replaceable>example</replaceable>,dc=<replaceable>com</replaceable>
-objectclass: dcObject
-objectclass: organization
-o: <replaceable>Example</replaceable>
-dc: <replaceable>Example</replaceable>
-
-dn: cn=<replaceable>Manager</replaceable>,dc=<replaceable>example</replaceable>,dc=<replaceable>com</replaceable>
-objectclass: organizationalRole
-cn: <replaceable>Manager</replaceable></programlisting>
-
- <para>To import this file, specify the file name. The following
- command will prompt for the password specified earlier and the
- output should look something like this:</para>
-
- <screen>&prompt.root; <userinput>ldapadd -Z -D "cn=<replaceable>Manager</replaceable>,dc=<replaceable>example</replaceable>,dc=<replaceable>com</replaceable>" -W -f <replaceable>import.ldif</replaceable></userinput>
-Enter LDAP Password:
-adding new entry "dc=example,dc=com"
+ <para>Then, the frontend configuration follows:</para>
-adding new entry "cn=Manager,dc=example,dc=com"</screen>
+ <programlisting># Frontend settings
+#
+dn: olcDatabase={-1}frontend,cn=config
+objectClass: olcDatabaseConfig
+objectClass: olcFrontendConfig
+olcDatabase: {-1}frontend
+olcAccess: to * by * read
+#
+# Sample global access control policy:
+# Root DSE: allow anyone to read it
+# Subschema (sub)entry DSE: allow anyone to read it
+# Other DSEs:
+# Allow self write access
+# Allow authenticated users read access
+# Allow anonymous users to authenticate
+#
+#olcAccess: to dn.base="" by * read
+#olcAccess: to dn.base="cn=Subschema" by * read
+#olcAccess: to *
+# by self write
+# by users read
+# by anonymous auth
+#
+# if no access controls are present, the default policy
+# allows anyone and everyone to read anything but restricts
+# updates to rootdn. (e.g., "access to * by * read")
+#
+# rootdn can always read and write EVERYTHING!
+#
+olcPasswordHash: {SSHA}
+# {SSHA} is already the default for olcPasswordHash</programlisting>
- <para>Verify the data was added by issuing a search on the
- server using <command>ldapsearch</command>:</para>
+ <para>The following section describes the configuration
+ backend: this will be the <emphasis>only way</emphasis> to
+ access the global configuration for the system
+ administrator, once this procedure is completed. Thus, it
+ is <emphasis>extremely important</emphasis> that all the
+ needed options are specified here. In particular, a root
+ password must be chosen: together with the default
+ administrator username <literal>cn=config</literal>, it will
+ let the server administrator to later edit the configuration
+ as the super-user. Note that, without the specification of
+ a <literal>olcRootPW</literal> here, after this file is
+ imported as a configuration file for
+ <filename>slapd</filename>, no one will be able to modify this
+ global configuration. This is highly undesirable. If anyway
+ something is wrong with the actual configuration, a way to
+ modify it will be shown later. A password can be generated
+ using <filename>slappasswd</filename> in a shell and its
+ entire output must be used as a value for
+ <literal>olcRootPW</literal>.</para>
+
+ <programlisting>dn: olcDatabase={0}config,cn=config
+objectClass: olcDatabaseConfig
+olcDatabase: {0}config
+olcAccess: to * by * none
+olcRootPW: {SSHA}iae+lrQZILpiUdf16Z9KmDmSwT77Dj4U</programlisting>
+
+ <para>The last section shown here is about the database
+ backend, used for the <emphasis>actual contents</emphasis>
+ of the <acronym>LDAP</acronym> directory. This database can
+ be used to add new groups and users as regards the domain
+ <literal>domain.example</literal>. Here, the database type
+ <literal>mdb</literal> is used and another super-user is
+ specified: it will be only able to modify this database and
+ not the previous sections of <filename>slapd.ldif</filename>.
+ Here, a username <literal>olcRootDN</literal> can be
+ specified, being related to the domain. A password can be
+ generated as before.</para>
+
+ <programlisting>#######################################################################
+# LMDB database definitions
+#######################################################################
+#
+dn: olcDatabase=mdb,cn=config
+objectClass: olcDatabaseConfig
+objectClass: olcMdbConfig
+olcDatabase: mdb
+olcDbMaxSize: 1073741824
+olcSuffix: dc=domain,dc=example
+olcRootDN: cn=mdbadmin,dc=domain,dc=example
+# Cleartext passwords, especially for the rootdn, should
+# be avoided. See slappasswd(8) and slapd-config(5) for details.
+# Use of strong authentication encouraged.
+olcRootPW: {SSHA}X2wHvIWDk6G76CQyCMS1vDCvtICWgn0+
+# The database directory MUST exist prior to running slapd AND
+# should only be accessible by the slapd and slap tools.
+# Mode 700 recommended.
+olcDbDirectory: /var/db/openldap-data
+# Indices to maintain
+olcDbIndex: objectClass eq</programlisting>
+
+ <para>In <link xlink:href=
+ "http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=tree;f=tests/data/regressions/its8444;h=8a5e808e63b0de3d2bdaf2cf34fecca8577ca7fd;hb=HEAD">this
+ repository</link>, four examples of
+ <filename>slapd.ldif</filename> files are available (they are
+ used as a 4-way multi master <acronym>LDAP</acronym> server).
+ At the bottom of <link
+ xlink:href="http://www.openldap.org/doc/admin24/slapdconf2.html">this
+ page</link>, section 5.4, also a way to convert an existing
+ <filename>slapd.conf</filename> into a valid
+ <filename>slapd.ldif</filename> is presented. Please note
+ that this may introduce some unuseful options.</para>
+
+ <para>Once the <filename>slapd.ldif</filename> configuration
+ is completed, this file must be imported in an empty
+ directory. It is recommended to create it with the
+ following name and location:</para>
+
+ <screen>&prompt.root; <userinput>mkdir /usr/local/etc/openldap/slapd.d/</userinput></screen>
+
+ <para>The commands suggested at points 9 and 10 in the <link
+ xlink:href="http://www.openldap.org/doc/admin24/quickstart.html">OpenLDAP
+ Quick Start guide</link> (which can be considered as a
+ reference for all the other operations) are currently wrong:
+ instead, it is advisable to use</para>
+
+ <screen>&prompt.root; <userinput>/usr/local/sbin/slapadd -n0 -F /usr/local/etc/openldap/slapd.d/ -l /usr/local/etc/openldap/slapd.ldif</userinput></screen>
+
+ <para>This will import the configuration database. To start
+ the slapd daemon,</para>
+
+ <screen>&prompt.root; <userinput>/usr/local/libexec/slapd -F /usr/local/etc/openldap/slapd.d/</userinput></screen>
+
+ <para>Option <literal>-d</literal> can be used for debugging,
+ as specified in <link xlink:href=
+ "https://www.freebsd.org/cgi/man.cgi?query=slapd&amp;sektion=8&amp;manpath=FreeBSD+11.0-RELEASE+and+Ports">slapd(8)</link>.
+ To verify that the server is running and working,</para>
- <screen>&prompt.user; <userinput>ldapsearch -Z</userinput>
+ <screen>&prompt.root; <userinput>ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts</userinput>
# extended LDIF
#
# LDAPv3
-# base &lt;dc=example,dc=com&gt; (default) with scope subtree
+# base &lt;&gt; with scope baseObject
# filter: (objectclass=*)
-# requesting: ALL
+# requesting: namingContexts
#
-# example.com
-dn: dc=example,dc=com
-objectClass: dcObject
-objectClass: organization
-o: Example
-dc: Example
-
-# Manager, example.com
-dn: cn=Manager,dc=example,dc=com
-objectClass: organizationalRole
-cn: Manager
+#
+dn:
+namingContexts: dc=domain,dc=example
# search result
-search: 3
+search: 2
result: 0 Success
-# numResponses: 3
-# numEntries: 2</screen>
+# numResponses: 2
+# numEntries: 1</screen>
+
+ <para>The server will still not be recognized by any client as
+ trusted, anyway. The certificates were created in
+ non-standard directories from the point of view of
+ <filename>openssl</filename>. In order for
+ <filename>openssl</filename> to work, the directories where
+ the certificates are stored must contain symbolic links (whose
+ names are composed by a hash) to the certificates. Even if
+ some <filename>openssl</filename> commands are already
+ available in the &os; base system, it is necessary now to
+ explicitly install the package:</para>
+
+ <screen>&prompt.root; <userinput>pkg install openssl</userinput></screen>
+
+ <para>This will provide the <link xlink:href=
+ "https://www.freebsd.org/cgi/man.cgi?query=c_rehash&amp;manpath=FreeBSD+11.0-RELEASE+and+Ports">c_rehash(1)</link>
+ tool. Now run</para>
+
+ <screen>&prompt.root; <userinput>c_rehash .</userinput></screen>
+
+ <para>from the directory where the CA is stored (in this
+ example, <filename>/usr/local/etc/openldap</filename>,
+ which contains the file <filename>ca.crt</filename>). This
+ utility must create a symlink for each
+ <filename>.pem</filename>, <filename>.crt</filename>,
+ <filename>.crl</filename> or <filename>.cer</filename> file
+ in the directory. Only this way <filename>
+ server.crt</filename> can be recognized as a valid, trusted
+ and acceptable certificate. After having verified that
+ symlinks have been created, in order to verify if the server
+ certificate is trusted (and this is the operation each
+ <acronym>LDAP</acronym> client does before accessing the
+ server), run (from the <filename>server.crt</filename>
+ directory):</para>
+
+ <screen>&prompt.root; <userinput>openssl verify -verbose -CApath . server.crt</userinput></screen>
+
+ <para>If <filename>slapd</filename> was running, it must now
+ be restarted before using the server. Please, carefully read
+ the comments included in
+ <filename>/usr/local/etc/rc.d/slapd</filename>, to make a
+ correct configuration to run <filename>slapd</filename> at
+ boot. An additional option is needed if the
+ <literal>cn=config</literal> style (that is: the file
+ <filename>slapd.ldif</filename>) is used for configuration.
+ You could put in <filename>/etc/rc.conf</filename> the
+ following lines:</para>
+
+ <programlisting>lapd_enable="YES"
+slapd_flags='-h "ldapi://%2fvar%2frun%2fopenldap%2fldapi/
+ldap://0.0.0.0/"'
+slapd_sockets="/var/run/openldap/ldapi"
+slapd_cn_config="YES"</programlisting>
+
+ <para><filename>slapd</filename> does not provide debugging at
+ boot, but <filename>dmesg -a</filename>,
+ <filename>/var/log/messages</filename> and (in particular)
+ <filename>/var/log/debug.log</filename> can be checked.</para>
+
+ <para>The <acronym>LDAP</acronym> users database is still
+ empty. An example, which adds a group called
+ <literal>team</literal> and a user called
+ <literal>john</literal> to the
+ <systemitem class="systemname">domain.example</systemitem>
+ database is provided here. Create a file
+ <filename>domain.ldif</filename> with the following
+ contents:</para>
+
+ <screen>&prompt.root; <userinput>cat domain.ldif</userinput>
+dn: dc=domain,dc=example
+objectClass: dcObject
+objectClass: organization
+o: domain.example
+dc: domain
+
+dn: ou=groups,dc=domain,dc=example
+objectClass: top
+objectClass: organizationalunit
+ou: groups
+
+dn: ou=users,dc=domain,dc=example
+objectClass: top
+objectClass: organizationalunit
+ou: users
+
+dn: cn=team,ou=groups,dc=domain,dc=example
+objectClass: top
+objectClass: posixGroup
+cn: team
+gidNumber: 10001
+
+dn: uid=john,ou=users,dc=domain,dc=example
+objectClass: top
+objectClass: account
+objectClass: posixAccount
+objectClass: shadowAccount
+cn: John McUser
+uid: john
+uidNumber: 10001
+gidNumber: 10001
+homeDirectory: /home/john/
+loginShell: /usr/bin/bash
+userPassword: secret</screen>
+
+ <para>Instead of being <literal>secret</literal>, the password
+ in the last line of <filename>domain.ldif</filename> for
+ <literal>john</literal> can be generated with
+ <filename>slappasswd</filename>. Be careful about the
+ default shell path: if it does not exist in the system where
+ the user tries to log in, an error can be generated and the
+ user could not be able to actually log in. A symlink can be
+ created, or a different shell can be used to avoid this. For
+ the structure of the <literal>ldif</literal> files and the
+ <acronym>LDAP</acronym> directory, see the OpenLDAP
+ documentation. Such data can be added to the database using
+ the <literal>mdb</literal> administrator:</para>
+
+ <screen>&prompt.root; <userinput>ldapadd -W -D "cn=mdbadmin,dc=domain,dc=example" -f domain.ldif</userinput></screen>
+
+ <para>If instead a global option is to be modified, a
+ <emphasis>different user</emphasis> must be considered: as
+ anticipated, it is the <emphasis>global</emphasis>
+ super-user. Let us assume that the option
+ <literal>olcTLSCipherSuite: HIGH:MEDIUM:SSLv3</literal> was
+ specified before and now it must be deleted. The
+ instructions for the modification can be stored in the file
+ <filename>global_mod</filename>. It must not contain the
+ previous value of the option to be deleted in the last line:
+ this means that
+ <literal>olcTLSCipherSuite: HIGH:MEDIUM:SSLv3</literal> must
+ not be included as last line.</para>
+
+ <screen>&prompt.root; <userinput>cat global_mod</userinput>
+dn: cn=config
+changetype: modify
+delete: olcTLSCipherSuite</screen>
+
+ <para>The modifications can be applied with</para>
+
+ <screen>&prompt.root; <userinput>ldapmodify -f global_mod -x -D "cn=config" -W</userinput></screen>
+
+ <para><literal>cn=config</literal> is the
+ <literal>dn</literal> (Distinguished Name) of the entry
+ (section) of the database to be modified. Use
+ <literal>ldapmodify</literal> to delete a single line of the
+ database; <literal>ldapdelete</literal> is used to delete an
+ entire entry (section) instead. Each database section has its
+ own administrator and it must be specified while applying a
+ modification. The global super-user, whose name is by default
+ <literal>cn=config</literal>, should have a password set by
+ <literal>olcRootPW</literal> in the
+ <literal>dn: olcDatabase={0}config,cn=config</literal>
+ section. It is the one who must used here. If something
+ goes wrong, or if this root administrator cannot access the
+ configuration backend, it is possible to completeley delete
+ the current configuration. It can be done by removing the
+ directory that was previously created:</para>
+
+ <screen>&prompt.root; <userinput>rm -rf /usr/local/etc/openldap/slapd.d/</userinput></screen>
+
+ <para><filename>slapd.ldif</filename> can then be edited and
+ imported again. Please note that this procedure
+ is not to be considered as ordinary, nor normal: it will not
+ have side effects, but it should be followed
+ <emphasis>only</emphasis> when no other solution is
+ suitable.</para>
+
+ <para>This is the configuration of the server only. The
+ client, which can be the server itself, and/or another
+ machine, relies upon other configuration files: a dedicated
+ guide must be followed for them.</para>
- <para>At this point, the server should be configured and
- functioning properly.</para>
</sect2>
</sect1>

File Metadata

Mime Type
text/plain
Expires
Fri, Feb 13, 12:10 PM (20 h, 32 m)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
28676857
Default Alt Text
D10600.id44148.diff (26 KB)

Event Timeline