Page MenuHomeFreeBSD
Files F144784028

D10600.id28032.diff
No OneTemporary
Actions

D10600.id28032.diff
View Options

Index: chapter.xml
===================================================================
--- chapter.xml
+++ chapter.xml
@@ -2249,6 +2249,11 @@
<surname>Rhodes</surname>
</personname>
<contrib>Written by </contrib>
+ <personname>
+ <firstname>Rocky</firstname>
+ <surname>Hotas</surname>
+ </personname>
+ <contrib>Updated by </contrib>
</author>
</authorgroup>
</info>
@@ -2341,7 +2346,13 @@
<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.
+ role="port">net/openldap24-server</package> package or port:
+ the default package can be simply installed with
+
+ <screen>&prompt.root; <userinput>pkg install openldap24-server</userinput></screen>
+
+ Note that the root shell is being used here and it will always
+ be used from now on: so, be sure to run all these commands as root.
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
@@ -2350,220 +2361,494 @@
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>
+ <para>Next, create (if not already existent) 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>
- <para>Copy over the database configuration file:</para>
+ <para>The database configuration file should be</para>
- <screen>&prompt.root; <userinput>cp /usr/local/etc/openldap/DB_CONFIG.example /var/db/openldap-data/DB_CONFIG</userinput></screen>
+ <screen><userinput>/usr/local/etc/openldap/DB_CONFIG.example</userinput></screen>
- <para>The next phase is to configure the certificate authority.
+ Anyway, it may not be in the system even after a successful
+ installation of openldap24-server. Thus, it could be necessary to
+ download it from an external source like <link
+ xlink:href="http://wpollock.com/AUnixNet/LDAP/lister.php?file=DB_CONFIG.example&linenums&dl">this one</link>.
+ Further information about this file and its parameters can be found in
+ the <link
+ xlink:href="http://www.openldap.org/faq/data/cache/1072.html">OpenLDAP FAQs</link>.
+
+ Once downloaded, the database configuration file should be copied in
+ an appropriate directory:
+
+ <screen>&prompt.root; <userinput>cp DB_CONFIG.example /var/db/openldap-data/DB_CONFIG</userinput></screen>
+
+ <para>If you are dealing with a brand new configuration and you are not in a big
+ company or infrastructure who already has its own Certificate Authority,
+ the cheapest and easiest thing you could do it to create it by
+ yourself. All you need is to create a self-signed certificate, which
+ will be the root, invisibile certificate that you will use to sign all the
+ other ones.
+ Further information can be found in &man.openssl.1;, &man.req.1; and in the <link
+ xlink:href="http://www.openldap.org/doc/admin24/tls.html">OpenLDAP 2.4 Administrator's Guide</link>.
The following commands must be executed from
- <filename>/usr/local/etc/openldap/private</filename>. This is
+ <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
- certificate authority, start with this command and follow the
- prompts:</para>
+ users should not have access to these files. To create the certificate authority,
+ you can use &man.openssl.1; with the syntax shown below.
+ You must answer to several questions, in order to
+ include specific information inside your certificate: your answers are
+ not important as regards this procedure (so you may choose them
+ arbitrarily or leave them empty), <emphasis>all but one</emphasis>, the
+ <literal>Common Name</literal>. This
+ is the only parameter you should <emphasis>carefully</emphasis> choose: for the Certificate
+ Authority that you are creating, it should be a name you will never
+ use again. It can be <filename>CAdomain.example</filename> or whatever you want, but
+ all the next certificates you will create later and that will be
+ signed with this one, must have a different <literal>Common Name</literal>.</para>
<screen>&prompt.root; <userinput>openssl req -days <replaceable>365</replaceable> -nodes -new -x509 -keyout ca.key -out ../ca.crt</userinput></screen>
- <para>The entries for the prompts may be generic
- <emphasis>except</emphasis> for the
- <literal>Common Name</literal>. This entry must be
- <emphasis>different</emphasis> than the system hostname. If
- this will be a self signed certificate, prefix the hostname
- with <literal>CA</literal> for certificate authority.</para>
-
- <para>The next task is to create a certificate signing request
- and a private key. Input this command and follow the
- prompts:</para>
+ <para>Now you just created a Certificate Authority called <filename>ca.crt</filename> in
+ <filename>/usr/local/etc/openldap</filename> and its private key <filename>ca.key</filename> in
+ <filename>/usr/local/etc/openldap/private</filename>.</para>
+
+ <para>You can now create a certificate (and a private key) for the LDAP server:
+ anyway, it will be called a "Certificate Signing Request" until it is
+ signed with the Certificate Authority. Again, only the <literal>Common Name</literal>
+ attribute is important here: if for the Certificate Authority you
+ chose <filename>CAdomain.example</filename>, now you can simply use
+ <filename>domain.example</filename>,
+ that is the hostname of your server (this is in fact the certificate
+ that will be used by your server during LDAP operation). This is a trivial way to choose
+ two different <literal>Common Name</literal>s without effort.</para>
<screen>&prompt.root; <userinput>openssl req -days <replaceable>365</replaceable> -nodes -new -keyout server.key -out server.csr</userinput></screen>
- <para>During the certificate generation process, be sure to
- correctly set the <literal>Common Name</literal> attribute.
- Once complete, sign the key:</para>
+ <para>Now, this 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>
- <para>The final part of the certificate generation process is to
- generate and sign the client certificates:</para>
+ <para>In <filename>/usr/local/etc/openldap</filename> a file called
+ <filename>server.crt</filename> has been created
+ and it will be the server certificate to be used: it is trusted
+ because it is signed with the Certificate Authority.
+ It is now possible to create even the <emphasis>client</emphasis>
+ Certificate Signing Request and to sign it with the same Certificate Authority as before
+ (only this way also the client certificate will be trusted).
+ If the client and the server are the same machine, the same Common
+ Name as for <filename>server.csr</filename> must be used. Otherwise, whatever name can be
+ choosen, as far as it is different from the Certificate Authority
+ <literal>Common Name</literal> <filename>CAdomain.example</filename>.</para>
<screen>&prompt.root; <userinput>openssl req -days <replaceable>365</replaceable> -nodes -new -keyout client.key -out client.csr</userinput>
&prompt.root; <userinput>openssl x509 -req -days 3650 -in client.csr -out ../client.crt -CA ../ca.crt -CAkey ca.key</userinput></screen>
- <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>
-
- <screen>&prompt.root; <userinput>ldapsearch -Z</userinput>
-# extended LDIF
-#
-# LDAPv3
-# base &lt;dc=example,dc=com&gt; (default) with scope subtree
-# filter: (objectclass=*)
-# requesting: ALL
-#
-
-# search result
-search: 3
-result: 32 No such object
-
-# numResponses: 1</screen>
-
- <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>
-
- <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>
+ <para>When finished, be sure that eight new files have been created: the
+ certificates <filename>ca.crt</filename>, <filename>server.crt</filename>
+ and <filename>client.crt</filename> in
+ <filename>/usr/local/etc/openldap</filename> and <filename>ca.key</filename>,
+ <filename>client.csr</filename>, <filename>client.key</filename>,
+ <filename>server.csr</filename>, <filename>server.key</filename> in
+ <filename>/usr/local/etc/openldap/private</filename>.</para>
+
+ <para>The daemon running the OpenLDAP server is called <filename>slapd</filename>
+ and it must be configured.
+ Such a configuration can be performed in two ways: through a
+ <filename>slapd.conf</filename> configuration file, or through a database file
+ <filename>slapd.ldif</filename>. The former way is deprecated by OpenLDAP and the
+ use of a ldif file is strongly recommended. The structure of this file is not trivial. A
+ configuration example can be found <link
+ xlink:href="http://www.openldap.org/doc/admin24/slapdconf2.html">here</link>, in
+ paragraph 5.3. The directory <filename>/usr/local/etc/openldap</filename> contains
+ a <filename>slapd.ldif.sample</filename> file in order to ease the configuration.
+ The file is divided into several parts: each of them is uniquely identified through
+ a <literal>dn:</literal> (Distinguished Name). The first one is 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, otherwise an
+ error will be generated.
+ In the global section, options regarding the execution of <filename>slapd</filename> and
+ security can be specified.
+ The statements are generally the same as in <filename>slapd.conf</filename>, but preceeded
+ by "<literal>olc</literal>". The beginning of the <filename>slapd.ldif</filename> file
+ is reported here: in this section, the certificate file, its key, and the
+ Certificate Authority file should be specified, if a secure connection
+ for communications is required. In this example, TLS will be used to
+ implement a secure channel. All the following options (and more) are
+ documented in &man.slapd-config.5;, which is recommended to be consulted
+ during configuration.</para>
+
+ <screen>
+ #
+ # See slapd-config(5) for details on configuration options.
+ # This file should NOT be world readable.
+ #
+ 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
+ olcTLSProtocolMin: 3.1
+ #olcTLSCipherSuite: HIGH:MEDIUM:+SSLv3
+ olcTLSVerifyClient: never
+ </screen>
+
+ <para>An option <literal>olcTLSCipherSuite</literal> can specified;
+ previously, it
+ was suggested to have the value <literal>HIGH:MEDIUM:+SSLv3</literal>. It should be
+ noted however that <literal>SSLv3</literal> has been deprecated by IETF and that the
+ syntax <literal>HIGH:MEDIUM</literal> is related to <filename>openssl</filename>; when clients with
+ different Operating Systems try to connect to this server, they may
+ not be able to parse this value. Linux clients, for example,
+ use <filename>gnutls</filename> as TLS client instead of <filename>openssl</filename>
+ and an error is generated
+ if this option is used with the shown syntax. Thus, otherwise you
+ won't have all FreeBSD clients, it is recommended to omit such a line, and
+ let the client choose the security cipher, regardless of the TLS
+ client used by its OS. The security cipher will be choosen according to
+ the available ciphers in the client machine, hopefully being the most
+ secure at the present time: it is not advisable that the server force it
+ and this is another benefit when omitting the <literal>olcTLSCipherSuite</literal>.
+ The security of the client ciphers is demanded to the package
+ maintainers of the TLS clients.
+ Nonetheless, the LDAP server Administrator can specify a minimum security
+ level required by the server, and this is done with the recommended option
+ <literal>olcTLSProtocolMin</literal>.
+ Server must always be verified, while clients can or can not be
+ verified: here it has been choosen to not verify them with
+ <literal>olcTLSVerifyClient</literal>.
+
+ The second part is about the backend modules and can be configured as
+ follows:</para>
+
+ <screen>
+ #
+ # 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
+ </screen>
+
+ <para>The third part is devoted to load the needed ldif schemas to be used
+ by the databases: they are essential.</para>
+
+ <screen>
+ 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
+ </screen>
+
+ <para>Then, the frontend configuration follows:</para>
+
+ <screen>
+ # 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
+ </screen>
+
+ <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 here specified. In particular,
+ a root password must be choosen: 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, later will be shown a way
+ to delete (and hopefully replace) it.
+ A password can be generated using &man.slappasswd.8C; in a shell and its
+ entire output must be used as a value for <literal>olcRootPW</literal>.</para>
+
+ <screen>
+ dn: olcDatabase={0}config,cn=config
+ objectClass: olcDatabaseConfig
+ olcDatabase: {0}config
+ olcAccess: to * by * none
+ olcRootPW: {SSHA}iae+lrQZILpiUdf16Z9KmDmSwT77Dj4U
+ </screen>
+
+ <para>The last section showed here is about the database backend, used for
+ the <emphasis>actual contents</emphasis> of the LDAP 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>
+
+ <screen>
+ #######################################################################
+ # 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
+ </screen>
+
+ <para>In<uri
+ 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</uri>, four examples of <filename>slapd.ldif<filename> files are available (they are used as a 4-way multi master
+ LDAP server). At the bottom of <uri
+ xlink:href="http://www.openldap.org/doc/admin24/slapdconf2.html">this page</uri>,
+ section 5.4, also a way to convert an existing <filename>slapd.conf<filename> into a valid
+ <filename>slapd.ldif<filename> is presented. 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 <uri
+ xlink:href="http://www.openldap.org/doc/admin24/quickstart.html">OpenLDAP Quick Start guide</uri>
+ (which can anyway 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>
- <programlisting>dn: dc=<replaceable>example</replaceable>,dc=<replaceable>com</replaceable>
-objectclass: dcObject
-objectclass: organization
-o: <replaceable>Example</replaceable>
-dc: <replaceable>Example</replaceable>
+ <screen>&prompt.root; <userinput>/usr/local/libexec/slapd -F /usr/local/etc/openldap/slapd.d/</userinput></screen>
-dn: cn=<replaceable>Manager</replaceable>,dc=<replaceable>example</replaceable>,dc=<replaceable>com</replaceable>
-objectclass: organizationalRole
-cn: <replaceable>Manager</replaceable></programlisting>
+ <para>Option <literal>-d</literal> can be used for debugging, as specified in &man.slapd.8;.
- <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>
+To verify that the server is running and working,</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"
-
-adding new entry "cn=Manager,dc=example,dc=com"</screen>
-
- <para>Verify the data was added by issuing a search on the
- server using <command>ldapsearch</command>:</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 <> 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 won't still 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 a FreeBSD 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 &man.c_rehash.1; tool. Now run</para>
+
+ <screen>&prompt.root; <userinput>c_rehash .</userinput></screen>
+
+ 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
+ should 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 LDAP 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 <filename>/usr/local/etc/rc.d/slapd<filename> file in order 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>
+
+ <screen>
+ 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"
+ </screen>
+
+ <para><filename>slapd</filename>doesn't 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 LDAP users database is still empty. An example, which adds a group
+ called <literal>team</literal> and a user called <literal>john</literal> to
+ the <literal>domain.example</literal> database
+ is here provided.</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
+ <filename>domain.ldif</filename> file for
+ <literal>john</literal> can be generated with
+ &man.slappasswd.8C;. Be careful about the default shell path: if it doesn't
+ 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 LDAP 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 different user must be
+ considered: as anticipated, it is the global super-user. Let's 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 store in the file <filename>global_mod</filename>.
+ It must not contain the previous value of the option to be deleted in
+ the last line, that is <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>The <filename>slapd.ldif</filename> file can then be edited and imported again.
+ Please note that this procedure is not to be considered as ordinary, nor normal:
+ it won't have side effects, but it should be followed only when no other solution is feasible.</para>
+
+ <para>This is the configuration of the server only. The client, which can be
+ the server itself, 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, 1:01 PM (21 h, 30 m)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
28677195
Default Alt Text
D10600.id28032.diff (31 KB)

Event Timeline