Bug 188845
| Summary: | Wrong SMTP port number in the LDAP Authentication article | ||
|---|---|---|---|
| Product: | Documentation | Reporter: | knezour |
| Component: | Books & Articles | Assignee: | Warren Block <wblock> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
knezour
2014-04-21 13:10:00 UTC
Responsible Changed From-To: freebsd-doc->wblock Take. Author: wblock Date: Mon Apr 21 16:23:41 2014 New Revision: 44615 URL: http://svnweb.freebsd.org/changeset/doc/44615 Log: Correct email port number. While here, fix title capitalization and contractions. PR: docs/188845 Submitted by: Ondra Knezour <knezour@weboutsourcing.cz> Modified: head/en_US.ISO8859-1/articles/ldap-auth/article.xml Modified: head/en_US.ISO8859-1/articles/ldap-auth/article.xml ============================================================================== --- head/en_US.ISO8859-1/articles/ldap-auth/article.xml Mon Apr 21 15:54:17 2014 (r44614) +++ head/en_US.ISO8859-1/articles/ldap-auth/article.xml Mon Apr 21 16:23:41 2014 (r44615) @@ -129,7 +129,7 @@ <para>SSL stands for <quote>Secure Sockets Layer</quote>, and services that implement SSL do <emphasis>not</emphasis> listen on the same ports as their non-SSL counterparts. Thus SMTPS listens - on port 465 (not 45), HTTPS listens on 443, and LDAPS on + on port 465 (not 25), HTTPS listens on 443, and LDAPS on 636.</para> <para>The reason SSL uses a different port than TLS is because a @@ -171,7 +171,7 @@ TLSCACertificateFile /path/to/your/cacer self-signed certificate with OpenSSL:</para> <example xml:id="genrsa"> - <title>Generating an RSA key</title> + <title>Generating an RSA Key</title> <screen>&prompt.user; <userinput>openssl genrsa -out cert.key 1024</userinput> Generating RSA private key, 1024 bit long modulus @@ -196,7 +196,7 @@ e is 65537 (0x10001) signed:</para> <example xml:id="self-sign"> - <title>Self-signing the certificate</title> + <title>Self-signing the Certificate</title> <screen>&prompt.user; <userinput>openssl x509 -req -in cert.csr -days 365 -signkey cert.key -out cert.crt</userinput> Signature ok @@ -335,7 +335,7 @@ cn: tuser</programlisting> <para>I start my LDAP users' UIDs at 10000 to avoid collisions with system accounts; you can configure whatever number you wish here, - as long as it's less than 65536.</para> + as long as it is less than 65536.</para> <para>We also need group entries. They are as configurable as user entries, but we will use the defaults below:</para> @@ -555,7 +555,7 @@ passwd: files ldap</programlisting> you should be made aware of; see <xref linkend="security-passwd"/></para> <example xml:id="chpw-shell"> - <title>Shell script for changing passwords</title> + <title>Shell Script for Changing Passwords</title> <programlisting><![CDATA[#!/bin/sh @@ -593,7 +593,7 @@ ldappasswd -D uid="$USER",ou=people,dc=e line, and on the web.</para> <example xml:id="chpw-ruby"> - <title>Ruby script for changing passwords</title> + <title>Ruby Script for Changing Passwords</title> <programlisting><![CDATA[require 'ldap' require 'base64' @@ -654,7 +654,7 @@ conn.modify(luser, [replace])]]></progra improvements.</para> <sect2 xml:id="secure-readonly"> - <title>Setting attributes read-only</title> + <title>Setting Attributes Read-only</title> <para>Several attributes in LDAP should be read-only. If left writable by the user, for example, a user could change his @@ -667,7 +667,7 @@ conn.modify(luser, [replace])]]></progra the following in <filename>slapd.conf</filename>:</para> <example xml:id="hide-userpass"> - <title>Hide passwords</title> + <title>Hide Passwords</title> <programlisting>access to dn.subtree="ou=people,dc=example,dc=org" attrs=userPassword @@ -691,7 +691,7 @@ access to * hole, modify the above to</para> <example xml:id="attrib-readonly"> - <title>Read-only attributes</title> + <title>Read-only Attributes</title> <programlisting>access to dn.subtree="ou=people,dc=example,dc=org" attrs=userPassword @@ -712,7 +712,7 @@ access to * </sect2> <sect2 xml:id="secure-root"> - <title><systemitem class="username">Root</systemitem> account definition</title> + <title><systemitem class="username">root</systemitem> Account Definition</title> <para>Often the <systemitem class="username">root</systemitem> or manager account for the LDAP service will be defined in the configuration file. @@ -724,21 +724,21 @@ access to * <para>Even better is to define accounts that have limited permissions, and omit a <systemitem class="username">root</systemitem> account entirely. - For example, users to can add or remove user accounts are added to + For example, users that can add or remove user accounts are added to one group, but they cannot themselves change the membership of this group. Such a security policy would help mitigate the effects of a leaked password.</para> <sect3 xml:id="manager-acct"> - <title>Creating a management group</title> + <title>Creating a Management Group</title> <para>Say you want your IT department to be able to change home - directories for users, but you don't want all of them to be able + directories for users, but you do not want all of them to be able to add or remove users. The way to do this is to add a group for these admins:</para> <example xml:id="manager-acct-dn"> - <title>Creating a management group</title> + <title>Creating a Management Group</title> <programlisting>dn: cn=homemanagement,dc=example,dc=org objectClass: top @@ -753,7 +753,7 @@ memberUid: uid=user2,ou=people,dc=exampl <filename>slapd.conf</filename>:</para> <example xml:id="management-acct-acl"> - <title>ACLs for a home directory management group</title> + <title>ACLs for a Home Directory Management Group</title> <programlisting>access to dn.subtree="ou=people,dc=example,dc=org" attr=homeDirectory @@ -764,7 +764,7 @@ memberUid: uid=user2,ou=people,dc=exampl <para>Now <systemitem class="username">tuser</systemitem> and <systemitem class="username">user2</systemitem> can change other users' home directories.</para> - <para>In this example we've given a subset of administrative + <para>In this example we have given a subset of administrative power to certain users without giving them power in other domains. The idea is that soon no single user account has the power of a <systemitem class="username">root</systemitem> account, but every power @@ -774,7 +774,7 @@ memberUid: uid=user2,ou=people,dc=exampl </sect2> <sect2 xml:id="security-passwd"> - <title>Password storage</title> + <title>Password Storage</title> <para>By default <application>OpenLDAP</application> will store the value of the <literal>userPassword</literal> attribute as it @@ -823,7 +823,7 @@ memberUid: uid=user2,ou=people,dc=exampl </appendix> <appendix xml:id="ssl-ca"> - <title><application>OpenSSL</application> Certificates For LDAP</title> + <title><application>OpenSSL</application> Certificates for LDAP</title> <para>If you are hosting two or more LDAP servers, you will probably not want to use self-signed certificates, since each client will @@ -841,7 +841,7 @@ memberUid: uid=user2,ou=people,dc=exampl are</para> <example xml:id="make-cert"> - <title>Creating a certificate</title> + <title>Creating a Certificate</title> <screen>&prompt.user; <userinput>openssl genrsa -out root.key 1024</userinput> &prompt.user; <userinput>openssl req -new -key root.key -out root.csr</userinput> @@ -872,7 +872,7 @@ memberUid: uid=user2,ou=people,dc=exampl <option>-signkey</option>:</para> <example xml:id="ca-sign"> - <title>Signing as a certificate authority</title> + <title>Signing as a Certificate Authority</title> <screen>&prompt.user; <userinput>openssl x509 -req -days 1024 \ -in ldap-server-one.csr -CA root.crt -CAkey root.key \ _______________________________________________ svn-doc-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-doc-all To unsubscribe, send any mail to "svn-doc-all-unsubscribe@freebsd.org" State Changed From-To: open->closed Changes committed, thanks! |
