Changeset View
Standalone View
chapter.xml
Show First 20 Lines • Show All 2,239 Lines • ▼ Show 20 Lines | # [...more groups to follow]</programlisting> | ||||
<sect1 xml:id="network-ldap"> | <sect1 xml:id="network-ldap"> | ||||
<info> | <info> | ||||
<title>Lightweight Directory Access Protocol | <title>Lightweight Directory Access Protocol | ||||
(<acronym>LDAP</acronym>)</title> | (<acronym>LDAP</acronym>)</title> | ||||
<authorgroup> | <authorgroup> | ||||
<author> | <author> | ||||
<personname> | <personname> | ||||
<firstname>Rocky</firstname> | |||||
<surname>Hotas</surname> | |||||
</personname> | |||||
<contrib>Updated by </contrib> | |||||
</author> | |||||
</authorgroup> | |||||
<authorgroup> | |||||
<author> | |||||
<personname> | |||||
<firstname>Tom</firstname> | <firstname>Tom</firstname> | ||||
<surname>Rhodes</surname> | <surname>Rhodes</surname> | ||||
</personname> | </personname> | ||||
<contrib>Written by </contrib> | <contrib>Originally contributed by </contrib> | ||||
</author> | </author> | ||||
</authorgroup> | </authorgroup> | ||||
</info> | </info> | ||||
<indexterm><primary>LDAP</primary></indexterm> | <indexterm><primary>LDAP</primary></indexterm> | ||||
<para>The Lightweight Directory Access Protocol | <para>The Lightweight Directory Access Protocol | ||||
(<acronym>LDAP</acronym>) is an application layer protocol used | (<acronym>LDAP</acronym>) is an application layer protocol used | ||||
to access, modify, and authenticate objects using a distributed | to access, modify, and authenticate objects using a distributed | ||||
directory information service. Think of it as a phone or record | directory information service. Think of it as a phone or record | ||||
▲ Show 20 Lines • Show All 64 Lines • ▼ Show 20 Lines | # numEntries: 1</screen> | ||||
<literal>dn</literal>, <literal>mail</literal>, | <literal>dn</literal>, <literal>mail</literal>, | ||||
<literal>cn</literal>, <literal>uid</literal>, and | <literal>cn</literal>, <literal>uid</literal>, and | ||||
<literal>telephoneNumber</literal> attributes. The | <literal>telephoneNumber</literal> attributes. The | ||||
<acronym>cn</acronym> attribute is the | <acronym>cn</acronym> attribute is the | ||||
<acronym>RDN</acronym>.</para> | <acronym>RDN</acronym>.</para> | ||||
<para>More information about <acronym>LDAP</acronym> and its | <para>More information about <acronym>LDAP</acronym> and its | ||||
terminology can be found at <uri | terminology can be found at <uri | ||||
xlink:href="http://www.openldap.org/doc/admin24/intro.html">http://www.openldap.org/doc/admin24/intro.html</uri>.</para> | xlink:href="http://www.openldap.org/doc/admin24/intro.html" | ||||
>http://www.openldap.org/doc/admin24/intro.html</uri> | |||||
.</para> | |||||
</sect2> | </sect2> | ||||
wblock: This colon just splices two sentences together. Please just use short, separate sentences. | |||||
<sect2 xml:id="ldap-config"> | <sect2 xml:id="ldap-config"> | ||||
Done Inline ActionsWhat does "default package" mean? "can be" is passive. Please do not say "simply", it can be seen as patronizing by someone who does not find the process simple. "with" is a little odd. wblock: What does "default package" mean?
"can be" is passive.
Please do not say "simply", it can be… | |||||
<title>Configuring an <acronym>LDAP</acronym> Server</title> | <title>Configuring an <acronym>LDAP</acronym> Server</title> | ||||
<indexterm><primary>LDAP Server</primary></indexterm> | <indexterm><primary>LDAP Server</primary></indexterm> | ||||
Done Inline ActionsIf we need to tell the user that they must be root, it should be done before they are told to run the command. But I doubt that it is necessary in... well, whatever chapter this is. Advanced Networking, I think, but there is no context. Please see https://wiki.freebsd.org/action/show/Phabricator?action=show&redirect=CodeReview about including context with diffs. It is also useful to generate the diff from the top-level doc directory so the path to the file includes the parent directory with the chapter name. PS: "root shell" is a vague term. Elsewhere, we just tell people to run commands as root. wblock: If we need to tell the user that they must be root, it should be done before they are told to… | |||||
Done Inline ActionsI still have problems running from the top of the source tree, but anyway I increased the context in the diff. rockyhotas_post.com: I still have problems running from the top of the source tree, but anyway I increased the… | |||||
Done Inline ActionsAs specified in the summary, it is "28.5. Lightweight Directory Access Protocol (LDAP)" chapter of the Handbook. This is the source file: https://svnweb.freebsd.org/doc/head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml?view=log rockyhotas_post.com: As specified in the summary, it is "28.5. Lightweight Directory Access Protocol (LDAP)" chapter… | |||||
<para>&os; does not provide a built-in <acronym>LDAP</acronym> | <para>&os; does not provide a built-in <acronym>LDAP</acronym> | ||||
Done Inline ActionsAs above, probably not necessary. wblock: As above, probably not necessary. | |||||
server. Begin the configuration by installing the <package | 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 | ||||
Since the port has many configurable options, it is | port. Be sure to run all the commands listed from now on | ||||
recommended that the default options are reviewed to see if | being <systemitem class="username">root</systemitem>. This | ||||
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 | <screen>&prompt.root; <userinput>pkg install openldap24-server</userinput></screen> | ||||
the certificates:</para> | |||||
installs the needed <emphasis>package</emphasis>, which is a | |||||
particular kind of <emphasis>port</emphasis>: | |||||
Done Inline ActionsPlease avoid asides (interruptions in parentheses, like this one) as they interrupt the flow of sentences and the train of thought. Try to avoid listing or labeling steps with "first" and "next" and "then", these usually add no value and make for a halting sentence. <para>Create directories to hold the data and certificates:</para> wblock: Please avoid asides (interruptions in parentheses, like this one) as they interrupt the flow of… | |||||
the one with all options set to default. | |||||
Done Inline Actions"If the directories to store the data and certificates do not exist already, create them with:" sevan: "If the directories to store the data and certificates do not exist already, create them with:" | |||||
In most cases, the defaults are fine and so the package is | |||||
too. But if for example SQL support is needed, | |||||
the relative option must be enabled and the port compiled | |||||
using the instructions in <xref linkend="ports-using"/>. | |||||
There are many other configurable options, so it is | |||||
Done Inline ActionsAvoid "should" unless making a recommendation. I can't tell what it is recommending here, a name or location or something else. wblock: Avoid "should" unless making a recommendation. I can't tell what it is recommending here, a… | |||||
recommended that the defaults are reviewed to see if | |||||
the <emphasis>package</emphasis> is sufficient, and to | |||||
instead compile the <emphasis>port</emphasis> if | |||||
any options should be changed.</para> | |||||
Done Inline Actions"Anyway"? "may" is usually used for permission, "might" means the possibility of something happening. I don't understand what this sentence is trying to say. wblock: "Anyway"?
"may" is usually used for permission, "might" means the possibility of something… | |||||
Done Inline ActionsThe old guide expects that a DB_CONFIG.example file is saved in the mentioned directory. But the package doesn't carry such a file, so there is a mismatch between the guide and the package. The sentence is saying: "if you installed openldap24-server but the file doesn't exists, try to download it". rockyhotas_post.com: The old guide expects that a DB_CONFIG.example file is saved in the mentioned directory. But… | |||||
<para>If the directories to store the data and certificates do | |||||
not exist already, create them:</para> | |||||
Done Inline ActionsIndentation problems, and the caption of the link hides the URL instead of naming it. wblock: Indentation problems, and the caption of the link hides the URL instead of naming it. | |||||
<screen>&prompt.root; <userinput>mkdir /var/db/openldap-data</userinput> | <screen>&prompt.root; <userinput>mkdir /var/db/openldap-data</userinput> | ||||
&prompt.root; <userinput>mkdir /usr/local/etc/openldap/private</userinput></screen> | &prompt.root; <userinput>mkdir /usr/local/etc/openldap/private</userinput></screen> | ||||
<para>Copy over the database configuration file:</para> | <para>The database configuration file is</para> | ||||
<screen>/usr/local/etc/openldap/DB_CONFIG.example</screen> | |||||
<para>If this file is not present after the installation of | |||||
<package role="port">net/openldap24-server</package>, it is | |||||
Done Inline ActionsPlease avoid the informal "you": https://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/writing-style.html wblock: Please avoid the informal "you": https://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp… | |||||
available for download <link | |||||
xlink:href="http://wpollock.com/AUnixNet/LDAP/lister.php?file=DB_CONFIG.example&linenums&dl"> | |||||
here</link> (this is not the only suitable copy of this | |||||
file on the internet: other identical ones can be found | |||||
through a search engine, if this link is not available). | |||||
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>.</para> | |||||
Done Inline ActionsThere is a strange space between the and OpenLDAP... remko: There is a strange space between the and OpenLDAP... | |||||
<para>Once downloaded, use the database configuration file in | |||||
an appropriate directory:</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>cp /usr/local/etc/openldap/DB_CONFIG.example /var/db/openldap-data/DB_CONFIG</userinput></screen> | ||||
<para>The next phase is to configure the certificate authority. | <para>When dealing with a brand new configuration, being not | ||||
The following commands must be executed from | in a big company or infrastructure who can buy or own | ||||
<filename>/usr/local/etc/openldap/private</filename>. This is | several Certificate Authorities, the cheapest and easiest | ||||
important as the file permissions need to be restrictive and | thing to do is to create a free, brand new Certificate | ||||
users should not have access to these files. To create the | Authority. It is a self-signed certificate, which will be | ||||
certificate authority, start with this command and follow the | the root, invisibile certificate that will be use to sign | ||||
prompts:</para> | all the other ones. Further information about this | ||||
procedure can be found in &man.openssl.1;, <link xlink:href= | |||||
"https://www.freebsd.org/cgi/man.cgi?query=req&manpath=FreeBSD+11.0-RELEASE+and+Ports"> | |||||
req(1)</link> 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 important as the file permissions need to be restrictive | |||||
and users should not have access to these files. Here, | |||||
&man.openssl.1; will be used to create the Certificate | |||||
Authority, with the syntax shown below.</para> | |||||
<para>Several questions must be answered to and | |||||
&man.openssl.1; will gather specific information to embed in | |||||
the certificate. As regards the OpenLDAP server | |||||
installation, <emphasis>all but one</emphasis> of these | |||||
questions are irrelevant. The only important question is | |||||
the one about the <literal>Common Name</literal>. All the | |||||
other answers may even be arbitrarily chosen or left empty. | |||||
Instead,</para> | |||||
<important> | |||||
<para>The <literal>Common Name</literal> should be | |||||
Done Inline Actionsto create even the -> to create the remko: to create even the -> to create the | |||||
<emphasis>carefully</emphasis> chosen: for the Certificate | |||||
Authority, it should be a name that will be never used | |||||
again.</para> | |||||
</important> | |||||
<para>In this example, <literal>CAdomain.example</literal> | |||||
will be used. Another <literal>Common Name</literal> can be | |||||
freely, arbitrarily chosen: the only important issue is that | |||||
all the next certificates, that will be created and | |||||
<emphasis>signed</emphasis> 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> | <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 | <para>With this command, a Certificate Authority called | ||||
<emphasis>except</emphasis> for the | <filename>ca.crt</filename> is created in <filename> | ||||
<literal>Common Name</literal>. This entry must be | /usr/local/etc/openldap</filename> and its private key | ||||
<emphasis>different</emphasis> than the system hostname. If | <filename>ca.key</filename> is placed in | ||||
this will be a self signed certificate, prefix the hostname | <filename>/usr/local/etc/openldap/private</filename>.</para> | ||||
with <literal>CA</literal> for certificate authority.</para> | |||||
<para>The next task is to create a certificate signing request | <para>A certificate (and a private key) for the | ||||
and a private key. Input this command and follow the | <acronym>LDAP</acronym> server is now needed: it will be | ||||
prompts:</para> | initially called a "Certificate Signing Request"; then, | ||||
after being signed with the Certificate Authority, it will | |||||
actually be a certificate. Only the <literal>Common | |||||
Name</literal> attribute is important here like before: if | |||||
for the Certificate Authority | |||||
<filename>CAdomain.example</filename> was chosen, now the | |||||
full hostname of the server <systemitem class="systemname"> | |||||
domain.example</systemitem> can be used. 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> | <screen>&prompt.root; <userinput>openssl req -days <replaceable>365</replaceable> -nodes -new -keyout server.key -out server.csr</userinput></screen> | ||||
Done Inline ActionsThese two lines can be wrapped to the previous lines and redone. remko: These two lines can be wrapped to the previous lines and redone. | |||||
<para>During the certificate generation process, be sure to | <para>This Certificate Signing Request must be signed with the | ||||
correctly set the <literal>Common Name</literal> attribute. | Certificate Authority in order to be used as a valid | ||||
Once complete, sign the key:</para> | 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> | <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 | <para>In <filename>/usr/local/etc/openldap</filename> a file | ||||
generate and sign the client certificates:</para> | called <filename>server.crt</filename> has been created | ||||
and it will be the server certificate: it is trusted | |||||
because it is signed with the Certificate Authority. | |||||
It is now possible to create 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 | |||||
<literal>Common Name</literal> as for | |||||
<filename>server.csr</filename> must be used. Otherwise, | |||||
whatever name can be chosen, 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> | <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> | &prompt.root; <userinput>openssl x509 -req -days <replaceable>365</replaceable> -in client.csr -out ../client.crt -CA ../ca.crt -CAkey ca.key</userinput></screen> | ||||
<para>Remember to use the same <literal>Common Name</literal> | <para>When finished, be sure that eight new files have been | ||||
attribute when prompted. When finished, ensure that a total | created: the certificates <filename>ca.crt</filename>, | ||||
of eight (8) new files have been generated through the | <filename>server.crt</filename> and | ||||
proceeding commands. If so, the next step is to edit | <filename>client.crt</filename> in | ||||
<filename>/usr/local/etc/openldap/slapd.conf</filename> and | <filename>/usr/local/etc/openldap</filename> and | ||||
add the following options:</para> | <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> | |||||
Done Inline ActionsPlease wrap the previous line with this one and try to make sure that the line does not exceed the max.. remko: Please wrap the previous line with this one and try to make sure that the line does not exceed… | |||||
<programlisting>TLSCipherSuite HIGH:MEDIUM:+SSLv3 | <para>The daemon running the OpenLDAP server is called | ||||
TLSCertificateFile /usr/local/etc/openldap/server.crt | <filename>slapd</filename> and it must be configured. | ||||
TLSCertificateKeyFile /usr/local/etc/openldap/private/server.key | Such a configuration can be performed in two ways: through a | ||||
TLSCACertificateFile /usr/local/etc/openldap/ca.crt</programlisting> | <filename>slapd.conf</filename> configuration file, or | ||||
through a database file <filename>slapd.ldif</filename>. | |||||
The former way is deprecated by OpenLDAP:</para> | |||||
<para>Then, edit | <tip> | ||||
<filename>/usr/local/etc/openldap/ldap.conf</filename> and add | <para>The use of <filename>slapd.ldif</filename> is | ||||
the following lines:</para> | strongly recommended.</para> | ||||
</tip> | |||||
Done Inline ActionsThere must not be a space between the closing > and slapd-config(5)</link>. Even though the link is long and the page can not be broken earlier, it must be there or there is a visual extra space in the output. bcr: There must not be a space between the closing > and slapd-config(5)</link>. Even though the… | |||||
<programlisting>TLS_CACERT /usr/local/etc/openldap/ca.crt | <para>The structure of this file is not trivial. A | ||||
TLS_CIPHER_SUITE HIGH:MEDIUM:+SSLv3</programlisting> | 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 file | |||||
named <filename>slapd.ldif.sample</filename> in order to | |||||
ease the configuration. | |||||
A full example of the <filename>slapd.ldif</filename> will | |||||
be provided below, with some comments. The file is composed | |||||
by 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 preceded by "<literal> | |||||
olc</literal>". The beginning of the <filename> | |||||
slapd.ldif</filename> configuration file is reported here: | |||||
in this section, the certificate file, its key, and the | |||||
Certificate Authority file should be specificed, if a secure | |||||
connection for communcations is required. In this example, | |||||
TLS will be used to implement a secure channel. All the | |||||
following options (and more) are documented in <link | |||||
xlink:href="https://www.freebsd.org/cgi/man.cgi?query=slapd-config&manpath=FreeBSD+11.0-RELEASE+and+Ports"> | |||||
slapd-config(5)</link>, which is recommended to be consulted | |||||
during configuration. The following file is intended to work | |||||
with the suggested TLS configuration.</para> | |||||
<para>While editing this file, uncomment the following entries | <programlisting># | ||||
and set them to the desired values: <option>BASE</option>, | # See slapd-config(5) for details on configuration options. | ||||
<option>URI</option>, <option>SIZELIMIT</option> and | # This file should NOT be world readable. | ||||
<option>TIMELIMIT</option>. Set the <option>URI</option> to | # | ||||
contain <option>ldap://</option> and | dn: cn=config | ||||
<option>ldaps://</option>. Then, add two entries pointing to | objectClass: olcGlobal | ||||
the certificate authority. When finished, the entries should | cn: config | ||||
look similar to the following:</para> | # | ||||
# | |||||
# 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 <co xml:id="server-certificate"/> | |||||
olcTLSCertificateKeyFile: /usr/local/etc/openldap/private/server.key <co xml:id="server-key"/> | |||||
olcTLSCACertificateFile: /usr/local/etc/openldap/ca.crt <co xml:id="ca"/> | |||||
#olcTLSCipherSuite: HIGH:MEDIUM:+SSLv3 <co xml:id="cipher-suite"/> | |||||
olcTLSProtocolMin: 3.1 <co xml:id="protocol-min"/> | |||||
olcTLSVerifyClient: never <co xml:id="verify-client"/></programlisting> | |||||
<programlisting>BASE dc=example,dc=com | <calloutlist> | ||||
URI ldap:// ldaps:// | <callout arearefs="server-certificate"> | ||||
<para>Specifies the location of the server certificate | |||||
for TLS operations.</para> | |||||
</callout> | |||||
SIZELIMIT 12 | <callout arearefs="server-key"> | ||||
TIMELIMIT 15 | <para>Specifies the location of the server key.</para> | ||||
</callout> | |||||
TLS_CACERT /usr/local/etc/openldap/ca.crt | <callout arearefs="ca"> | ||||
TLS_CIPHER_SUITE HIGH:MEDIUM:+SSLv3</programlisting> | <para>Specifies the location of the Certificate | ||||
Authority.</para> | |||||
</callout> | |||||
<para>The default password for the server should then be | <callout arearefs="cipher-suite"> | ||||
changed:</para> | <para>An option <literal>olcTLSCipherSuite</literal> can | ||||
be specified, but here is commented; it was suggested | |||||
to have the value <literal>HIGH:MEDIUM:+SSLv3</literal>. | |||||
It should be noted in fact 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. In order to | |||||
connect to an <acronym>LDAP</acronym> server using TLS, | |||||
each client machine must run a <literal>TLS | |||||
client</literal>. Linux machines, for example, use | |||||
<filename>gnutls</filename> as <literal>TLS | |||||
client</literal> instead of <filename> | |||||
openssl</filename>. An error is generated if the | |||||
option | |||||
<literal>olcTLSCipherSuite: HIGH:MEDIUM:+SSLv3</literal> | |||||
Done Inline Actionsare here specified -> are specified here. remko: are here specified -> are specified here. | |||||
is used with the shown syntax. | |||||
Otherwise <emphasis>all the clients</emphasis> will not | |||||
Done Inline ActionsGrammar is a bit fractured here. I don't understand what this is saying. (But as a general rule, ciphers that aren't in the "HIGH" set should *never* be used unless absolutely required for compatibility with ancient clients, and even that contains a bunch of ciphers that should not be enabled.) wollman: Grammar is a bit fractured here. I don't understand what this is saying. (But as a general… | |||||
Not Done Inline ActionsYes, I understand. This part needed a complete rephrasing. As you can see in the new diff, it has been shrunk.
Please, refer now to the new version of this text. If you think that your suggestion about ciphers and "HIGH" must still be specified, I can add it. rockyhotas_post.com: Yes, I understand. This part needed a complete rephrasing. As you can see in the new diff, it… | |||||
Not Done Inline ActionsNew version looks OK to me. While I'd still prefer to see policy enforced on the server side, but if there is a significant population of clients that still can't do modern TLS, then I suppose that suggestion would be counterproductive. wollman: New version looks OK to me. While I'd still prefer to see policy enforced on the server side… | |||||
run FreeBSD, it is recommended to omit such a line, and | |||||
let the client OS choose the security cipher: this way, | |||||
the server configuration can be done and acceptable, | |||||
regardless of the <literal>TLS client</literal>s that | |||||
will connect. | |||||
The security cipher will be chosen according to the | |||||
available ciphers in the client machine, hopefully being | |||||
Done Inline Actions&man.slappaswd.8C; does not exist. &man.slappasswd.8; should be the right one.. remko: &man.slappaswd.8C; does not exist. &man.slappasswd.8; should be the right one.. | |||||
Not Done Inline Actionsif we need &man.something then we should add it to the entity's for that. There is $base/share/xml/man-refs.ent which has a lot of those entries, also some for external ones like samba-tool. The build system obviously complaints because the reference is missing :) remko: if we need &man.something then we should add it to the entity's for that. There is… | |||||
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.</para> | |||||
</callout> | |||||
<screen>&prompt.root; <userinput>slappasswd -h "{SHA}" >> /usr/local/etc/openldap/slapd.conf</userinput></screen> | <callout arearefs="protocol-min"> | ||||
<para>The <acronym>LDAP</acronym> server Administrator can | |||||
anyway specify a minimum security level required by the | |||||
server. Unlike for the previous one, the use of this | |||||
option is recommended: | |||||
<literal>olcTLSProtocolMin</literal>.</para> | |||||
</callout> | |||||
<para>This command will prompt for the password and, if the | <callout arearefs="verify-client"> | ||||
process does not fail, a password hash will be added to the | <para>Server must always be verified, while clients can be | ||||
end of <filename>slapd.conf</filename>. Several hashing | verified or not: with <literal> | ||||
formats are supported. Refer to the manual page for | olcTLSVerifyClient</literal>, in this example the | ||||
<command>slappasswd</command> for more information.</para> | clients are not verified.</para> | ||||
</callout> | |||||
<para>Next, edit | </calloutlist> | ||||
<filename>/usr/local/etc/openldap/slapd.conf</filename> and | |||||
add the following lines:</para> | |||||
<programlisting>password-hash {sha} | <para>The second part is about the backend modules and can be | ||||
allow bind_v2</programlisting> | configured as follows:</para> | ||||
<para>The <option>suffix</option> in this file must be updated | <programlisting># | ||||
to match the <option>BASE</option> used in | # Load dynamic backend modules: | ||||
<filename>/usr/local/etc/openldap/ldap.conf</filename> and | # | ||||
<option>rootdn</option> should also be set. A recommended | dn: cn=module,cn=config | ||||
value for <option>rootdn</option> is something like | objectClass: olcModuleList | ||||
<option>cn=Manager</option>. Before saving this file, place | cn: module | ||||
the <option>rootpw</option> in front of the password output | olcModulepath: /usr/local/libexec/openldap | ||||
from <command>slappasswd</command> and delete the old | olcModuleload: back_mdb.la | ||||
<option>rootpw</option>. The end result should | #olcModuleload: back_bdb.la | ||||
look similar to this:</para> | #olcModuleload: back_hdb.la | ||||
#olcModuleload: back_ldap.la | |||||
#olcModuleload: back_passwd.la | |||||
#olcModuleload: back_shell.la</programlisting> | |||||
<programlisting>TLSCipherSuite HIGH:MEDIUM:+SSLv3 | <para>The third part is devoted to load the needed <literal> | ||||
TLSCertificateFile /usr/local/etc/openldap/server.crt | ldif</literal> schemas to be used by the databases: they | ||||
TLSCertificateKeyFile /usr/local/etc/openldap/private/server.key | are essential.</para> | ||||
TLSCACertificateFile /usr/local/etc/openldap/ca.crt | |||||
rootpw {SHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g=</programlisting> | |||||
Done Inline ActionsVery long line, please wrap it. remko: Very long line, please wrap it. | |||||
<para>Finally, enable the <application>OpenLDAP</application> | <programlisting>dn: cn=schema,cn=config | ||||
service in <filename>/etc/rc.conf</filename> and set the | objectClass: olcSchemaConfig | ||||
<acronym>URI</acronym>:</para> | cn: schema | ||||
<programlisting>slapd_enable="YES" | include: file:///usr/local/etc/openldap/schema/core.ldif | ||||
slapd_flags="-4 -h ldaps:///"</programlisting> | 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>At this point the server can be started and tested:</para> | <para>Then, the frontend configuration follows:</para> | ||||
<screen>&prompt.root; <userinput>service slapd start</userinput></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>If everything is configured correctly, a search of the | <para>The following section describes the configuration | ||||
directory should show a successful connection with a single | backend: this will be the <emphasis>only way</emphasis> to | ||||
response as in this example:</para> | 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 | |||||
Done Inline Actionswon' t -> will not remko: won' t -> will not | |||||
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.8; in a | |||||
Done Inline ActionsSame as above: no space between <filename> and slappasswd</filename> bcr: Same as above: no space between <filename> and slappasswd</filename> | |||||
shell and its entire output must be used as a value for | |||||
<literal>olcRootPW</literal>.</para> | |||||
<screen>&prompt.root; <userinput>ldapsearch -Z</userinput> | <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 showed here is about the database | |||||
Done Inline Actionss/showed/shown/ bcr: s/showed/shown/ | |||||
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> | |||||
Done Inline ActionsAnd another superfulous space: <filename>slapd.ldif</filename> bcr: And another superfulous space: <filename>slapd.ldif</filename> | |||||
slapd.ldif</filename>. Here, a username <literal> | |||||
Done Inline ActionsHere as well. bcr: Here as well. | |||||
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 | |||||
Done Inline ActionsI think there is a small mistake here. It should probably be: slapd_enable="YES" joel_lopes-da-silva.com: I think there is a small mistake here. It should probably be: `slapd_enable="YES"` | |||||
Not Done Inline ActionsSure, it is like you wrote: slapd_enable="YES". Thank you rockyhotas_post.com: Sure, it is like you wrote: `slapd_enable="YES"`. Thank you | |||||
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. | |||||
Done Inline Actionsdoesn' t -> does not remko: doesn' t -> does not | |||||
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> | |||||
Done Inline Actionsyou can break this one like the following: bcr: you can break this one like the following:
...longurl>this
repository</link> | |||||
slapd.ldif</filename> files are available (they are used | |||||
Done Inline ActionsLet <filename> and slapd.ldif</filename> come closer together here, too. bcr: Let <filename> and slapd.ldif</filename> come closer together here, too. | |||||
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 | |||||
Done Inline ActionsAnd another space that needs to go. You can break the line between "this" and "page". bcr: And another space that needs to go. You can break the line between "this" and "page". | |||||
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 anyway be | |||||
Done Inline ActionsI think we don't need "anyway" here. bcr: I think we don't need "anyway" here. | |||||
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&sektion=8&manpath=FreeBSD+11.0-RELEASE+and+Ports"> | |||||
slapd(8)</link>. To verify that the server is running and | |||||
Done Inline ActionsAnd one more space to remove. bcr: And one more space to remove. | |||||
working,</para> | |||||
<screen>&prompt.root; <userinput>ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts</userinput> | |||||
# extended LDIF | # extended LDIF | ||||
# | # | ||||
# LDAPv3 | # LDAPv3 | ||||
# base <dc=example,dc=com> (default) with scope subtree | # base <> with scope baseObject | ||||
# filter: (objectclass=*) | # filter: (objectclass=*) | ||||
# requesting: ALL | # requesting: namingContexts | ||||
# | # | ||||
# | |||||
dn: | |||||
namingContexts: dc=domain,dc=example | |||||
# search result | # search result | ||||
search: 3 | search: 2 | ||||
result: 32 No such object | result: 0 Success | ||||
# numResponses: 1</screen> | # numResponses: 2 | ||||
# numEntries: 1</screen> | |||||
<note> | <para>The server will not still be recognized by any client as | ||||
Done Inline Actionss/will not still be/will still not be/ bcr: s/will not still be/will still not be/ | |||||
<para>If the command fails and the configuration looks | trusted, anyway. | ||||
correct, stop the <command>slapd</command> service and | The certificates were created in non-standard directories | ||||
Done Inline ActionsThis line needs to be on the one above. Continuing after the "anyway." bcr: This line needs to be on the one above. Continuing after the "anyway." | |||||
restart it with debugging options:</para> | 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 | |||||
Done Inline Actionss/FreeBSD/&os;/ bcr: s/FreeBSD/&os;/
s/a/the/ | |||||
is necessary now to explicitly install the package:</para> | |||||
<screen>&prompt.root; <userinput>service slapd stop</userinput> | <screen>&prompt.root; <userinput>pkg install openssl</userinput></screen> | ||||
&prompt.root; <userinput>/usr/local/libexec/slapd -d -1</userinput></screen> | |||||
</note> | |||||
<para>Once the service is responding, the directory can be | <para>This will provide the <link xlink:href= | ||||
populated using <command>ldapadd</command>. In this example, | "https://www.freebsd.org/cgi/man.cgi?query=c_rehash&manpath=FreeBSD+11.0-RELEASE+and+Ports">c_rehash(1)</link> | ||||
a file containing this list of users is first created. Each | tool. Now run</para> | ||||
user should use the following format:</para> | |||||
<programlisting>dn: dc=<replaceable>example</replaceable>,dc=<replaceable>com</replaceable> | <screen>&prompt.root; <userinput>c_rehash .</userinput></screen> | ||||
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> | <para>from the directory where the CA is stored (in this | ||||
objectclass: organizationalRole | example, <filename>/usr/local/etc/openldap</filename>, | ||||
cn: <replaceable>Manager</replaceable></programlisting> | 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 | |||||
Done Inline ActionsPlease do not use contractions. "It will not have side effects". remko: Please do not use contractions. "It will not have side effects". | |||||
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> | |||||
<para>To import this file, specify the file name. The following | <screen>&prompt.root; <userinput>openssl verify -verbose -CApath . server.crt</userinput></screen> | ||||
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> | <para>If <filename>slapd</filename> was running, it must now | ||||
Enter LDAP Password: | be restarted before using the server. | ||||
adding new entry "dc=example,dc=com" | Please, carefully read the comments included in | ||||
Done Inline ActionsMove this sentence up one line. bcr: Move this sentence up one line. | |||||
<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 | |||||
Done Inline ActionsSame here, move the sentence up to start after "boot." bcr: Same here, move the sentence up to start after "boot." | |||||
<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> | |||||
adding new entry "cn=Manager,dc=example,dc=com"</screen> | <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>Verify the data was added by issuing a search on the | <para><filename>slapd</filename> does not provide debugging at | ||||
server using <command>ldapsearch</command>:</para> | boot, but <filename>dmesg -a</filename>, <filename> | ||||
/var/log/messages</filename> and (in particular) | |||||
Done Inline Actionsno space here between <filename> and /var/log/messages</filename> bcr: no space here between <filename> and /var/log/messages</filename> | |||||
<filename>/var/log/debug.log</filename> can be checked.</para> | |||||
<screen>&prompt.user; <userinput>ldapsearch -Z</userinput> | <para>The <acronym>LDAP</acronym> users database is still | ||||
# extended LDIF | empty. An example, which adds a group called | ||||
# | <literal>team</literal> and a user called | ||||
# LDAPv3 | <literal>john</literal> to the | ||||
# base <dc=example,dc=com> (default) with scope subtree | <systemitem class="systemname">domain.example</systemitem> | ||||
# filter: (objectclass=*) | database is here provided. Create a file <filename> | ||||
Done Inline Actionss/here provided/provided here/ bcr: s/here provided/provided here/ | |||||
# requesting: ALL | domain.ldif</filename> with the following contents:</para> | ||||
Done Inline ActionsNo space here. bcr: No space here. | |||||
# | |||||
# example.com | <screen>&prompt.root; <userinput>cat domain.ldif</userinput> | ||||
dn: dc=example,dc=com | dn: dc=domain,dc=example | ||||
objectClass: dcObject | objectClass: dcObject | ||||
objectClass: organization | objectClass: organization | ||||
o: Example | o: domain.example | ||||
dc: Example | dc: domain | ||||
# Manager, example.com | dn: ou=groups,dc=domain,dc=example | ||||
dn: cn=Manager,dc=example,dc=com | objectClass: top | ||||
objectClass: organizationalRole | objectClass: organizationalunit | ||||
cn: Manager | ou: groups | ||||
# search result | dn: ou=users,dc=domain,dc=example | ||||
search: 3 | objectClass: top | ||||
result: 0 Success | objectClass: organizationalunit | ||||
ou: users | |||||
# numResponses: 3 | dn: cn=team,ou=groups,dc=domain,dc=example | ||||
# numEntries: 2</screen> | objectClass: top | ||||
objectClass: posixGroup | |||||
cn: team | |||||
gidNumber: 10001 | |||||
<para>At this point, the server should be configured and | dn: uid=john,ou=users,dc=domain,dc=example | ||||
functioning properly.</para> | 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 | |||||
&man.slappasswd.8;. Be careful about the default shell path: | |||||
if it does not exist in the system where the user tries to log | |||||
Done Inline ActionsNo line break here. bcr: No line break here. | |||||
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 | |||||
Done Inline ActionsMove this one up to continue the line. bcr: Move this one up to continue the line. | |||||
<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. | |||||
Done Inline ActionsMove this one up, too. bcr: Move this one up, too. | |||||
The global super-user, whose name is by default | |||||
<literal>cn=config</literal>, should have a password set by | |||||
Done Inline ActionsThis can also go on on the previous line. bcr: This can also go on on the previous line. | |||||
<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 | |||||
Done Inline Actionsno break here after the colon (:). The "it" will certainly fit into this line and then wrap like normal. bcr: no break here after the colon (:). The "it" will certainly fit into this line and then wrap… | |||||
<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> | |||||
</sect2> | </sect2> | ||||
</sect1> | </sect1> | ||||
<sect1 xml:id="network-dhcp"> | <sect1 xml:id="network-dhcp"> | ||||
<!-- | <!-- | ||||
<sect1info> | <sect1info> | ||||
<authorgroup> | <authorgroup> | ||||
<author> | <author> | ||||
▲ Show 20 Lines • Show All 3,212 Lines • Show Last 20 Lines |
This colon just splices two sentences together. Please just use short, separate sentences.