Centralized authentication using OpenLDAP/zh

这份指南介绍了有关LDAP的一些基础概念并且向您展示了如何配置OpenLDAP来完成一组计算机之间的认证.

LDAP是什么？
LDAP是指“Lightweight Directory Access Protocol（轻量目录访问协议）”，它是基于X.500协议的，包括了X.500的大部分功能，但是精减掉了那些过于艰深的东西. 那么什么是X.500，而为什么还要有LDAP出现呢？

X.500是OSI标准体系中的目录服务模型，它包含了命名空间的定义以及查询与更新目录的协议，但是X.500在很多场景下被认为有些“用力过猛”. 而LDAP，虽然像X.500一样也为目录提供了数据/命名空间的模型与协议，但它被设计为运行在TCP/IP网络协议栈上（译者注：TCP/IP协议栈是IETF标准化组织定义的，而之前讲的OSI标准体系是区别于IETF的另外一套标准化组织，其实OSI体系更古老，更资深也更复杂，我们现在的互联网是基于TCP/IP的通信协议栈的，而OSI里面是有对应于TCP/IP的通信协议栈的，但由于设备厂家支持较少，最终没有流行起来. IETF与OSI有矛盾但也有合作，互相借鉴很多有价值的东西），所以我们可以把LDAP当成是“减肥”了的X.500.

我还是不理解，什么是目录？
目录是一个特殊的数据库，它的数据经常被查询，但是不经常更新. 不像普通的数据库，目录不包括对事件（transaction）的支持也不包括回滚特性. 目录是很容易被复制的，以便增加它的可用性和可靠性. 当目录被复制时，临时的数据不一致情况是允许出现的，只要最终这些数据得到同步即可.

信息是怎样被组织的？
目录中所有的信息被分层次组织在一起. 另外，如果您想在目录中添加数据，目录必须要知道如何在树状结构中添加您的这些数据. 我们用一个虚构的公司来举例说明一下，如下面的像Internet一样的树状结构：

因为您不能像上图一样使用ascii图形码向一个数据库中输入数据，所以这样一个树形结构中的每一个节点都要被定义. 为了定义这样一个节点，LDAP使用“命名方案（Naming Scheme）”. 大多数的LDAP发行版（包括OpenLDAP）已经包括了一揽子预定义（以及共同认可）的命名方案，如“inetOrgPerson”，或者“posixAccount”，“posixAccount”用来定义一个用户（user）的Unix/Linux相关属性，它是非常常用的. 值得一提的是您可以考虑采用图形化的基于web的工具来管理LDAP，这样能轻松很多. 参见实际使用OpenLDAP

感兴趣的用户推荐阅读 OpenLDAP Admin Guide

那么，LDAP能够干什么呢？
LDAP可以用来做许多不同的事情呢. 这篇文档聚焦于如何集中管理用户，把所有用户的信息保存在统一的LDAP目录里（统一并不意味着只有一台服务器，LDAP是支持高可用性与高冗余性的），另外还有其它一些目标也可以通过LDAP来实现.


 * 公钥基础设施


 * 共享日历


 * 共享地址簿


 * 存储DHCP，DNS，......


 * 系统级的配置管理（跟踪多台服务器的配置）


 * 集中认证 (PosixAccount)



OpenLDAP服务器配置
域名“genfic.com”是这份指南中的一个例子，您当然想改变它，但是请确保其顶级节点是官方的合法域名，如net、com、cc、be......

我们首先要emerge OpenLDAP. 请确保如下USE标记被使用：berkdb, crypt, gnutls, ipv6, sasl, ssl, syslog, -minimal

