From owner-svn-doc-all@FreeBSD.ORG Mon May 26 17:43:19 2014 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4369CAC8; Mon, 26 May 2014 17:43:19 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2EB5E2B0E; Mon, 26 May 2014 17:43:19 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s4QHhJCg076590; Mon, 26 May 2014 17:43:19 GMT (envelope-from bcr@svn.freebsd.org) Received: (from bcr@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s4QHhJSr076589; Mon, 26 May 2014 17:43:19 GMT (envelope-from bcr@svn.freebsd.org) Message-Id: <201405261743.s4QHhJSr076589@svn.freebsd.org> From: Benedict Reuschling Date: Mon, 26 May 2014 17:43:19 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44962 - head/en_US.ISO8859-1/articles/ldap-auth X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 17:43:19 -0000 Author: bcr Date: Mon May 26 17:43:18 2014 New Revision: 44962 URL: http://svnweb.freebsd.org/changeset/doc/44962 Log: Whitespace fixes covering the whole document. Translators can ignore them. 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 May 26 17:21:11 2014 (r44961) +++ head/en_US.ISO8859-1/articles/ldap-auth/article.xml Mon May 26 17:43:18 2014 (r44962) @@ -1,14 +1,24 @@ -
- LDAP Authentication - +
+ + LDAP Authentication - TobyBurress -
kurin@causa-sui.net
- + + + Toby + Burress + + +
+ kurin@causa-sui.net +
+ + @@ -28,10 +38,11 @@ This document is intended as a guide for the configuration - of an LDAP server (principally an OpenLDAP - server) for authentication on &os;. This is useful for situations - where many servers need the same user accounts, for example as a - replacement for NIS. + of an LDAP server (principally an + OpenLDAP server) for authentication + on &os;. This is useful for situations where many servers + need the same user accounts, for example as a replacement for + NIS. @@ -39,65 +50,73 @@ Preface This document is intended to give the reader enough of an - understanding of LDAP to configure an LDAP server. This document will - attempt to provide an - explanation of net/nss_ldap - and security/pam_ldap for use with - client machines services for use with the LDAP server. + understanding of LDAP to configure an LDAP server. This + document will attempt to provide an explanation of + net/nss_ldap and + security/pam_ldap for use with client + machines services for use with the LDAP server. When finished, the reader should be able to configure and deploy a &os; server that can host an LDAP directory, and to - configure and deploy a &os; server which can authenticate against - an LDAP directory. + configure and deploy a &os; server which can authenticate + against an LDAP directory. This article is not intended to be an exhaustive account of the security, robustness, or best practice considerations for - configuring LDAP or the other services discussed herein. While the author - takes care to do everything correctly, he does not - address security issues beyond a general scope. This article should be - considered to lay the theoretical groundwork only, and any actual - implementation should be accompanied by careful requirement - analysis. + configuring LDAP or the other services discussed herein. While + the author takes care to do everything correctly, he does not + address security issues beyond a general scope. This article + should be considered to lay the theoretical groundwork only, and + any actual implementation should be accompanied by careful + requirement analysis. Configuring LDAP + LDAP stands for Lightweight Directory Access - Protocol and is a subset of the X.500 Directory Access - Protocol. Its most recent specifications are in RFC4510 and - friends. Essentially it is a database that expects to be read from - more often than it is written to. - - The LDAP server OpenLDAP will be used in the - examples in this document; while the principles here should be - generally applicable to many different servers, most of the - concrete administration is + Protocol and is a subset of the X.500 Directory Access + Protocol. Its most recent specifications are in RFC4510 + and friends. Essentially it is a database that expects to be + read from more often than it is written to. + + The LDAP server OpenLDAP will be + used in the examples in this document; while the principles here + should be generally applicable to many different servers, most + of the concrete administration is OpenLDAP-specific. There are several - server versions in ports, for example net/openldap24-server. Client servers - will need the corresponding net/openldap24-client libraries. + server versions in ports, for example + net/openldap24-server. Client servers will + need the corresponding net/openldap24-client + libraries. - There are (basically) two areas of the LDAP service which need - configuration. The first is setting up a server to receive + There are (basically) two areas of the LDAP service which + need configuration. The first is setting up a server to receive connections properly, and the second is adding entries to the - server's directory so that &os; tools know how to interact with it. + server's directory so that &os; tools know how to interact with + it. Setting Up the Server for Connections This section is specific to - OpenLDAP. If you are using another - server, you will need to consult that server's + OpenLDAP. If you are using + another server, you will need to consult that server's documentation. Installing <application>OpenLDAP</application> - First, install OpenLDAP: + First, install + OpenLDAP: - Installing <application>OpenLDAP</application> + Installing + <application>OpenLDAP</application> &prompt.root; cd /usr/ports/net/openldap24-server &prompt.root; make install clean @@ -114,38 +133,39 @@ Next we must configure OpenLDAP. - You will want to require encryption in your - connections to the LDAP server; otherwise your users' passwords - will be transferred in plain text, which is considered - insecure. The tools we will be using support two very similar kinds - of encryption, SSL and TLS. - - TLS stands for Transportation Layer Security. - Services that employ TLS tend to connect on the - same ports as the same services without - TLS; thus an SMTP server which supports TLS will listen for - connections on port 25, and an LDAP server will listen on 389. + You will want to require encryption in your connections + to the LDAP server; otherwise your users' passwords will be + transferred in plain text, which is considered insecure. + The tools we will be using support two very similar kinds of + encryption, SSL and TLS. + + TLS stands for Transportation Layer + Security. Services that employ TLS tend to + connect on the same ports as the same + services without TLS; thus an SMTP server which supports TLS + will listen for connections on port 25, and an LDAP server + will listen on 389. SSL stands for Secure Sockets Layer, and - services that implement SSL do not listen on - the same ports as their non-SSL counterparts. Thus SMTPS listens - on port 465 (not 25), HTTPS listens on 443, and LDAPS on - 636. - - The reason SSL uses a different port than TLS is because a - TLS connection begins as plain text, and switches to encrypted - traffic after the STARTTLS directive. SSL - connections are encrypted from the beginning. Other than that - there are no substantial differences between the two. + services that implement SSL do not + listen on the same ports as their non-SSL counterparts. + Thus SMTPS listens on port 465 (not 25), HTTPS listens on + 443, and LDAPS on 636. + + The reason SSL uses a different port than TLS is because + a TLS connection begins as plain text, and switches to + encrypted traffic after the STARTTLS + directive. SSL connections are encrypted from the + beginning. Other than that there are no substantial + differences between the two. - We will adjust - OpenLDAP to use TLS, as SSL is - considered deprecated. + We will adjust OpenLDAP to + use TLS, as SSL is considered deprecated. - Once OpenLDAP is installed via - ports, the following configuration parameters in + Once OpenLDAP is installed + via ports, the following configuration parameters in /usr/local/etc/openldap/slapd.conf will enable TLS: @@ -158,17 +178,18 @@ TLSCACertificateFile /path/to/your/cacer Here, ssf=128 tells OpenLDAP to require 128-bit - encryption for all connections, both search and update. This - parameter may be configured based on the security needs of your - site, but rarely you need to weaken it, as most LDAP client - libraries support strong encryption. + encryption for all connections, both search and update. + This parameter may be configured based on the security needs + of your site, but rarely you need to weaken it, as most LDAP + client libraries support strong encryption. The cert.crt, cert.key, and - cacert.crt files are necessary for clients - to authenticate you as the valid LDAP - server. If you simply want a server that runs, you can create a - self-signed certificate with OpenSSL: + cacert.crt files are necessary for + clients to authenticate you as the + valid LDAP server. If you simply want a server that runs, + you can create a self-signed certificate with + OpenSSL: Generating an RSA Key @@ -181,16 +202,16 @@ e is 65537 (0x10001) &prompt.user; openssl req -new -key cert.key -out cert.csr - At this point you should be prompted for some values. You - may enter whatever values you like; however, it is important the - Common Name value be the fully qualified domain - name of the OpenLDAP server. - In our case, and the examples here, the server is - server.example.org. - Incorrectly setting this value will cause clients to fail when - making connections. This can the - cause of great frustration, so ensure that you follow these - steps closely. + At this point you should be prompted for some values. + You may enter whatever values you like; however, it is + important the Common Name value be the fully + qualified domain name of the + OpenLDAP server. In our case, + and the examples here, the server is + server.example.org. Incorrectly + setting this value will cause clients to fail when making + connections. This can the cause of great frustration, so + ensure that you follow these steps closely. Finally, the certificate signing request needs to be signed: @@ -207,11 +228,12 @@ Getting Private key This will create a self-signed certificate that can be used for the directives in slapd.conf, where cert.crt and - cacert.crt are the same file. If you are - going to use many OpenLDAP servers - (for replication via slurpd) you will want to - see to generate a CA key and use it to - sign individual server certificates. + cacert.crt are the same file. If you + are going to use many OpenLDAP + servers (for replication via slurpd) you + will want to see to generate a CA + key and use it to sign individual server + certificates. Once this is done, put the following in /etc/rc.conf: @@ -230,16 +252,18 @@ ldap slapd 3261 7 tcp4 *:38 Configuring the Client - Install the net/openldap24-client port for the - OpenLDAP libraries. The client - machines will always have OpenLDAP - libraries since that is all security/pam_ldap and net/nss_ldap support, at least for the + Install the net/openldap24-client + port for the OpenLDAP libraries. + The client machines will always have + OpenLDAP libraries since that is + all security/pam_ldap and + net/nss_ldap support, at least for the moment. The configuration file for the OpenLDAP libraries is - /usr/local/etc/openldap/ldap.conf. Edit - this file to contain the following values: + /usr/local/etc/openldap/ldap.conf. + Edit this file to contain the following values: base dc=example,dc=org uri ldap://server.example.org/ @@ -248,17 +272,17 @@ tls_cacert /path/to/your/cacert.crt It is important that your clients have access to - cacert.crt, otherwise they will not be - able to connect. + cacert.crt, otherwise they will not + be able to connect. There are two files called - ldap.conf. The first is this file, which - is for the OpenLDAP libraries and - defines how to talk to the server. The second is - /usr/local/etc/ldap.conf, and is for - pam_ldap. + ldap.conf. The first is this file, + which is for the OpenLDAP + libraries and defines how to talk to the server. The + second is /usr/local/etc/ldap.conf, + and is for pam_ldap. At this point you should be able to run @@ -266,8 +290,9 @@ tls_cacert /path/to/your/cacert.crt-Z means use TLS. If you encounter an error, then something is configured wrong; most likely it is your certificates. Use &man.openssl.1;'s - s_client and s_server to - ensure you have them configured and signed properly. + s_client and s_server + to ensure you have them configured and signed + properly. @@ -275,22 +300,23 @@ tls_cacert /path/to/your/cacert.crtEntries in the Database Authentication against an LDAP directory is generally - accomplished by attempting to bind to the directory as the connecting user. - This is done by establishing a simple - bind on the directory with the user name supplied. If there is an - entry with the uid equal to the user name and - that entry's userPassword attribute matches the - password supplied, then the bind is successful. + accomplished by attempting to bind to the directory as the + connecting user. This is done by establishing a + simple bind on the directory with the user name + supplied. If there is an entry with the + uid equal to the user name and that entry's + userPassword attribute matches the password + supplied, then the bind is successful. - The first thing we have to do is figure out is where in the - directory our users will live. + The first thing we have to do is figure out is where in + the directory our users will live. The base entry for our database is - dc=example,dc=org. The default location for - users that most clients seem to expect is something like - ou=people,base, so - that is what will be used here. However keep in mind that this is - configurable. + dc=example,dc=org. The default location + for users that most clients seem to expect is something like + ou=people,base, + so that is what will be used here. However keep in mind that + this is configurable. So the ldif entry for the people organizational unit will look like: @@ -306,17 +332,18 @@ ou: people Some thought might be given to the object class your users will belong to. Most tools by default will use people, which is fine if you simply want to - provide entries against which to authenticate. However, if you - are going to store user information in the LDAP database as well, - you will probably want to use inetOrgPerson, - which has many useful attributes. In either case, the relevant - schemas need to be loaded in - slapd.conf. + provide entries against which to authenticate. However, if + you are going to store user information in the LDAP database + as well, you will probably want to use + inetOrgPerson, which has many useful + attributes. In either case, the relevant schemas need to be + loaded in slapd.conf. For this example we will use the person - object class. If you are using inetOrgPerson, - the steps are basically identical, except that the - sn attribute is required. + object class. If you are using + inetOrgPerson, the steps are basically + identical, except that the sn attribute is + required. To add a user testuser, the ldif would be: @@ -333,9 +360,9 @@ loginShell: /bin/csh uid: tuser cn: tuser - 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 is less than 65536. + 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 is less than 65536. We also need group entries. They are as configurable as user entries, but we will use the defaults below: @@ -352,13 +379,14 @@ gidNumber: 10000 cn: tuser To enter these into your database, you can use - slapadd or ldapadd - on a file containing these entries. Alternatively, you can use + slapadd or ldapadd on a + file containing these entries. Alternatively, you can use sysutils/ldapvi. - The ldapsearch utility on the client machine - should now return these entries. If it does, your database is - properly configured to be used as an LDAP authentication server. + The ldapsearch utility on the client + machine should now return these entries. If it does, your + database is properly configured to be used as an LDAP + authentication server. @@ -366,27 +394,29 @@ cn: tuser Client Configuration The client should already have - OpenLDAP libraries from , but if you are installing several - client machines you will need to install net/openldap24-client on each of - them. + OpenLDAP libraries from , but if you are installing + several client machines you will need to install + net/openldap24-client on each of them. &os; requires two ports to be installed to authenticate - against an LDAP server, security/pam_ldap and net/nss_ldap. + against an LDAP server, security/pam_ldap and + net/nss_ldap. Authentication - security/pam_ldap is - configured via /usr/local/etc/ldap.conf. + security/pam_ldap is configured via + /usr/local/etc/ldap.conf. This is a different file than the OpenLDAP library functions' configuration file, - /usr/local/etc/openldap/ldap.conf; however, - it takes many of the same options; in fact it is a superset of - that file. For the rest of this section, references to - ldap.conf will mean + /usr/local/etc/openldap/ldap.conf; + however, it takes many of the same options; in fact it is a + superset of that file. For the rest of this section, + references to ldap.conf will mean /usr/local/etc/ldap.conf. @@ -394,11 +424,12 @@ cn: tuser configuration parameters from openldap/ldap.conf to the new ldap.conf. Once this is done, we want to - tell security/pam_ldap what to - look for on the directory server. + tell security/pam_ldap what to look for on + the directory server. - We are identifying our users with the uid - attribute. To configure this (though it is the default), set the + We are identifying our users with the + uid attribute. To configure this (though + it is the default), set the pam_login_attribute directive in ldap.conf: @@ -408,46 +439,51 @@ cn: tuser pam_login_attribute uid - With this set, security/pam_ldap will search the entire - LDAP directory under base for the value - uid=username. If it - finds one and only one entry, it will attempt to bind as that user - with the password it was given. If it binds correctly, then it - will allow access. Otherwise it will fail. + With this set, security/pam_ldap will + search the entire LDAP directory under base + for the value + uid=username. + If it finds one and only one entry, it will attempt to bind as + that user with the password it was given. If it binds + correctly, then it will allow access. Otherwise it will + fail. PAM PAM, which stands for Pluggable Authentication - Modules, is the method by which &os; authenticates most - of its sessions. To tell &os; we wish to use an LDAP server, we - will have to add a line to the appropriate PAM file. + Modules, is the method by which &os; authenticates + most of its sessions. To tell &os; we wish to use an LDAP + server, we will have to add a line to the appropriate PAM + file. Most of the time the appropriate PAM file is /etc/pam.d/sshd, if you want to use SSH (remember to set the relevant - options in /etc/ssh/sshd_config, otherwise - SSH will not use PAM). + options in /etc/ssh/sshd_config, + otherwise SSH will not use + PAM). To use PAM for authentication, add the line auth sufficient /usr/local/lib/pam_ldap.so no_warn Exactly where this line shows up in the file and which - options appear in the fourth column determine the exact behavior - of the authentication mechanism; see &man.pam.d.5; + options appear in the fourth column determine the exact + behavior of the authentication mechanism; see + &man.pam.d.5; - With this configuration you should be able to authenticate - a user against an LDAP directory. + With this configuration you should be able to + authenticate a user against an LDAP directory. PAM will perform a bind with your credentials, and if successful will tell SSH to allow access. However it is not a good idea to allow every user in the directory into - every client machine. With the - current configuration, all that a user needs to log into a - machine is an LDAP entry. Fortunately there are a few ways to + every client machine. With the current + configuration, all that a user needs to log into a machine + is an LDAP entry. Fortunately there are a few ways to restrict user access. ldap.conf supports a @@ -458,27 +494,28 @@ cn: tuser pam_groupdn cn=servername,ou=accessgroups,dc=example,dc=org in ldap.conf, then only members of - that group will be able to log in. There are a few things to - bear in mind, however. + that group will be able to log in. There are a few things + to bear in mind, however. Members of this group are specified in one or more - memberUid attributes, and each attribute must - have the full distinguished name of the member. So - memberUid: someuser will not work; it must - be: + memberUid attributes, and each attribute + must have the full distinguished name of the member. So + memberUid: someuser will not work; it + must be: memberUid: uid=someuser,ou=people,dc=example,dc=org - Additionally, this directive is not checked in PAM during - authentication, it is checked during account management, so you - will need a second line in your PAM files under - account. This will require, in turn, - every user to be listed in the group, which - is not necessarily what we want. To avoid blocking users that - are not in LDAP, you should enable the - ignore_unknown_user attribute. Finally, you - should set the ignore_authinfo_unavail option - so that you are not locked out of every computer when the LDAP + Additionally, this directive is not checked in PAM + during authentication, it is checked during account + management, so you will need a second line in your PAM files + under account. This will require, in + turn, every user to be listed in the + group, which is not necessarily what we want. To avoid + blocking users that are not in LDAP, you should enable the + ignore_unknown_user attribute. Finally, + you should set the + ignore_authinfo_unavail option so that + you are not locked out of every computer when the LDAP server is unavailable. Your pam.d/sshd might then end up @@ -499,11 +536,12 @@ account required /usr/loc Since we are adding these lines specifically to - pam.d/sshd, this will only have an effect - on SSH sessions. LDAP users will - be unable to log in at the console. To change this behavior, - examine the other files in /etc/pam.d and - modify them accordingly. + pam.d/sshd, this will only have an + effect on SSH sessions. LDAP + users will be unable to log in at the console. To change + this behavior, examine the other files in + /etc/pam.d and modify them + accordingly. @@ -512,21 +550,23 @@ account required /usr/loc Name Service Switch NSS is the service that maps - attributes to names. So, for example, if a file is owned by user - 1001, an application will query + attributes to names. So, for example, if a file is owned by + user 1001, an application will query NSS for the name of - 1001, and it might get bob - or ted or whatever the user's name is. + 1001, and it might get + bob or ted or whatever + the user's name is. Now that our user information is kept in LDAP, we need to tell NSS to look there when queried. - The net/nss_ldap port - does this. It uses the same configuration file as security/pam_ldap, and should not need - any extra parameters once it is installed. Instead, what is left - is simply to edit /etc/nsswitch.conf to take - advantage of the directory. Simply replace the following + The net/nss_ldap port does this. It + uses the same configuration file as + security/pam_ldap, and should not need any + extra parameters once it is installed. Instead, what is left + is simply to edit /etc/nsswitch.conf to + take advantage of the directory. Simply replace the following lines: group: compat @@ -547,12 +587,13 @@ passwd: files ldap Caveats - Unfortunately, as of the time this was written &os; did not - support changing user passwords with &man.passwd.1;. Because of - this, most administrators are left to implement a solution - themselves. I provide some examples here. Note that if you write - your own password change script, there are some security issues - you should be made aware of; see + Unfortunately, as of the time this was written &os; did + not support changing user passwords with &man.passwd.1;. + Because of this, most administrators are left to implement a + solution themselves. I provide some examples here. Note that + if you write your own password change script, there are some + security issues you should be made aware of; see Shell Script for Changing Passwords @@ -580,17 +621,17 @@ ldappasswd -D uid="$USER",ou=people,dc=e This script does hardly any error checking, but more important it is very cavalier about how it stores your passwords. If you do anything like this, at least adjust - the security.bsd.see_other_uids - sysctl value: + the security.bsd.see_other_uids sysctl + value: &prompt.root; sysctl security.bsd.see_other_uids=0. A more flexible (and probably more secure) approach can be - used by writing a custom program, or even a web interface. The - following is part of a Ruby library - that can change LDAP passwords. It sees use both on the command - line, and on the web. + used by writing a custom program, or even a web interface. + The following is part of a Ruby + library that can change LDAP passwords. It sees use both on + the command line, and on the web. Ruby Script for Changing Passwords @@ -634,8 +675,9 @@ conn.modify(luser, [replace])]]> Although not guaranteed to be free of security holes (the - password is kept in memory, for example) this is cleaner and more - flexible than a simple sh script. + password is kept in memory, for example) this is cleaner and + more flexible than a simple sh + script. @@ -658,13 +700,15 @@ conn.modify(luser, [replace])]]>Several attributes in LDAP should be read-only. If left writable by the user, for example, a user could change his - uidNumber attribute to 0 and - get root access! - - To begin with, the userPassword attribute - should not be world-readable. By default, anyone who can connect - to the LDAP server can read this attribute. To disable this, put - the following in slapd.conf: + uidNumber attribute to 0 + and get root + access! + + To begin with, the userPassword + attribute should not be world-readable. By default, anyone + who can connect to the LDAP server can read this attribute. + To disable this, put the following in + slapd.conf: Hide Passwords @@ -681,14 +725,14 @@ access to * This will disallow reading of the - userPassword attribute, while still allowing - users to change their own passwords. + userPassword attribute, while still + allowing users to change their own passwords. Additionally, you'll want to keep users from changing some of their own attributes. By default, users can change any - attribute (except for those which the LDAP schemas themselves deny - changes), such as uidNumber. To close this - hole, modify the above to + attribute (except for those which the LDAP schemas themselves + deny changes), such as uidNumber. To close + this hole, modify the above to Read-only Attributes @@ -707,35 +751,38 @@ access to * by * read - This will stop users from being able to masquerade as other - users. + This will stop users from being able to masquerade as + other users. - <systemitem class="username">root</systemitem> Account Definition + <systemitem class="username">root</systemitem> Account + Definition - Often the root or manager account for - the LDAP service will be defined in the configuration file. - OpenLDAP supports this, for example, - and it works, but it can lead to trouble if - slapd.conf is compromised. It may be better - to use this only to bootstrap yourself into LDAP, and then define - a root account there. + Often the root + or manager account for the LDAP service will be defined in the + configuration file. OpenLDAP + supports this, for example, and it works, but it can lead to + trouble if slapd.conf is compromised. It + may be better to use this only to bootstrap yourself into + LDAP, and then define a root account there. Even better is to define accounts that have limited - permissions, and omit a root account entirely. - 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. + permissions, and omit a root account entirely. 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. Creating a Management Group - Say you want your IT department to be able to change home - 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: + Say you want your IT department to be able to change + home 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: Creating a Management Group @@ -755,21 +802,24 @@ memberUid: uid=user2,ou=people,dc=exampl ACLs for a Home Directory Management Group - access to dn.subtree="ou=people,dc=example,dc=org" + access to dn.subtree="ou=people,dc=example,dc=org" attr=homeDirectory by dn="cn=homemanagement,dc=example,dc=org" dnattr=memberUid write - Now tuser and user2 - can change other users' home directories. + Now tuser and + user2 can change + other users' home directories. 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 root account, but every power - root had is had by at least one user. The root - account then becomes unnecessary and can be removed. + domains. The idea is that soon no single user account has + the power of a root account, but every + power root had is had by at least one user. The root account then becomes + unnecessary and can be removed. @@ -777,14 +827,15 @@ memberUid: uid=user2,ou=people,dc=exampl Password Storage By default OpenLDAP will store - the value of the userPassword attribute as it - stores any other data: in the clear. Most of the time it is base - 64 encoded, which provides enough protection to keep an honest - administrator from knowing your password, but little else. - - It is a good idea, then, to store passwords in a more secure - format, such as SSHA (salted SHA). This is done by whatever - program you use to change users' passwords. + the value of the userPassword attribute as + it stores any other data: in the clear. Most of the time it + is base 64 encoded, which provides enough protection to keep + an honest administrator from knowing your password, but little + else. + + It is a good idea, then, to store passwords in a more + secure format, such as SSHA (salted SHA). This is done by + whatever program you use to change users' passwords. @@ -795,42 +846,43 @@ memberUid: uid=user2,ou=people,dc=exampl particularly if you have many users and do not want to configure everything manually. - security/pam_mkhomedir is - a PAM module that always succeeds; its purpose is to create home - directories for users which do not have them. If you have dozens of - client servers and hundreds of users, it is much easier to use this - and set up skeleton directories than to prepare every home + security/pam_mkhomedir is a PAM module + that always succeeds; its purpose is to create home directories + for users which do not have them. If you have dozens of client + servers and hundreds of users, it is much easier to use this and + set up skeleton directories than to prepare every home directory. - sysutils/cpu is a - &man.pw.8;-like utility that can be used to manage users in the LDAP - directory. You can call it directly, or wrap scripts around it. It - can handle both TLS (with the flag) and - SSL (directly). - - sysutils/ldapvi is a great - utility for editing LDAP values in an LDIF-like syntax. The - directory (or subsection of the directory) is presented in the - editor chosen by the EDITOR environment variable. - This makes it easy to enable large-scale changes in the directory - without having to write a custom tool. - - security/openssh-portable - has the ability to contact an LDAP server to verify - SSH keys. This is extremely nice if you - have many servers and do not want to copy your public keys across - all of them. + sysutils/cpu is a &man.pw.8;-like utility + that can be used to manage users in the LDAP directory. You can + call it directly, or wrap scripts around it. It can handle both + TLS (with the flag) and SSL + (directly). + + sysutils/ldapvi is a great utility for + editing LDAP values in an LDIF-like syntax. The directory (or + subsection of the directory) is presented in the editor chosen + by the EDITOR environment variable. This makes + it easy to enable large-scale changes in the directory without + having to write a custom tool. + + security/openssh-portable has the ability + to contact an LDAP server to verify + SSH keys. This is extremely nice if + you have many servers and do not want to copy your public keys + across all of them. - <application>OpenSSL</application> Certificates for LDAP + <application>OpenSSL</application> Certificates for + LDAP - If you are hosting two or more LDAP servers, you will probably - not want to use self-signed certificates, since each client will - have to be configured to work with each certificate. While this is - possible, it is not nearly as simple as creating your own - certificate authority, and signing your servers' certificates with - that. + If you are hosting two or more LDAP servers, you will + probably not want to use self-signed certificates, since each + client will have to be configured to work with each certificate. + While this is possible, it is not nearly as simple as creating + your own certificate authority, and signing your servers' + certificates with that. The steps here are presented as they are with very little attempt at explaining what is going on—further explanation @@ -849,22 +901,23 @@ memberUid: uid=user2,ou=people,dc=exampl These will be your root CA key and certificate. You will - probably want to encrypt the key and store it in a cool, dry place; - anyone with access to it can masquerade as one of your LDAP - servers. + probably want to encrypt the key and store it in a cool, dry + place; anyone with access to it can masquerade as one of your + LDAP servers. Next, using the first two steps above create a key ldap-server-one.key and certificate signing - request ldap-server-one.csr. Once you sign the - signing request with root.key, you will be able - to use ldap-server-one.* on your LDAP - servers. + request ldap-server-one.csr. Once you sign + the signing request with root.key, you will + be able to use ldap-server-one.* on your + LDAP servers. - Do not forget to use the fully qualified domain name for the - common name attribute when generating the + Do not forget to use the fully qualified domain name for + the common name attribute when generating the certificate signing request; otherwise clients will reject a - connection with you, and it can be very tricky to diagnose. + connection with you, and it can be very tricky to + diagnose. To sign the key, use and @@ -879,13 +932,13 @@ memberUid: uid=user2,ou=people,dc=exampl -out ldap-server-one.crt *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***