OpenLDAP有一个主要用户，它被称为“rootdn（Root Distinguished Name）”，这个用户已经在应用中被写死，不可更改. 但是与Unix中的root用户不同，rootdn仍然需要被指定适当的权限. rootdn用户可能仅在配置的上下文中被使用，也可能被用于目录的定义，相应地，rootdn用户可以使用配置文件里的密码和目录树中的密码来认证他们自己. （译者注：这里不太好理解，我的个人理解是：openldap的服务器采用/etc/slapd.conf来做配置，里面有一个rootdn条目，这里面指定的dn，例如cn=Manager,dc=genfic,dc=com就是ldap里面最牛的管理员，它可以在LDAP里面干任何事儿，另外openldap运行起来之后，它会维护一个用户信息数据库，这个数据库里面是可以没有cn=Manager,dc=genfic,dc=com这个dn的，当没有这个dn时，这个叫Manager的用户就是只可以管理ldap目录及其内容，但不能用这个用户在ldap客户端上登录，也不能保存关于Manager的个人信息，如电话、地址等，因为ldap没有存储这些信息的地方. 但是您也可以在数据库中自己加上这个用户的相应节点，这时这个用户就可以像其它用户一样享受在客户端登录，保存个人信息等“福利”了. ）

为了验证目的的用户密码（不管是rootdn的还是其它用户的）都可以被存储为明文或者哈希过的. 很多哈希算法都是可用的，但是使用太弱（比MD5更弱）的加密算法是不被推荐的. SHA当前被认为是足够安全的算法.

In the below command, a hashed value is created for a given password; the result of this command can be used in the configuration file, or in the internal directory definition of a user:

Now edit the LDAP Server configuration in. The provided is from the original openLDAP source. Below is a sample configuration file one can use to replace it with to get things started.

For a more detailed analysis of the configuration file, we suggest that you work through the OpenLDAP Administrator's Guide.

Verifying the configuration
After customizing the file you can check it with the following command.

Or, if you decide to use OLC:

Vary the debug level (the "-d 1" above) for more info. If all goes well you will see config file testing succeeded. If there's an error,  will list the line number to which it applies (of the  file).

Note that since version 2.4.23, OpenLDAP moved from traditional flat config files to OLC (OnLineConfiguration, also known through its   structure) as default configuration method. One of benefits of using OLC is that the dynamic back-end (cn=config) doesn't require restart of server after updating the configuration. Existing users can migrate to the new configuration method by invoking  setting both -f and -F options. Traditionally OLC is stored in ldif back-end (which keep benefits of human-readability) in the directory. In Gentoo it is not required to convert the configuration yet, but support for the currently documented approach will be removed in the future.

If you want to be able to change OpenLDAP server's configuration, you must define at least write (or normally manage) access to.

The example below shows how to grant manage access to OLC (cn=config database) to the system administrator (root user) by adding the proper lines at the end of the file:

Running this command will transfer and translate the configuration. After that you are expected to update the configuration using specially prepared ldif files. And only if you aren't enough familiar with them, you can first edit and after that re-translate the  into. Don't forget to check the directory's permissions.

For more instructions read the in-line comments of the generated files.

The below line will enable the configuration method.

Finally, create the structure:

Start slapd:

If it does not start then increase the loglevel variable in to 4 or more, and look in  for more information.

Example OLC-style update LDIFs
Some examples of updates on the OLC-style configuration are mentioned below.

For instance, to change the location of the OLC configuration directory:

To change the log level used by the OpenLDAP instance:

In order to apply the changes, run the following command:

Configuring the OpenLDAP Client tools
Edit the LDAP Client configuration file. This file is read by ldapsearch and other ldap command line tools.

You can test the running server with the following command:

If you receive an error, try adding  to increase the verbosity and solve the issue you have.

Client Configuration for Centralised Authentication
There are numerous methods/tools that can be used for remote authentication. Some distributions also have their own easy to use configuration tool. Below there are some in no particular order. It is possible to combine local users and centrally authorized accounts at the same time. This is important because, for instance, if the LDAP server cannot be accessed one can still login as root.


 * SSSD (Single Sign-on Services Daemon). Its primary function is to provide access to identity and authentication remote resource through a common framework that can provide caching and offline support to the system. It provides PAM and NSS modules, and in the future will support D-Bus interfaces for extended user information. It also provides a better database to store local users as well as extended user data.


 * Use  to login to the LDAP server and authenticate. Passwords are not sent over the network in clear text.


 * NSLCD (Name Service Look up Daemon). Similar to SSSD, but older.


 * NSS (Name Service Switch) using the traditional  module to fetch password hashes over the network. To permit users to update their password this has to be combined with the   method.

The first two are demonstrated below with the minimum necessary configuration options to get working.

Client PAM configuration SSSD Method
Here is the more direct method. The three files that are required to be edited are mentioned below.

Add sss to the end as shown below to enable the lookup to be handed to the sssd system service. Once you have finished editing start the sssd daemon.

The last file is the most critical. Open an extra root terminal as a fallback before editing this. The lines that end with  have been added to enable remote authentication. Note the use of to support creating the user home directories.

Now try logging in from another box.

Client PAM configuration the pam_ldap Module Method
First, we will configure PAM to allow LDAP authorization. Install so that PAM supports LDAP authorization, and  so that your system can cope with LDAP servers for additional information (used by ).

The last file is the most critical. Open a few extra root terminals as a backup before editing this. The lines that end with  have been added to enable remote authentication.

Now change to read:

Next, copy over the (OpenLDAP) file from the server to the client so the clients are aware of the LDAP environment:

Finally, configure your clients so that they check the LDAP for system accounts:

If you noticed one of the lines you pasted into your was commented out (the   line): you don't need it unless you want to change a user's password as superuser. In this case you need to echo the root password to in plaintext. This is DANGEROUS and should be chmoded to 600. What you might want to do is keep that file blank and when you need to change someone's password that's both in the LDAP and, put the pass in there for 10 seconds while changing the users password and remove it when done.

Migrate existing data to LDAP
Configuring OpenLDAP for centralized administration and management of common Linux/Unix items isn't easy, but thanks to some tools and scripts available on the Internet, migrating a system from a single-system administrative point-of-view towards an OpenLDAP-based, centralized managed system isn't hard either.

Go to http://www.padl.com/OSS/MigrationTools.html and fetch the scripts there. You'll need the migration tools and the script.

Next, extract the tools and copy the script inside the extracted location:

The next step now is to migrate the information of your system to OpenLDAP. The script will do this for you, after you have provided it with the information regarding your LDAP structure and environment.

At the time of writing, the tools require the following input:

The tool will also ask you which accounts and settings you want to migrate.

High availability
To setup replication of changes across multiple LDAP systems. Replication within OpenLDAP is, in this guide, set up using a specific replication account which has read rights on the primary LDAP server and which pulls in changes from the primary LDAP server to the secondary.

This setup is then mirrored, allowing the secondary LDAP server to act as a primary. Thanks to OpenLDAP's internal structure, changes are not re-applied if they are already in the LDAP structure.

Setting Up Replication
To setup replication, first setup a second OpenLDAP server, similarly as above. However take care that, in the configuration file:


 * The sync replication provider is pointing to the other system


 * The serverID of each OpenLDAP system is different

Next, create the synchronisation account. We will create an LDIF file (the format used as data input for LDAP servers) and add it to each LDAP server:

OpenLDAP permissions
If we take a look at you'll see that you can specify the ACLs (permissions if you like) of what data users can read and/or write:

This gives you access to everything a user should be able to change. If it's your information, then you got write access to it; if it's another user their information then you can read it; anonymous people can send a login/pass to get logged in. There are four levels, ranking them from lowest to greatest:.

The next ACL is a bit more secure as it blocks normal users to read other people their shadowed password:

This example gives root and John access to read/write/search for everything in the the tree below. This also lets users change their own 's. As for the ending statement everyone else just has a search ability meaning they can fill in a search filter, but can't read the search results. Now you can have multiple ACLs but the rule of the thumb is it processes from bottom up, so your toplevel should be the most restrictive one.

Maintaining the directory
You can start using the directory to authenticate users in apache/proftpd/qmail/samba. You can manage it with LAM (Ldap Account Manager), phpldapadmin, diradm, jxplorer, or lat, which provide easy management interfaces.

Acknowledgements
We would like to thank Matt Heler for lending us his box for the purpose of this guide. Thanks also go to the cool guys in #ldap @ irc.freenode.net